Re: [PATCH] x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.08.2022 12:48, Andrew Cooper wrote:
> On 23/08/2022 10:27, Jan Beulich wrote:
>> On 23.08.2022 10:59, Andrew Cooper wrote:
>>> But this is going to further complicate my several-year-old series
>>> trying to get Xen's XSTATE handling into a position where we can start
>>> to offer supervisor states.
>> Where do you see further complication? The necessary fiddling with XSS
>> here would of course be dependent upon p->xstate.xsaves alone (or,
>> maybe better, on the set of enabled features in XSS being non-empty),
>> but that's simply another (inner) if().
>>
>> As an aside, I actually wonder what use the supplied size is to user
>> mode code when any XSS-controlled feature is enabled: They'd allocate
>> a needlessly large block of memory, as they would only be able to use
>> XSAVEC.
> 
> This field is an already known kernel=>user infoleak.  There are threads
> about it on LKML.
> 
> But it does highlight another problem.  This change does not fix Linux
> on AMD Zen3 hardware, where the kernel will find the CPUID value larger
> than it can calculate the size to be, because Xen's use of CET-SS will
> show up in the CPUID value.

Why would that be? We don't even have CET related defines for XCR0, so
we don't enable the states in XSS. And I don't see why we would. Even
for other XSTATE-managed but not XSTATE-enabled features we could
clear the respective bits around the CPUID invocation (just like we
may need to set some in XSS). We'd be in trouble only for any XSTATE-
enabled feature that we make use of ourselves.

Jan