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: <YKwbz3zuPhR7u1dw@google.com>
Date:   Mon, 24 May 2021 21:34:07 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Jing Liu <jing2.liu@...ux.intel.com>
Cc:     pbonzini@...hat.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, jing2.liu@...el.com
Subject: Re: [PATCH RFC 1/7] kvm: x86: Expose XFD CPUID to guest

I need a formletter for these...

GET_SUPPORTED_CPUID advertises support to userspace, it does not expose anything
to the guest.

On Sun, Feb 07, 2021, Jing Liu wrote:
> Intel's Extended Feature Disable (XFD) feature is an extension
> to the XSAVE feature that allows an operating system to enable
> a feature while preventing specific user threads from using
> the feature. A processor that supports XFD enumerates
> CPUID.(EAX=0DH,ECX=1):EAX[4] as 1.
> 
> Signed-off-by: Jing Liu <jing2.liu@...ux.intel.com>
> ---
>  arch/x86/kvm/cpuid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 83637a2ff605..04a73c395c71 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -437,7 +437,7 @@ void kvm_set_cpu_caps(void)
>  	);
>  
>  	kvm_cpu_cap_mask(CPUID_D_1_EAX,
> -		F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES)
> +		F(XSAVEOPT) | F(XSAVEC) | F(XGETBV1) | F(XSAVES) | F(XFD)

KVM must not advertise support until it actually has said support, i.e. this
patch needs to go at the end of the series.

Also, adding the kvm_cpu_cap flag in a separate patch isn't strictly required.
In most cases, I would go so far as to say that if there is additional enabling
to be done, advertising the feature should be done in the same patch that adds
the last bits of enabling.  Putting the CPUID stuff in its own patch doesn't
usually add values, e.g. if there's a bug in the actual support code bisecting
will point at the wrong patch if userspace conditions its vCPU model on
GET_SUPPORTED_CPUID.

>  	);
>  
>  	kvm_cpu_cap_mask(CPUID_8000_0001_ECX,
> -- 
> 2.18.4
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ