linux-kernel - Re: [RESEND PATCH v10 02/10] vmx: spp: Add control flags for Sub-Page Protection(SPP)

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: <20200110165859.GB21485@linux.intel.com>
Date:   Fri, 10 Jan 2020 08:58:59 -0800
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Yang Weijiang <weijiang.yang@...el.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        pbonzini@...hat.com, jmattson@...gle.com,
        yu.c.zhang@...ux.intel.com, alazar@...defender.com,
        edwin.zhai@...el.com
Subject: Re: [RESEND PATCH v10 02/10] vmx: spp: Add control flags for
 Sub-Page Protection(SPP)

On Thu, Jan 02, 2020 at 02:13:11PM +0800, Yang Weijiang wrote:
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index e3394c839dea..5713e8a6224c 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -60,6 +60,7 @@
>  #include "vmcs12.h"
>  #include "vmx.h"
>  #include "x86.h"
> +#include "../mmu/spp.h"

The ".." should be unnecessary, e.g. x86.h is obviously a level up.

>  MODULE_AUTHOR("Qumranet");
>  MODULE_LICENSE("GPL");
> @@ -111,6 +112,7 @@ module_param_named(pml, enable_pml, bool, S_IRUGO);
>  
>  static bool __read_mostly dump_invalid_vmcs = 0;
>  module_param(dump_invalid_vmcs, bool, 0644);
> +static bool __read_mostly spp_supported = 0;

s/spp_supported/enable_spp to be consistent with all the other booleans.

Is there a reason this isn't exposed as a module param?

And if this is to be on by default, then the flag itself should be
initialized to '1' so that it's clear to readers that the feature is
enabled by default (if it's supported).  Looking at only this code, I would
think that SPP is forced off and can't be enabled.

That being said, turning on the enable_spp control flag should be the last
patch in the series, i.e. it shouldn't be turned on until all the
underlying support code is in place.  So, I would keep this as is, but
invert the code in hardware_setup() below.  That way the flag exists and
is checked, but can't be turned on without modifying the code.  Then when
all is said and done, you can add a patch to introduce the module param
and turn on the flag by default (if that's indeed what we want).

>  #define MSR_BITMAP_MODE_X2APIC		1
>  #define MSR_BITMAP_MODE_X2APIC_APICV	2
> @@ -2391,6 +2393,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf,
>  			SECONDARY_EXEC_RDSEED_EXITING |
>  			SECONDARY_EXEC_RDRAND_EXITING |
>  			SECONDARY_EXEC_ENABLE_PML |
> +			SECONDARY_EXEC_ENABLE_SPP |
>  			SECONDARY_EXEC_TSC_SCALING |
>  			SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE |
>  			SECONDARY_EXEC_PT_USE_GPA |
> @@ -4039,6 +4042,9 @@ static void vmx_compute_secondary_exec_control(struct vcpu_vmx *vmx)
>  	if (!enable_pml)
>  		exec_control &= ~SECONDARY_EXEC_ENABLE_PML;
>  
> +	if (!spp_supported)
> +		exec_control &= ~SECONDARY_EXEC_ENABLE_SPP;
> +
>  	if (vmx_xsaves_supported()) {
>  		/* Exposing XSAVES only when XSAVE is exposed */
>  		bool xsaves_enabled =
> @@ -7630,6 +7636,9 @@ static __init int hardware_setup(void)
>  	if (!cpu_has_vmx_flexpriority())
>  		flexpriority_enabled = 0;
>  
> +	if (cpu_has_vmx_ept_spp() && enable_ept)
> +		spp_supported = 1;

As above, invert this to disable spp when it's not supported, or when EPT
is disabled (or not supported).

> +
>  	if (!cpu_has_virtual_nmis())
>  		enable_vnmi = 0;
>  
> -- 
> 2.17.2
>