Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp812292iog; Wed, 15 Jun 2022 12:56:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ucHgjMTq1x3Rtmp0ACd4ELb8re596TVGiwAt/CmiDSDzD77Z+NFTyBD/L+J5AHXZLhF0kM X-Received: by 2002:a17:903:1208:b0:168:e42f:acf9 with SMTP id l8-20020a170903120800b00168e42facf9mr1281917plh.165.1655322984298; Wed, 15 Jun 2022 12:56:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655322984; cv=none; d=google.com; s=arc-20160816; b=Ys8FI6GTi/yLMUz2OfnvCXyhMkU139WVqGESsbfIoMKCPfsduqzEOu+49Vws6G695w PTqXW0xSlBnCNeAJVoulbyEc/jl1L6FiNpKou96EgPWmdRZjYSEMr18XO6j9TLUH1mIE mRjTfvp+ZVQv1uzITEvLXFYnOEKoVYj+LkDpCAgMQBmDa9RaMdZxdcvCosNwvGX8dYcZ Y3e0KC6ZJOXWOR9mSpMijqI5x7RMuxoen91MtAhBCVWRR15bgtGcu/Sj+khHLGdpLb23 v1L4yYu0kLq6vi4bIUlHtoOArdLUj2jcFVD0CiVDD4lOfmzFFHMA7CZJPJ/lRahJ9H1o q3jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=sD8IqB97I70LoLibTMokNd39/3wgDdyCaZhezBKenf0=; b=RGQr2USXmtITyzNKDpicQyoN8IwuFxfID6sJYgtx4g/TcBzg8Kl7nhcakh5MS2xzJw R8wXDvzAlBIzwz5Nhv1fEzdIWHQCkViy6WUQPKdIpjtjopBHXTEjU2GdLJGuwOUyfAzr 8VsRZrFpBrWx6k5qBaBqt3jQnduCjln2478JEqxDVjwiVh5YBIh9yL8ZAexUcCIJ0VMd uoDLt/xRPGo5VDd7CpXOFPbcPKUtrO2Tc/oADVXlCCiINQtaSiXwPIptQM7DfgE6+i2e ehwXaGMMX77WK5aYddoBdYi8BmzafbpDC6qcRiYHmVnFabIzDVFJ7al+o6LYzRvwGlDl y4HQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=DyKH3kuc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h13-20020a056a00170d00b00518984386ebsi137822pfc.37.2022.06.15.12.56.12; Wed, 15 Jun 2022 12:56:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=DyKH3kuc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347809AbiFOTfP (ORCPT + 99 others); Wed, 15 Jun 2022 15:35:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347369AbiFOTfO (ORCPT ); Wed, 15 Jun 2022 15:35:14 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 928F1340D1 for ; Wed, 15 Jun 2022 12:35:11 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id y29so14409189ljd.7 for ; Wed, 15 Jun 2022 12:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sD8IqB97I70LoLibTMokNd39/3wgDdyCaZhezBKenf0=; b=DyKH3kucgWByYnRSwlcv/ad2v9o/FLycAER5k5b3kHFwFUzuAEgM23y4XArIqyzH/V YTF9V80+outxXkkLFijzi+R+8GJYb515k3NH5VTRI5wUqc+/6nfYqtPy7VvQG88ylx82 DcDdtvG3cCEBeDOtI8QnddDLFhP+34VHvs/p1PCc+D7YfBYqTZyWdvi87+axb2jxAA/V Cp690LwLvz6+qpkvDid858R6u5J39vw/uN0/uY1QMq6euonnAErJN2p8wiUoo2aQEUu0 OofPnvvA+7VrlGlep8QvvPrBzZXFa8ugfSNgo91+BJOqHjnfpf+RzCSPsVuUGLEKBgrh YgvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sD8IqB97I70LoLibTMokNd39/3wgDdyCaZhezBKenf0=; b=JaxbkJ498318BZBJWvJVquanbFtWvmGQCIl6iNvU4HryzU01nXEFFn4HuX4ycvWYiT Ia9CjRPi9OUlbiItHFNTQ6vG3/2nCmKCoiLwDENLpb5RvSZQ4tTb0WKQuJE5T3aOPhKC 5lxrvdkbsmnAl6SKaXSd9Bbh/WoP8T4TTP/KfdHdBe1VuxsfBnlwXKg7or1YoV+VghcE qxqlKPcAtIF0xzbFLF+rL6Ih1OzrG4oQLzxIe1fLhqgDlVuPr+k2CpR5kWeZQY1ib2uM pOlnfz+oHqZE8AzbybNEs9OjTKANDDmLO4F4KC2jcISfQkp+VsqCEXl7nhCFW1Jalvnq U+fQ== X-Gm-Message-State: AJIora9mkbTLKYzkWbup8GCwF9k12YaBM0/iC3oowAdOXnTcmp0ZAxrW 14h2B0yTXI09TgAW3D8sJxnsQ6EP1BjWnU4U3TM= X-Received: by 2002:a05:651c:a04:b0:255:bf2e:72b9 with SMTP id k4-20020a05651c0a0400b00255bf2e72b9mr686193ljq.333.1655321709803; Wed, 15 Jun 2022 12:35:09 -0700 (PDT) MIME-Version: 1.0 References: <20220614210217.1940563-1-martin.fernandez@eclypsium.com> <20220615190519.GA1524500@alison-desk> In-Reply-To: <20220615190519.GA1524500@alison-desk> From: Richard Hughes Date: Wed, 15 Jun 2022 20:34:58 +0100 Message-ID: Subject: Re: [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS To: Alison Schofield Cc: Martin Fernandez , linux-kernel@vger.kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, mingo@redhat.com, tglx@linutronix.de, daniel.gutson@eclypsium.com, alex.bazhaniuk@eclypsium.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Jun 2022 at 20:06, Alison Schofield wrote: > My first reaction is lying about the cpuinfo is not a soln, since > it creates a problem for a users currently relying on cpuinfo to be > the source of truth for TME. I think you have to qualify "source of truth". At the moment the CPU reports "Yes! I support TME!" and then for one reason or another the platform turns it off and actually there's no memory encryption of your secrets at all. There's seemingly no userspace way of telling if TME is actually active. We were told that we shouldn't export the "platform has disabled a CPU feature" in sysfs and just to clear the cpuid flag that gets exported (like AMD is currently doing) which is what Martin proposed here. Programs want to know the true CPU capability can do __get_cpuid_count() like they can for the SME/SEV capabilities. > Are we to tell them to go look in the > log now, because fwupd folks didn't want to ;) We're not telling anyone to use the log; grepping megabytes of unformatted kernel logs is a terrible (and slow) way to get one boolean value. Richard.