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

[Jan Beulich <jbeulich@suse.com>]

On 24.08.2022 14:19, Andrew Cooper wrote:
> On 24/08/2022 07:00, 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:
>>>>> 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.
> 
> It's not Xen's CPUID invocation which is relevant.  It's the guest
> kernels, which goes straight to hardware because AMD still doesn't have
> CPUID faulting.
> 
> And yes, right now none of Xen's CET state shows up in XSTATE, but that
> needs to change in order to support CET in HVM guests if we don't want
> an enormous extra overhead in the general context switch path.

Right. HVM guests, though, aren't affected by the CPUID limitation you
name for AMD. And PV guests could continue to be run with the bits off
in XSS (we need to context switch XSS and XCR0 anyway).

Jan