lkml.org 
[lkml]   [2021]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 0/8] x86/fpu: Mop up XSAVES and related damage
Date
On Fri, Jun 04 2021 at 10:46, Dave Hansen wrote:
> On 6/4/21 7:05 AM, Thomas Gleixner wrote:
>> But looking at the above, it's not clear to me why that PKRU stuff works
>> at all (upstream), but I'll figure it out eventually. I'm quite sure
>> that it does work by pure chance not by design.
>
> The upstream flush_thread() code appears correct and even intentionally
> so. Just how we must eagerly load PKRU on a context switch, the
> fpu__clear*() code eagerly "clears" PKRU. It doesn't actually zero it,
> of course, but reverts the register and the fpstate back to the
> 'init_pkru_value':
>
> flush_thread()->fpu__clear_all()->fpu__clear(user_only=false)
> copy_init_fpstate_to_fpregs()
> copy_kernel_to_xregs(init_fpu) // fpstate
> copy_init_pkru_to_fpregs()
> write_pkru(init_pkru_value_snapshot) // fpregs
>
> Andy said you have a fix for this, but I think the new fpu__clear_all()
> is failing to do the eager write_pkru().

Yes, that's the reason and it took some time until I realized that
fpu__initialize() is inconsistent vs. PKRU.

We can't use copy_init_pkru_to_fregs() either because that's not
updating the xsaves area because XFEATURE_PKRU has been cleared.
Yay for consistency!

I'll post a fix soonish after testing it.

Thanks,

tglx

\
 
 \ /
  Last update: 2021-06-04 20:14    [W:0.083 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site