Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1842799ybh; Mon, 20 Jul 2020 08:30:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvD5eKwdHYUhYfe3aNyZVZZVDZZ/Lv36JoBn+spamPNhSRXUV62wPRrEYaVBg2nVUbzWg6 X-Received: by 2002:a17:906:40d7:: with SMTP id a23mr20660234ejk.421.1595259031742; Mon, 20 Jul 2020 08:30:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595259031; cv=none; d=google.com; s=arc-20160816; b=pjxDqhmHUhIMXMm7pmlyfBjR6j+cmLcOpAa1Cj/Ek2F1ZmslIzl+mLS/SU60Nzs4FW Mx3EDZsq2L7Spmhy6HfEYHn+KRyYRM5eLQZJGCT3re/aUM+F0tGfuCf/IDy+W62eEMpu /HAZjbpS24zCdQEEoNfII+6KwnsCi7XeERuJ/VyKYjBFAXIgTVFtzmpb6yjReJQiQAKt DdESCn9HCYARkR2Vd6X58UABeDXv80M/fF9mzCyEZPX74vGGHFtjiArrTK4CWdDXc8s/ XITTDYjUobcHT/Pevyd95PNurs3oBc7zfrkcHDjlAb3bW0REmQ9WdEjM+qAqcf2cwF0x 6Ghg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=851ZG4Nh5lk2fNR5lKCym31f1RdIUffrc3sGyvXK2bw=; b=1C3f9joL1CJi8pwsrZEGuDfZMUlJlp5lk1AkHdkczn4VXM3zauDxNXic/nFQFyD/LZ LwKRd+XomlivCd0mGLTOwHaCufTLiF735PccByXja8G3+mDRtZMlL6FAxJoFx2A6n6/O YCgDuzyPrKOCa4YEwKbthq1u36owU+T6hdP/T/g0ITL82s75qIx7Fzpopw2q7BK3mygB 5Y8cqN+D1U/EtXyx3ZmRfxUqGiXkFWns5H8yj+EEUXupItICMpdAFzkZ9vjeNw6tIMUx 3ZYBmtLqYik3/RThaK1auvQtu96dv2LC5/mA0tt/1MQmn6qMF/VLWKGRN7npQlzcns+6 YZgg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f13si10947217edy.576.2020.07.20.08.30.08; Mon, 20 Jul 2020 08:30:31 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728476AbgGTPaC (ORCPT + 99 others); Mon, 20 Jul 2020 11:30:02 -0400 Received: from 8bytes.org ([81.169.241.247]:58142 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbgGTPaB (ORCPT ); Mon, 20 Jul 2020 11:30:01 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 4CFC6344; Mon, 20 Jul 2020 17:29:59 +0200 (CEST) Date: Mon, 20 Jul 2020 17:29:55 +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: <20200720152955.GA620@8bytes.org> References: <20200714120917.11253-1-joro@8bytes.org> <20200714120917.11253-71-joro@8bytes.org> <202007141837.2B93BBD78@keescook> <20200715092638.GJ16200@suse.de> <202007150815.A81E879@keescook> <20200715154856.GA24822@suse.de> <202007151244.315DCBAE@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202007151244.315DCBAE@keescook> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 15, 2020 at 12:49:23PM -0700, Kees Cook wrote: > Aaah. I see. Thanks for the details there. So ... can you add a bunch > more comments about why/when the new entry path is being used? I really > don't want to accidentally discover some unrelated refactoring down > the road (in months, years, unrelated to SEV, etc) starts to also skip > verify_cpu() on Intel systems. There had been a lot of BIOSes that set > this MSR to disable NX, and I don't want to repeat that pain: Linux must > never start an Intel CPU with that MSR set. :P Understood :) I added a comment above the label explaining why it is only used for SEV-ES guests and pointing out the importance of running verify_cpu() on all other systems, especially if they are Intel based. Regards, Joerg