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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z739wdGmk4ZuWJ8v@google.com>
Date: Tue, 25 Feb 2025 09:28:33 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Xin Li <xin@...or.com>
Cc: Chao Gao <chao.gao@...el.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org, pbonzini@...hat.com, corbet@....net, 
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, luto@...nel.org, 
	peterz@...radead.org, andrew.cooper3@...rix.com
Subject: Re: [PATCH v3 03/27] KVM: VMX: Add support for the secondary VM exit controls

On Tue, Oct 22, 2024, Xin Li wrote:
> > > > > 		_vmentry_control &= ~n_ctrl;
> > > > > 		_vmexit_control &= ~x_ctrl;
> > > > 
> > > > w/ patch 4, VM_EXIT_ACTIVATE_SECONDARY_CONTROLS is cleared if FRED fails in the
> > > > consistent check. this means, all features in the secondary vm-exit controls
> > > > are removed. it is overkill.
> > > 
> > > Good catch!
> > > 
> > > > 
> > > > I prefer to maintain a separate table for the secondary VM-exit controls:
> > > > 
> > > >    	struct {
> > > >    		u32 entry_control;
> > > >    		u64 exit2_control;
> > > > 	} const vmcs_entry_exit2_pairs[] = {
> > > > 		{ VM_ENTRY_LOAD_IA32_FRED, SECONDARY_VM_EXIT_SAVE_IA32_FRED |
> > > > 					   SECONDARY_VM_EXIT_LOAD_IA32_FRED},
> > > > 	};
> > > > 
> > > > 	for (i = 0; i < ARRAY_SIZE(vmcs_entry_exit2_pairs); i++) {
> > > > 	...
> > > > 	}
> > > 
> > > Hmm, I prefer one table, as it's more straight forward.

Heh, that's debatable.  Also, calling these triplets is *very* misleading.

> > One table is fine if we can fix the issue and improve readability. The three
> > nested if() statements hurts readability.
> 
> You're right!  Let's try to make it clearer.

I agree with Chao, two tables provides better separation, which makes it easier
to follow what's going on, and avoids "polluting" every entry with empty fields.

If it weren't for the new controls supporting 64 unique bits, and the need to
clear bits in KVM's controls, it'd be trivial to extract processing to a helper
function.  But, it's easy enough to solve that conundrum by using a macro instead
of a function.  And as a bonus, a macro allows for adding compile-time assertions
to detect typos, e.g. can detect if KVM passes in secondary controls (u64) pairs
with the primary controls (u32) variable.

I'll post the attached patch shortly.  I verified it works as expected with a
simulated "bad" FRED CPU.

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index c9e5576d99d0..4717d48eabe8 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2621,6 +2621,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
        u32 _vmentry_control = 0;
        u64 basic_msr;
        u64 misc_msr;
+       u64 _vmexit2_control = BIT_ULL(1);
 
        /*
         * LOAD/SAVE_DEBUG_CONTROLS are absent because both are mandatory.
@@ -2638,6 +2639,13 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
                { VM_ENTRY_LOAD_IA32_RTIT_CTL,          VM_EXIT_CLEAR_IA32_RTIT_CTL },
        };
 
+       struct {
+               u32 entry_control;
+               u64 exit_control;
+       } const vmcs_entry_exit2_pairs[] = {
+               { 0x00800000,                           BIT_ULL(0) | BIT_ULL(1) },
+       };
+
        memset(vmcs_conf, 0, sizeof(*vmcs_conf));
 
        if (adjust_vmx_controls(KVM_REQUIRED_VMX_CPU_BASED_VM_EXEC_CONTROL,
@@ -2728,6 +2736,12 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
                                       _vmentry_control, _vmexit_control))
                return -EIO;
 
+       if (vmx_check_entry_exit_pairs(vmcs_entry_exit2_pairs,
+                                      _vmentry_control, _vmexit2_control))
+               return -EIO;
+
+       WARN_ON_ONCE(_vmexit2_control);
+
        /*
         * Some cpus support VM_{ENTRY,EXIT}_IA32_PERF_GLOBAL_CTRL but they
         * can't be used due to an errata where VM Exit may incorrectly clear

View attachment "0001-KVM-VMX-Extract-checks-on-entry-exit-control-pairs-t.patch" of type "text/x-diff" (4753 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ