From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33479C433FE for ; Thu, 21 Oct 2021 14:48:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 84340611CE for ; Thu, 21 Oct 2021 14:48:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 84340611CE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 155FE6B006C; Thu, 21 Oct 2021 10:48:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E00C900002; Thu, 21 Oct 2021 10:48:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9C2D6B0073; Thu, 21 Oct 2021 10:48:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id D4AC96B006C for ; Thu, 21 Oct 2021 10:48:16 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9AE1F1814C3D3 for ; Thu, 21 Oct 2021 14:48:16 +0000 (UTC) X-FDA: 78720724992.06.95A562F Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf13.hostedemail.com (Postfix) with ESMTP id 4B2D010432DB for ; Thu, 21 Oct 2021 14:48:11 +0000 (UTC) Received: from zn.tnic (p200300ec2f1912003b8abe7004197216.dip0.t-ipconnect.de [IPv6:2003:ec:2f19:1200:3b8a:be70:419:7216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id BF9201EC0554; Thu, 21 Oct 2021 16:48:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1634827693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=LFIuHJqA1Ok8eGxsQDk+FzhK+VwfVCIGalVILCtc6mM=; b=F5CjdLMt3ljZR1pMBN0I0I40KB+bqYCabnPHfamE/zWwBlD+b7GndmIPbxEEZdzMWYOKBc QQuBG9sOlY7F34hP3KevRm1q0eYMT4x8d02Rmzs4Q89yN+sDrxE0esRUINg416udbF0AgO b/qutwzImWXA1ZE5aFGniElqF/PQqiM= Date: Thu, 21 Oct 2021 16:48:16 +0200 From: Borislav Petkov To: Michael Roth Cc: Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v6 08/42] x86/sev-es: initialize sev_status/features within #VC handler Message-ID: References: <20211008180453.462291-1-brijesh.singh@amd.com> <20211008180453.462291-9-brijesh.singh@amd.com> <20211018184003.3ob2uxcpd2rpee3s@amd.com> <20211020161023.hzbj53ehmzjrt4xd@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211020161023.hzbj53ehmzjrt4xd@amd.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4B2D010432DB X-Stat-Signature: rz6jqfhhka866ef5a1rdn317swhighh6 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=F5CjdLMt; spf=pass (imf13.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de X-HE-Tag: 1634827691-873149 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote: > At which point we then switch to using the CPUID table? But at that > point all the previous CPUID checks, both SEV-related/non-SEV-related, > are now possibly not consistent with what's in the CPUID table. Do we > then revalidate? Well, that's a tough question. That's basically the same question as, does Linux support heterogeneous cores and can it handle hardware features which get enabled after boot. The perfect example is, late microcode loading which changes CPUID bits and adds new functionality. And the answer to that is, well, hard. You need to decide this on a case-by-case basis. But isn't it that the SNP CPUID page will be parsed early enough anyway so that kernel proper will see only SNP CPUID info and init properly using that? > Even a non-malicious hypervisor might provide inconsistent values > between the two sources due to bugs, or SNP validation suppressing > certain feature bits that hypervisor otherwise exposes, etc. There's also migration, lemme point to a very recent example: https://lore.kernel.org/r/20211021104744.24126-1-jane.malalane@citrix.com which is exactly what you say - a non-malicious HV taking care of its migration pool. So how do you handle that? > Now all the code after sme_enable() can potentially take unexpected > execution paths, where post-sme_enable() code makes assumptions about > pre-sme_enable() checks that may no longer hold true. So as I said above, if you parse SNP CPUID page early enough, you don't have to worry about feature rediscovery. Early enough means, before identify_boot_cpu(). -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette