Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp549017ybh; Wed, 15 Jul 2020 08:50:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxlwxSs/2ZjozzDz9fZWg7vxVAEv1wudjnCCcm+5E332BSNCIDW0U1z+S8kBbCsDSB+PBGF X-Received: by 2002:a17:906:1a59:: with SMTP id j25mr9327002ejf.398.1594828235642; Wed, 15 Jul 2020 08:50:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594828235; cv=none; d=google.com; s=arc-20160816; b=QiY807PONoY8t5mFXMmRcM2vl+DHyUbQRaAOMyDxpyJdwsc+q7oADQqVELzkxlNU/c 7d8nQxgfk68p5QHPmN6BGgrWBKhujZOhqhwBuo/wjQ57ZemUt2BgryMxA6cX1DHcpvHT GMoOT6Duty8odjdkepPATaz2jEx/JwEsahzvwERlQKpHk8nCa/Z1LN1nt0tZPj9ZyqRj 80DYBaVUo3Loh+llBYYeV7dMrFSQ7JzrvWlIl+Rx8MtRv0fBqdXyfGglpJZPKe128PZG NV6/Ielh4ryBUYrtkr8NJNemnKNIshVFTbVpff5ecmJeVETzKRYuAXTVzkzQp+Y/Yry2 ZsMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=MXSGa733Lz3sU04cT/d80AVcVWZr9Eb8bS+5mYzP9Xw=; b=CyaETdnX0JQ8uQgfN3IAsuz4xES1c+WF1IwTMq4hIoCm1NuiqXNcEj3dksmM4ojyF2 J2P7RxbP0Hbjly3aGNLtarSCpt0yokgM1tZe28+VN9d9zwLO46uazqWaFrB0gHpKyITn lIdFth9rq1QMBC892SthMY8wz5KxlpcCGMAD070C6hUwv0sa0XtJ+pU+pd6g2Am8ar9x 1zW7+HrZcl51R2YetldCbHM1hbcBp6guo0L848HfwTkZeB3lRT04q27XpLtUNmBUO3vk SuDwn8TpraR1W+AcUNKbmzm765gtiqFFBsml4OE9sldkWAQOoC0eGHLg99FYctxitlGk eboQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bk19si1413622ejb.338.2020.07.15.08.50.05; Wed, 15 Jul 2020 08:50:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727036AbgGOPtB (ORCPT + 99 others); Wed, 15 Jul 2020 11:49:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:49944 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725867AbgGOPtA (ORCPT ); Wed, 15 Jul 2020 11:49:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 1FA51ABE4; Wed, 15 Jul 2020 15:49:02 +0000 (UTC) Date: Wed, 15 Jul 2020 17:48:56 +0200 From: Joerg Roedel 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 Subject: Re: [PATCH v4 70/75] x86/head/64: Don't call verify_cpu() on starting APs 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 Content-Disposition: inline In-Reply-To: <202007150815.A81E879@keescook> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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