Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch 0/8] x86/fpu: Mop up XSAVES and related damage | Date | Fri, 04 Jun 2021 20:14:24 +0200 |
| |
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
| |