Re: [PATCH stable 5.4,5.10] x86/fpu: Correct pkru/xstate inconsistency

[Brian Geffon]

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.