From: Sean Christopherson <seanjc@google.com>
To: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Paolo Bonzini <pbonzini@redhat.com>,
tony.luck@intel.com, ak@linux.intel.com,
tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, kvm@vger.kernel.org,
Alyssa Milburn <alyssa.milburn@linux.intel.com>,
Daniel Sneddon <daniel.sneddon@linux.intel.com>,
antonio.gomez.iglesias@linux.intel.com
Subject: Re: [PATCH v3 6/6] KVM: VMX: Move VERW closer to VMentry for MDS mitigation
Date: Thu, 26 Oct 2023 14:22:58 -0700 [thread overview]
Message-ID: <ZTrYsls7ya5yOdSV@google.com> (raw)
In-Reply-To: <20231026204810.chvljddk6noxsuqi@desk>
On Thu, Oct 26, 2023, Pawan Gupta wrote:
> On Thu, Oct 26, 2023 at 12:30:55PM -0700, Sean Christopherson wrote:
> > > if (static_branch_unlikely(&vmx_l1d_should_flush))
> > > vmx_l1d_flush(vcpu);
> >
> > There's an existing bug here. vmx_1ld_flush() is not guaranteed to do a flush in
> > "conditional mode", and is not guaranteed to do a ucode-based flush
>
> AFAICT, it is based on the condition whether after a VMexit any
> sensitive data could have been touched or not. If L1TF mitigation
> doesn't consider certain data sensitive and skips L1D flush, executing
> VERW isn't giving any protection, since that data can anyways be leaked
> from L1D using L1TF.
That assumes vcpu->arch.l1tf_flush_l1d is 100% precise and accurate, which is most
definitely not the case. You're also preventing the admin from choosing between
being super paranoind (always flush L1D) and mostly paranoid (conditionally flush
L1D, always flush CPU buffers).
AIUI, flushing the L1D is crazy expensive compared to flushing the CPU buffers,
so it's entirely plausible for someone to want to choose the mostly paranoid
option.
Side topic, isn't the NMI path missing a call to kvm_set_cpu_l1tf_flush_l1d()?
> > /*
> > * The MMIO stale data vulnerability is a subset of the general MDS
> > * vulnerability, i.e. this is mutually exclusive with the VERW that's
> > * done just before VM-Enter. The vulnerability requires the attacker,
> > * i.e. the guest, to do MMIO, so this "clear" can be done earlier.
> > */
> > if (static_branch_unlikely(&mmio_stale_data_clear) &&
> > !cpu_buffers_flushed && kvm_arch_has_assigned_device(vcpu->kvm))
> > mds_clear_cpu_buffers();
>
> This is certainly better, but I don't know what scenario is this helping with.
Heh, that's host I feel about moving VERW to just before VM-Enter. I have a hard
time believing there's meaningful sensitive that's accessed in __vmx_vcpu_run().
The closest thing is probably CR2, but that's a very dubious vector since CR2 will
hold a guest value for most VM-Enters.
I'm not against moving VERW close to VM-Enter because it's relatively straightforward,
but if we're going to be super paranoid, why not go all the way and not have to
worry about what ifs?
next prev parent reply other threads:[~2023-10-26 21:23 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 20:52 [PATCH v3 0/6] Delay VERW Pawan Gupta
2023-10-25 20:52 ` [PATCH v3 1/6] x86/bugs: Add asm helpers for executing VERW Pawan Gupta
2023-10-25 21:10 ` Andrew Cooper
2023-10-25 21:28 ` Josh Poimboeuf
2023-10-25 21:30 ` Andrew Cooper
2023-10-25 21:49 ` Josh Poimboeuf
2023-10-25 22:07 ` Pawan Gupta
2023-10-25 22:13 ` Andrew Cooper
2023-10-27 13:48 ` Pawan Gupta
2023-10-27 14:12 ` Andrew Cooper
2023-10-27 14:24 ` Pawan Gupta
2023-10-26 13:44 ` Nikolay Borisov
2023-10-26 13:58 ` Andrew Cooper
2023-10-25 20:52 ` [PATCH v3 2/6] x86/entry_64: Add VERW just before userspace transition Pawan Gupta
2023-10-26 16:25 ` Nikolay Borisov
2023-10-26 19:29 ` Pawan Gupta
2023-10-26 19:40 ` Dave Hansen
2023-10-26 21:15 ` Pawan Gupta
2023-10-26 22:13 ` Pawan Gupta
2023-10-26 22:17 ` Dave Hansen
2023-10-25 20:53 ` [PATCH v3 3/6] x86/entry_32: " Pawan Gupta
2023-10-25 20:53 ` [PATCH v3 4/6] x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key Pawan Gupta
2023-10-25 20:53 ` [PATCH v3 5/6] KVM: VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH Pawan Gupta
2023-10-25 20:53 ` [PATCH v3 6/6] KVM: VMX: Move VERW closer to VMentry for MDS mitigation Pawan Gupta
2023-10-26 16:14 ` Nikolay Borisov
2023-10-26 19:07 ` Pawan Gupta
2023-10-26 19:30 ` Sean Christopherson
2023-10-26 20:17 ` Sean Christopherson
2023-10-26 21:27 ` Pawan Gupta
2023-10-26 20:48 ` Pawan Gupta
2023-10-26 21:22 ` Sean Christopherson [this message]
2023-10-26 22:03 ` Pawan Gupta
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=ZTrYsls7ya5yOdSV@google.com \
--to=seanjc@google.com \
--cc=ak@linux.intel.com \
--cc=alyssa.milburn@linux.intel.com \
--cc=antonio.gomez.iglesias@linux.intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=tony.luck@intel.com \
--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