Messages in this thread | | | Subject | Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state | From | Dave Hansen <> | Date | Wed, 24 Mar 2021 14:58:07 -0700 |
| |
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.
| |