Re: [PATCH v5 14/28] x86/fpu/xstate: Prevent unauthorised use of dynamic user state

[Dave Hansen]

On 6/16/21 11:47 AM, Bae, Chang Seok wrote:
> On Jun 16, 2021, at 11:12, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>> On 6/16/21 9:27 AM, Dave Hansen wrote:
>>> On 5/23/21 12:32 PM, Chang S. Bae wrote:
>>>> @@ -571,6 +612,8 @@ static inline void switch_fpu_finish(struct fpu *new_fpu)
>>>>
>>>> 	set_thread_flag(TIF_NEED_FPU_LOAD);
>>>>
>>>> +	xfd_switch(old_fpu, new_fpu);
>>> This seems fragile.
>>>
>>> XSAVE* will decline to write out state for feature i when XFD[i]=1 and
>>> will instead write out the init state.  That means that, at this point,
>>> we switch XFD and yet leave state for feature i in place.
>>>
>>> That means this *MUST* come before any copy_fpregs_to_fpstate() occurs.
>>>
>>> Could we please add some FPU_WARN_ON() checks to ensure that no XSAVE*
>>> is ever performed with XINUSE=1 *and* XFD armed?
> So, xfd_switch() is after copy_fpregs_to_fpstate():
>  
> __switch_to()
> --> switch_fpu_prepare() --> copy_fpregs_to_fpstate()
> --> switch_fpu_finish() --> xfd_switch()
>  
> I don't see someone intentionally flip this order.

I'm more worried about how it might interact with KVM, or how future
code might try to optimize the whole thing.

Either way: the point stands: XSAVE with XINIT[i]=0 and XFD[i]=1 kills
puppies.  I ideally want a warning if the puppy slaughter ever happens.
 If that's not feasible, I'll also settle for a big fat comment about it.

But, something is needed.  The XSAVE code is littered with assumptions
that demonstrate a lack of imagination about how future hacking might
kill puppies.

> Reading XINUSE via XGETBV is cheap but not free. I don't know spending a
> hundred cycles for this WARN is big deal but this is one of the most
> performance-critical paths.
Is XGETBV(1) really a hundred cycles?  That seems absurdly high for a
non-serializing register read.

If you're really worried, let's put it under X86_FEATURE_DEBUG_FPU or
something.