mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: mlevitsk@redhat.com
To: kvm@vger.kernel.org
Cc: Sean Christopherson <seanjc@google.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	 linux-kernel@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	 x86@kernel.org
Subject: Re: [PATCH v3 0/2] Fix for a very old KVM bug in the segment cache
Date: Fri, 02 Aug 2024 18:33:20 +0300	[thread overview]
Message-ID: <6d043ba2be415fae75d0789d1b7b4d432032a113.camel@redhat.com> (raw)
In-Reply-To: <20240725175232.337266-1-mlevitsk@redhat.com>

У чт, 2024-07-25 у 13:52 -0400, Maxim Levitsky пише:
> Hi,
> 
> Recently, while trying to understand why the pmu_counters_test
> selftest sometimes fails when run nested I stumbled
> upon a very interesting and old bug:
> 
> It turns out that KVM caches guest segment state,
> but this cache doesn't have any protection against concurrent use.
> 
> This usually works because the cache is per vcpu, and should
> only be accessed by vCPU thread, however there is an exception:
> 
> If the full preemption is enabled in the host kernel,
> it is possible that vCPU thread will be preempted, for
> example during the vmx_vcpu_reset.
> 
> vmx_vcpu_reset resets the segment cache bitmask and then initializes
> the segments in the vmcs, however if the vcpus is preempted in the
> middle of this code, the kvm_arch_vcpu_put is called which
> reads SS's AR bytes to determine if the vCPU is in the kernel mode,
> which caches the old value.
> 
> Later vmx_vcpu_reset will set the SS's AR field to the correct value
> in vmcs but the cache still contains an invalid value which
> can later for example leak via KVM_GET_SREGS and such.
> 
> In particular, kvm selftests will do KVM_GET_SREGS,
> and then KVM_SET_SREGS, with a broken SS's AR field passed as is,
> which will lead to vm entry failure.
> 
> This issue is not a nested issue, and actually I was able
> to reproduce it on bare metal, but due to timing it happens
> much more often nested. The only requirement for this to happen
> is to have full preemption enabled in the kernel which runs the selftest.
> 
> pmu_counters_test reproduces this issue well, because it creates
> lots of short lived VMs, but the issue as was noted
> about is not related to pmu.
> 
> To paritally fix this issue, call vmx_segment_cache_clear
> after we done with segment register setup in vmx_vcpu_reset.
> 
> V2: incorporated Paolo's suggestion of having
>     vmx_write_segment_cache_start/end functions  (thanks!)
> 
> V3: reverted to a partial fix.
> 
> Best regards,
>         Maxim Levitsky
> 
> Maxim Levitsky (2):
>   KVM: nVMX: use vmx_segment_cache_clear
>   VMX: reset the segment cache after segment initialization in
>     vmx_vcpu_reset
> 
>  arch/x86/kvm/vmx/nested.c |  3 ++-
>  arch/x86/kvm/vmx/vmx.c    | 10 +++-------
>  arch/x86/kvm/vmx/vmx.h    |  5 +++++
>  3 files changed, 10 insertions(+), 8 deletions(-)
> 
> -- 
> 2.26.3
> 
> 

Any update?

Best regards,
	Maxim Levitsky


  parent reply	other threads:[~2024-08-02 15:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25 17:52 Maxim Levitsky
2024-07-25 17:52 ` [PATCH v3 1/2] KVM: nVMX: use vmx_segment_cache_clear Maxim Levitsky
2024-07-25 17:52 ` [PATCH v3 2/2] VMX: reset the segment cache after segment initialization in vmx_vcpu_reset Maxim Levitsky
2024-08-06  1:18   ` Chao Gao
2024-08-09 15:27     ` Sean Christopherson
2024-09-09 19:11       ` Maxim Levitsky
2024-09-10  1:07         ` Maxim Levitsky
2024-09-25 15:08           ` Sean Christopherson
2024-09-25 17:05             ` Maxim Levitsky
2024-09-25 18:30               ` Sean Christopherson
2024-08-02 15:33 ` mlevitsk [this message]
2024-08-02 16:07   ` [PATCH v3 0/2] Fix for a very old KVM bug in the segment cache Sean Christopherson
2024-08-23 23:48 ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d043ba2be415fae75d0789d1b7b4d432032a113.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®