From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH v4 70/75] x86/head/64: Don't call verify_cpu() on starting APs Date: Wed, 15 Jul 2020 17:48:56 +0200 Message-ID: <20200715154856.GA24822@suse.de> References: <20200714120917.11253-1-joro@8bytes.org> <20200714120917.11253-71-joro@8bytes.org> <202007141837.2B93BBD78@keescook> <20200715092638.GJ16200@suse.de> <202007150815.A81E879@keescook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <202007150815.A81E879@keescook> Sender: linux-kernel-owner@vger.kernel.org To: Kees Cook Cc: Joerg Roedel , x86@kernel.org, hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org List-Id: virtualization@lists.linuxfoundation.org Hi Kees, as a general note: With SEV-ES the guest kernel will get #VC exceptions for events that, without SEV-ES, would just cause a #VMEXIT to the hypervisor. On Wed, Jul 15, 2020 at 08:26:14AM -0700, Kees Cook wrote: > On Wed, Jul 15, 2020 at 11:26:38AM +0200, Joerg Roedel wrote: > > That MSR is Intel-only, right? The boot-path installed here is only used > > for SEV-ES guests, running on AMD systems, so this MSR is not even > > accessed during boot on those VMs. > > Oh, hrm, yes, that's true. If other x86 maintainers are comfortable with > this, then okay. My sense is that changing the early CPU startup paths > will cause trouble down the line. The AP startup path does not change for non SEV-ES guests. But under SEV-ES everything that might cause a #VC exception must be avoided until the kernel is ready to handle them. With the current patches this happens when the AP runs in 64bit long-mode and loaded TSS and IDT. Therefore a slightly different AP boot-path is needed for SEV-ES guests. > So, going back to the requirements here ... what things in verify_cpu() > can cause exceptions? AFAICT, cpuid is safely handled (i.e. it is > detected and only run in a way to avoid exceptions and the MSR > reads/writes are similarly bound by CPU family/id range checks). I must > be missing something. :) It is actually the CPUID instructions that cause #VC exceptions. The MSRs that are accessed on AMD processors are not intercepted in the hypervisors this code has been tested on, so these will not cause #VC exceptions. Regards, Joerg