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

[Andrew Cooper <Andrew.Cooper3@citrix.com>]

On 23/08/2022 13:01, Jan Beulich wrote:
> 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:
>>>> On 23/08/2022 07:42, Jan Beulich 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.
>>
>> Linux needs an adjustment from != to <= for this check.
> I was wondering about that too, but if I'm not mistaken the change you
> suggest is the opposite of what would be apparently safe there (against
> overrunning buffers). Hence it may take more than just the comparison
> type to be modified.

The issue is that the CPUID leaf reports the compressed size of
XCR0|XSS, which is >= what the XSAVEC instruction will write when it's
only operating on XCR0 states.

So either Linux trusts what it calculates from the other CPUID leaves,
and gets the compressed size right, or it needs to account for the fact
that in XenPV at least (probably UML too), that the CPUID leaf over-reports.

~Andrew