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 X-Spam-Level: X-Spam-Status: No, score=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60D62C47089 for ; Wed, 26 May 2021 17:27:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2E824613B9 for ; Wed, 26 May 2021 17:27:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232674AbhEZR2i (ORCPT ); Wed, 26 May 2021 13:28:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232134AbhEZR2i (ORCPT ); Wed, 26 May 2021 13:28:38 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 927A5C061756 for ; Wed, 26 May 2021 10:27:05 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id kr9so1184435pjb.5 for ; Wed, 26 May 2021 10:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CoNplCfjrcSDFcQORSZKbieGzoFc0tVb2QaR+5+KW4o=; b=R3RaDZ5pPOEcRrGF7YAc9kKiy/s8YyUZPVZigdVu56JdrWEZ5RJmXIqAm16XpdjKR0 RHaamhV47DtinB3cdibBoorf/HXghHZzXt8BWdNo7YmiN0xerI7l/seKjf5GGoDO802O ZROzCsrvp0XjrK3ceden6UztWmQE6kGxZ8PsNpXrO1uUiSxro+Lk9jVC7gMUgwJQY5Tg saSa4FplZV8oLd7y0oCsnxANWb1v8PXpi90I0ST+0zDogjRGn3gDlabhPfVHtp7IA6Ei +EdC22DACWxWz+d8HTDlioNk+VRu5OcO4q+yiY/KzqQgOu4FtMbA4bnzaMv5ZOTQFNQS t6OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CoNplCfjrcSDFcQORSZKbieGzoFc0tVb2QaR+5+KW4o=; b=nWPlWqnwLtvRLalrI8vfmGmVNTCjEtngoA3zSZk2bq5nWnVy22deulSSODVQWZ0Igv tpDviqv49hjVRf2T1OewIPaoycP9NsxGzYU3SHbfVQbDtMhGBpObigP/9lQk3hX8emvs oswllmUljIFqATYV08Wm8BdXtOJPhfyovinEVk96IhBiNBpqooKKS6e023vAWlVyln4K Ypr6lSTZJ7xKa8phTU6Z0jqYePzsMAgY3km9qP5eW8PAsGt9NMsq0xHKzuzVEdywVLTt BAbUlteIjDQWeWeNPST4PLv8wy5JiLBw9lobeF2N9x/iTK47qNMbA3J69FTXl04yZniz I9Ag== X-Gm-Message-State: AOAM531F36PjKlF467ZRmQExImyn0x+B89DWaMXUcVS19Wy+C5lkMMCE vCuSPfYPDOXTLMHHFrGWspNxQw== X-Google-Smtp-Source: ABdhPJya+m+m16xOAuZHqbYdFnytU2u2a+uxUSV+KpX0U1uXb08CAe/nSl/mBbQmPAtCbwDILB/v2g== X-Received: by 2002:a17:90a:9105:: with SMTP id k5mr37340618pjo.48.1622050024875; Wed, 26 May 2021 10:27:04 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id s3sm18479111pgs.62.2021.05.26.10.27.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 May 2021 10:27:04 -0700 (PDT) Date: Wed, 26 May 2021 17:27:00 +0000 From: Sean Christopherson To: Pu Wen Cc: x86@kernel.org, joro@8bytes.org, thomas.lendacky@amd.com, dave.hansen@linux.intel.com, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@suse.de, hpa@zytor.com, jroedel@suse.de, sashal@kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] x86/sev: Check whether SEV or SME is supported first Message-ID: References: <20210526072424.22453-1-puwen@hygon.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210526072424.22453-1-puwen@hygon.cn> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, May 26, 2021, Pu Wen wrote: > The first two bits of the CPUID leaf 0x8000001F EAX indicate whether > SEV or SME is supported respectively. It's better to check whether > SEV or SME is supported before checking the SEV MSR(0xc0010131) to > see whether SEV or SME is enabled. > > This also avoid the MSR reading failure on the first generation Hygon > Dhyana CPU which does not support SEV or SME. > > Fixes: eab696d8e8b9 ("x86/sev: Do not require Hypervisor CPUID bit for SEV guests") > Cc: # v5.10+ > Signed-off-by: Pu Wen > --- > arch/x86/mm/mem_encrypt_identity.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c > index a9639f663d25..470b20208430 100644 > --- a/arch/x86/mm/mem_encrypt_identity.c > +++ b/arch/x86/mm/mem_encrypt_identity.c > @@ -504,10 +504,6 @@ void __init sme_enable(struct boot_params *bp) > #define AMD_SME_BIT BIT(0) > #define AMD_SEV_BIT BIT(1) > > - /* Check the SEV MSR whether SEV or SME is enabled */ > - sev_status = __rdmsr(MSR_AMD64_SEV); > - feature_mask = (sev_status & MSR_AMD64_SEV_ENABLED) ? AMD_SEV_BIT : AMD_SME_BIT; > - > /* > * Check for the SME/SEV feature: > * CPUID Fn8000_001F[EAX] > @@ -519,11 +515,16 @@ void __init sme_enable(struct boot_params *bp) > eax = 0x8000001f; > ecx = 0; > native_cpuid(&eax, &ebx, &ecx, &edx); > - if (!(eax & feature_mask)) > + /* Check whether SEV or SME is supported */ > + if (!(eax & (AMD_SEV_BIT | AMD_SME_BIT))) Hmm, checking CPUID at all before MSR_AMD64_SEV is flawed for SEV, e.g. the VMM doesn't need to pass-through CPUID to attack the guest, it can lie directly. SEV-ES is protected by virtue of CPUID interception being reflected as #VC, which effectively tells the guest that it's (probably) an SEV-ES guest and also gives the guest the opportunity to sanity check the emulated CPUID values provided by the VMM. In other words, this patch is flawed, but commit eab696d8e8b9 was also flawed by conditioning the SEV path on CPUID.0x80000000. Given that #VC can be handled cleanly, the kernel should be able to handle a #GP at this point. So I think the proper fix is to change __rdmsr() to native_read_msr_safe(), or an open coded variant if necessary, and drop the CPUID checks for SEV. The other alternative is to admit that the VMM is still trusted for SEV guests and take this patch as is (with a reworded changelog). This probably has my vote, I don't see much value in pretending that the VMM can't exfiltrate data from an SEV guest. In fact, a malicious VMM is probably more likely to get access to interesting data by _not_ lying about SEV being enabled, because lying about SEV itself will hose the guest sooner than later. > return; > > me_mask = 1UL << (ebx & 0x3f); > > + /* Check the SEV MSR whether SEV or SME is enabled */ > + sev_status = __rdmsr(MSR_AMD64_SEV); > + feature_mask = (sev_status & MSR_AMD64_SEV_ENABLED) ? AMD_SEV_BIT : AMD_SME_BIT; > + > /* Check if memory encryption is enabled */ > if (feature_mask == AMD_SME_BIT) { > /* > -- > 2.23.0 >