Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state

[Dave Hansen <dave.hansen@intel.com>]

On 3/24/21 2:42 PM, Andy Lutomirski wrote:
>>>> 3. user space always uses fully uncompacted XSAVE buffers.
>>>>
>>> There is no reason we have to do this for new states. Arguably we
>>> shouldn’t for AMX to avoid yet another altstack explosion.
>> The thing that's worried me is that the list of OS-enabled states is
>> visible to apps via XGETBV.  It doesn't seem too much of a stretch to
>> think that apps will see AMX enabled with XGETBV and them assume that
>> it's on the signal stack.
>>
>> Please tell me I'm being too paranoid.  If we can break this
>> assumption, it would get rid of a lot of future pain.
> There are no AMX apps. I sure hope that there are no apps that
> enumerate xfeatures with CPUID and try to decode the mess in the
> signal stack.

I don't think they quite need to decode it in order to be screwed over a
bit.  For instance, I don't think it's too crazy if someone did:

	xcr0 = xgetbv(0);
	xrstor(xcr0, &sig_stack[something]);
	// change some registers
	xsave(xcr0, &sig_stack[something]);

The XRSTOR would work fine, but the XSAVE would overflow the stack
because it would save the AMX state.  It also *looks* awfully benign.
This is true even if the silly signal handler didn't know about AMX at
*ALL*.

A good app would have checked that the xfeatures field in the header
matched xcr0.