linux-kernel - Re: [PATCH v5 09/19] KVM:x86: Make guest supervisor states as non-XSAVE managed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2597a87b-1248-b8ce-ce60-94074bc67ea4@intel.com>
Date:   Mon, 28 Aug 2023 14:00:35 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Yang, Weijiang" <weijiang.yang@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>, peterz@...radead.org,
        Sean Christopherson <seanjc@...gle.com>
Cc:     Chao Gao <chao.gao@...el.com>, john.allen@....com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        rick.p.edgecombe@...el.com, binbin.wu@...ux.intel.com
Subject: Re: [PATCH v5 09/19] KVM:x86: Make guest supervisor states as
 non-XSAVE managed

On 8/10/23 08:15, Paolo Bonzini wrote:
> On 8/10/23 16:29, Dave Hansen wrote:
>> What actual OSes need this support?
> 
> I think Xen could use it when running nested.  But KVM cannot expose
> support for CET in CPUID, and at the same time fake support for
> MSR_IA32_PL{0,1,2}_SSP (e.g. inject a #GP if it's ever written to a
> nonzero value).
> 
> I suppose we could invent our own paravirtualized CPUID bit for
> "supervisor IBT works but supervisor SHSTK doesn't".  Linux could check
> that but I don't think it's a good idea.
> 
> So... do, or do not.  There is no try. :)

Ahh, that makes sense.  This is needed for implementing the
*architecture*, not because some OS actually wants to _do_ it.

...
>> In a perfect world, we'd just allocate space for CET_S in the KVM
>> fpstates.  The core kernel fpstates would have
>> XSTATE_BV[13]==XCOMP_BV[13]==0.  An XRSTOR of the core kernel fpstates
>> would just set CET_S to its init state.
> 
> Yep.  I don't think it's a lot of work to implement.  The basic idea as
> you point out below is something like
> 
> #define XFEATURE_MASK_USER_DYNAMIC XFEATURE_MASK_XTILE_DATA
> #define XFEATURE_MASK_USER_OPTIONAL \
>     (XFEATURE_MASK_DYNAMIC | XFEATURE_MASK_CET_KERNEL)
> 
> where XFEATURE_MASK_USER_DYNAMIC is used for xfd-related tasks
> (including the ARCH_GET_XCOMP_SUPP arch_prctl) but everything else uses
> XFEATURE_MASK_USER_OPTIONAL.
> 
> KVM would enable the feature by hand when allocating the guest fpstate.
> Disabled features would be cleared from EDX:EAX when calling
> XSAVE/XSAVEC/XSAVES.

OK, so let's _try_ this perfect-world solution.  KVM fpstates get
fpstate->xfeatures[13] set, but no normal task fpstates have that bit
set.  Most of the infrastructure should be there to handle this without
much fuss because it _should_ be looking at generic things like
fpstate->size and fpstate->features.

But who knows what trouble this will turn up.  It could get nasty and
not worth it, but we should at least try it.