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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 E8C2BC47080 for ; Tue, 1 Jun 2021 18:08:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C8F4861026 for ; Tue, 1 Jun 2021 18:08:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234653AbhFASKI (ORCPT ); Tue, 1 Jun 2021 14:10:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231726AbhFASKG (ORCPT ); Tue, 1 Jun 2021 14:10:06 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8688BC06174A for ; Tue, 1 Jun 2021 11:08:24 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id k5so171909pjj.1 for ; Tue, 01 Jun 2021 11:08:24 -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=DnmoH9bekRYpYwPbGnzt8MqfxFmGQVDBVeFrYtSfJAg=; b=jNgEdYIMirBHf1RlWUpV+0XMt7t6M9Qb3u+Dm5b2Ko72L5Q/aswYluWEgM0Cf1LWE4 hZ4M7fWl9C2A90MzYiCfu3In2kwCEUcJN5Zc0GAfv75NTC6ApAs0DyLtLGT5urQTNFrG 7bLFUJEzE9nVbsd9R+hdLTvVTbmopnWQzV0xR04k/6p3ClNRirj1x4wRe6nIlNCbWV4P eWrRfI9TcM8sHd6WRL1CPUWeYcmxdECAYdhZRpp9sQDHsU7hqycvpMxzdAFmdAg7h53z dCD/VRxEBLWSQ8ecq+4dmDVENZe1rttV1r5JRy+1TOOdWU1A5y1e0hi3zd5sn6bMbQ4K eI/w== 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=DnmoH9bekRYpYwPbGnzt8MqfxFmGQVDBVeFrYtSfJAg=; b=lzjzzQ5qc5hN8kG5WnP7T+Yb+hIUoJTDe8Fi5FM6Pg/GkfjUsfgH5D9y3dxuKh0qs6 DQGIPBCiH7kDn1eyrznEFdpXZ1ojiBv343N12+LiJQvFk46BkZS9yYFeSgmDDxugrpjs UjUkI07Ob/GtQ7xadzQxpPSDY2IwZiKMM7YReCRiltbT1l8Tp8FLBxAY0EFU30leTvNb KhMq3IizVJ7BILdE2hr4mP9RdebHV4SizqnLNtw6BAbm0MICarofhGiFKy19I5D6bNza DsHUJ7MLw8n0QR5wsn6O6HWjM9xFZuMsgR6GYpYz2ogofu7bTOQW4znnUuHcoDEy84VZ Tm4w== X-Gm-Message-State: AOAM53228G09fw89KXN2jWDjwyRZoqVvzlsurjuBSw9RaN356KJia+pq NAe9F+LpXBO7xwBXiUSefyLQLA== X-Google-Smtp-Source: ABdhPJxKXC66gotDOyho4nO17wIW1CBqdGqeINp4HW5tpxGXIBnz8OWQp2+0yigdIN5+oThSwjq6Qg== X-Received: by 2002:a17:90b:17c9:: with SMTP id me9mr1124647pjb.13.1622570903889; Tue, 01 Jun 2021 11:08:23 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id mr23sm909701pjb.12.2021.06.01.11.08.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 11:08:23 -0700 (PDT) Date: Tue, 1 Jun 2021 18:08:19 +0000 From: Sean Christopherson To: Borislav Petkov Cc: Tom Lendacky , Pu Wen , Joerg Roedel , x86@kernel.org, joro@8bytes.org, dave.hansen@linux.intel.com, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, 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: <905ecd90-54d2-35f1-c8ab-c123d8a3d9a0@hygon.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 01, 2021, Borislav Petkov wrote: > On Tue, Jun 01, 2021 at 05:16:12PM +0000, Sean Christopherson wrote: > > The bug isn't limited to out-of-spec hardware. At the point of #GP, sme_enable() > > has only verified the max leaf is greater than 0x8000001f, it has not verified > > that 0x8000001f is actually supported. The APM itself declares several leafs > > between 0x80000000 and 0x8000001f as reserved/unsupported, so we can't argue that > > 0x8000001f must be supported if the max leaf is greater than 0x8000001f. > > If a hypervisor says that 0x8000001f is supported but then we explode > when reading MSR_AMD64_SEV, then hypervisor gets to keep both pieces. But in my scenario, the hypervisor has not said that 0x8000001f is valid, it has only said that at least one leaf > 0x8000001f is valid. E.g. if a (virtual) CPU supports CPUID ranges: 0x80000000 - 0x8000000A 0x80000020 - 0x80000021 then the below check will pass as eax will be 0x80000021. /* Check for the SME/SEV support leaf */ eax = 0x80000000; ecx = 0; native_cpuid(&eax, &ebx, &ecx, &edx); if (eax < 0x8000001f) return; But we have not yet verified that 0x8000001f is supported, only that the result of CPUID.0x8000001f can be trusted (to handle Intel CPUs which return data from the highest supported leaf if the provided leaf function is greater than the max supported leaf). Verifying that 0x8000001f is supported doesn't happen until 0x8000001f is actually read, which is currently done after the RDMSR that #GPs and explodes. > We're not going to workaround all possible insane hardware/hypervisor > configurations just because they dropped the ball. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette