On Thu, Feb 17, 2022 at 11:44 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 2/17/22 05:31, Brian Geffon wrote: > > How would you and Greg KH like to proceed with this? I'm happy to help > > however I can. > > If I could wave a magic wand, I'd just apply the whole FPU rewrite to > stable. > > My second choice would be to stop managing PKRU with XSAVE. > x86_pkru_load() uses WRPKRU instead of XSAVE and keeps the task's PKRU > in task->pkru instead of the XSAVE buffer. Doing that will take some > care, including pulling XFEATURE_PKRU out of the feature mask (RFBM) at > XRSTOR. I _think_ that can be done in a manageable set of patches which > will keep stable close to mainline. I recognize that more bugs might > get introduced in the process which are unique to stable. Hi Dave, I did take some time to look through that series and pick out what I think is the minimum set that would pull out PKRU from xstate, that list is: 9782a712eb x86/fpu: Add PKRU storage outside of task XSAVE buffer 784a46618f x86/pkeys: Move read_pkru() and write_pkru() ff7ebff47c59 x86/pkru: Provide pkru_write_default() 739e2eec0f x86/pkru: Provide pkru_get_init_value() fa8c84b77a x86/cpu: Write the default PKRU value when enabling PKE 72a6c08c44 x86/pkru: Remove xstate fiddling from write_pkru() 2ebe81c6d8 x86/fpu: Dont restore PKRU in fpregs_restore_userspace() 71ef453355 x86/kvm: Avoid looking up PKRU in XSAVE buffer 954436989c x86/fpu: Remove PKRU handling from switch_fpu_finish() e84ba47e31 x86/fpu: Hook up PKRU into ptrace() 30a304a138 x86/fpu: Mask PKRU from kernel XRSTOR[S] operations 0e8c54f6b2c x86/fpu: Don't store PKRU in xstate in fpu_reset_fpstate() The majority of these don't apply cleanly to 5.4, and there are some other patches we'd have to pull back too that moved code and some of the those won't be needed for 5.10 though. TBH, I'm not sure it makes sense to try to do this just given the fact that most do not cleanly apply. Brian > > If you give that a shot and realize that it's not feasible to do a > subset, then we can fall back to the minimal fix. I'm not asking for a > multi-month engineering effort here. Maybe an hour or two to see if > it's really as scary as it looks.
