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
next prev 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®