From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16D302F26 for ; Mon, 7 Feb 2022 18:43:13 +0000 (UTC) Received: from zn.tnic (dslb-088-067-221-104.088.067.pools.vodafone-ip.de [88.67.221.104]) (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 24AE01EC02B9; Mon, 7 Feb 2022 19:43:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1644259387; 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=SZEc3K4WUssJFPuRZM4cYUdq0EX2pDa+Q3YePuI1VGc=; b=qmClInz1dKwfOZbiO2QrY2gZK/xZolImE900/WaPmxRFwwOa2cp3K4OMeOEJsTi80Hu4Qp G43sMx+xX8AUxdLvcgTvewjlRnNRSbTkdwsgOZ6e9vtHFY+GtTdk9DIq09oCjIgK1EE+5Z CRyqtdz0t/QXSU+RToQpc+wZ3krqc2c= Date: Mon, 7 Feb 2022 19:43:01 +0100 From: Borislav Petkov To: Michael Roth Cc: 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 , brijesh.singh@amd.com, Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , "Dr . David Alan Gilbert" , brijesh.ksingh@gmail.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH v9 38/43] x86/sev: Use firmware-validated CPUID for SEV-SNP guests Message-ID: References: <20220128171804.569796-1-brijesh.singh@amd.com> <20220128171804.569796-39-brijesh.singh@amd.com> <20220205171901.kt47bahdmh64b45x@amd.com> <20220207170018.sg37idc6nzlzgj6p@amd.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220207170018.sg37idc6nzlzgj6p@amd.com> On Mon, Feb 07, 2022 at 11:00:18AM -0600, Michael Roth wrote: > this is more a statement that an out-of-spec hypervisor should not > expect that their guests will continue working in future firmware > versions, and what's being determined here is whether to break > those out-of-spec hypervisor now, or later when/if we actually > make use of the fields in the guest code, I think you're missing a very important aspect here called reality. Let's say that HV is a huge cloud vendor who means a lot of $ and a huge use case for SEV tech. And let's say that same HV is doing those incompatible things. Now imagine you break it with the spec change. But they already have a gazillion of deployments on real hw which they can't simply update just like that. Hell, cloud vendors are even trying to dictate how CPU vendors should do microcode updates on a live system, without rebooting, and we're talking about some wimpy fields in some table. Now imagine your business unit calls your engineering and says, you need to fix this because a very persuasive chunk of money. What you most likely will end up with is an ugly ugly workaround after a lot of managers screaming at each other and you won't even think about breaking that HV. Now imagine you've designed it the right and unambiguous way from the getgo. You wake up and realize, it was all just a bad dream... > Ok, I'll follow up with the firmware team on this. But just to be clear, > what they're suggesting is that the firmware could enforce the MBZ checks > on the CPUID page, so out-of-spec hypervisors will fail immediately, > rather than in some future version of the spec/cpuid page, and guests > can continue ignoring them in the meantime. Yes, exactly. Fail immediately. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette