[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <de679a1f-8a6d-6db2-d891-6069ed4cb33e@redhat.com>
Date: Wed, 16 Sep 2020 18:54:57 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: Borislav Petkov <bp@...en8.de>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Dave Hansen <dave.hansen@...el.com>,
Chang Seok Bae <chang.seok.bae@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Sasha Levin <sashal@...nel.org>,
kvm list <kvm@...r.kernel.org>,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH] x86/entry/64: Disallow RDPID in paranoid entry if KVM is
enabled
On 22/08/20 18:42, Andy Lutomirski wrote:
> On VMX, when a VM exits, the VM's
> value of MSR_TSC_AUX is live, and we can take an NMI, MCE, or
> abominable new #SX, #VE, #VC, etc on the next instruction boundary.
> And unless we use the atomic MSR switch mechanism, the result is that
> we're going through the entry path with guest-controlled MSRs.
If anything of that is a problem, we can and will use the atomic MSR
switching; it's not worth doing complicated stuff if you're going to pay
the price of rdmsr/wrmsr anyway.
The remaining cases are MSRs that are really meant for usermode (such as
the syscall MSRs) and especially the edge cases of these two MSRs that
the kernel doesn't mind too much about. But they are really really
rare, I don't expect any new one coming soon and if they are ever needed
(by SGX perhaps?!?) I'll certainly loop you guys in.
Paolo
Powered by blists - more mailing lists