linux-kernel - Re: [PATCH 08/28] KVM: nSVM: Use dedicated array of MSRPM offsets to merge L0 and L1 bitmaps

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: <aEBrAbhRFkou4Mvj@google.com>
Date: Wed, 4 Jun 2025 08:49:21 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Borislav Petkov <bp@...en8.de>, Xin Li <xin@...or.com>, Chao Gao <chao.gao@...el.com>, 
	Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: Re: [PATCH 08/28] KVM: nSVM: Use dedicated array of MSRPM offsets to
 merge L0 and L1 bitmaps

On Wed, Jun 04, 2025, Paolo Bonzini wrote:
> On 5/30/25 01:39, Sean Christopherson wrote:
> > Use a dedicated array of MSRPM offsets to merge L0 and L1 bitmaps, i.e. to
> > merge KVM's vmcb01 bitmap with L1's vmcb12 bitmap.  This will eventually
> > allow for the removal of direct_access_msrs, as the only path where
> > tracking the offsets is truly justified is the merge for nested SVM, where
> > merging in chunks is an easy way to batch uaccess reads/writes.
> > 
> > Opportunistically omit the x2APIC MSRs from the merge-specific array
> > instead of filtering them out at runtime.
> > 
> > Note, disabling interception of XSS, EFER, PAT, GHCB, and TSC_AUX is
> > mutually exclusive with nested virtualization, as KVM passes through the
> > MSRs only for SEV-ES guests, and KVM doesn't support nested virtualization
> > for SEV+ guests.  Defer removing those MSRs to a future cleanup in order
> > to make this refactoring as benign as possible.
> > 
> > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> > ---
> >   arch/x86/kvm/svm/nested.c | 72 +++++++++++++++++++++++++++++++++------
> >   arch/x86/kvm/svm/svm.c    |  4 +++
> >   arch/x86/kvm/svm/svm.h    |  2 ++
> >   3 files changed, 67 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> > index 89a77f0f1cc8..e53020939e60 100644
> > --- a/arch/x86/kvm/svm/nested.c
> > +++ b/arch/x86/kvm/svm/nested.c
> > @@ -184,6 +184,64 @@ void recalc_intercepts(struct vcpu_svm *svm)
> >   	}
> >   }
> > +static int nested_svm_msrpm_merge_offsets[9] __ro_after_init;
> > +static int nested_svm_nr_msrpm_merge_offsets __ro_after_init;
> > +
> > +int __init nested_svm_init_msrpm_merge_offsets(void)
> > +{
> > +	const u32 merge_msrs[] = {
> 
> "static const", please.

Ugh, I was thinking the compiler would be magical enough to not generate code to
fill an on-stack array at runtime, but that's not the case.

AFAICT, tagging it __initdata works, so I'll do this to hopefully ensure the
memory is discarded after module load.

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index fb4808cf4711..af530f45bf64 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -205,7 +205,7 @@ static int svm_msrpm_offset(u32 msr)
 
 int __init nested_svm_init_msrpm_merge_offsets(void)
 {
-       const u32 merge_msrs[] = {
+       static const u32 __initdata merge_msrs[] = {
                MSR_STAR,
                MSR_IA32_SYSENTER_CS,
                MSR_IA32_SYSENTER_EIP,