linux-kernel - Re: [PATCH v3 05/15] KVM: VMX: Rename XSAVES control to follow KVM's preferred "ENABLE

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: <ZNzZ/vpK6lgvc62d@google.com>
Date:   Wed, 16 Aug 2023 07:15:26 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Zeng Guang <guang.zeng@...el.com>,
        Yuan Yao <yuan.yao@...el.com>
Subject: Re: [PATCH v3 05/15] KVM: VMX: Rename XSAVES control to follow KVM's
 preferred "ENABLE_XYZ"

On Wed, Aug 16, 2023, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@...gle.com> writes:
> > diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> > index 0d02c4aafa6f..0e73616b82f3 100644
> > --- a/arch/x86/include/asm/vmx.h
> > +++ b/arch/x86/include/asm/vmx.h
> > @@ -71,7 +71,7 @@
> >  #define SECONDARY_EXEC_RDSEED_EXITING		VMCS_CONTROL_BIT(RDSEED_EXITING)
> >  #define SECONDARY_EXEC_ENABLE_PML               VMCS_CONTROL_BIT(PAGE_MOD_LOGGING)
> >  #define SECONDARY_EXEC_PT_CONCEAL_VMX		VMCS_CONTROL_BIT(PT_CONCEAL_VMX)
> > -#define SECONDARY_EXEC_XSAVES			VMCS_CONTROL_BIT(XSAVES)
> > +#define SECONDARY_EXEC_ENABLE_XSAVES		VMCS_CONTROL_BIT(XSAVES)
> >  #define SECONDARY_EXEC_MODE_BASED_EPT_EXEC	VMCS_CONTROL_BIT(MODE_BASED_EPT_EXEC)
> >  #define SECONDARY_EXEC_PT_USE_GPA		VMCS_CONTROL_BIT(PT_USE_GPA)
> >  #define SECONDARY_EXEC_TSC_SCALING              VMCS_CONTROL_BIT(TSC_SCALING)
> 
> To avoid the need to make up these names in KVM we can probably just
> stick to SDM; that would make it easier to make a connection between KVM
> and Intel docs if needed. E.g. SDM uses "Use TSC scaling" so this
> could've been "SECONDARY_EXEC_USE_TSC_SCALING" for consistency.
> 
> Unfortunatelly, SDM itself is not very consistent in the naming,
> e.g. compare "WBINVD exiting"/"RDSEED exiting" with "Enable ENCLS
> exiting"/"Enable ENCLV exiting" but I guess we won't be able to do
> significantly better in KVM anyways..

Heh, I agree that we should default to whatever the SDM uses, but I disagree with
the assertion that KVM can't do better.  Every once in a while the SDM ends up with
a name that is weirdly different for no obvious reason, or aggressively abbreviated
to the point where the "name" is completely inscrutable without an absurb amount of
context (I've mostly seen this with MSR bits).

In those cases I think we should exercise common sense and deviate from the SDM,
e.g. in the outliers you pointed out, omit the "ENABLE" from the ENCLS/ENCLV flags.