Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4326642imw; Tue, 12 Jul 2022 06:11:32 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tyi985uU/FyQfkTqQVCGHvMORoGjhi1CDOZ9635MNL8DaA5w417Bc8Wtzw1F5TXjJz4kxw X-Received: by 2002:a17:906:14d:b0:711:ff36:b1af with SMTP id 13-20020a170906014d00b00711ff36b1afmr23810112ejh.422.1657631492598; Tue, 12 Jul 2022 06:11:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657631492; cv=none; d=google.com; s=arc-20160816; b=Q0CDqDLCxKNMvaIc1E+0/gKw56PJOohwgfG6E6LiOl7Ch/W7SrS85YPVHWtpHy+x8k JhYk+FWR7rnvXx8iQjBY4FPrxUOJIYSso72hb6LUrWtJQ+dXANqqhmuJarniJqpRT+O7 KbO5Xb7XhxZyPT3TrXDX7DNJTcoB5kNCdl/POVM+WKGja7sBS9laqCjBqxmepokD/PK4 DcyTDHQZ0tS0yolqK0BOSJ8WvV/Rmr9ep7cb5WRe721YDFR8vjFySWuwLYxtOnn0gXGR IU7+DOiR9xszwfQ8rsUJ1ykVO8IR1mxzUD98TQt9aGdaq52ZQJr6WL6N1ISAALrB/0PC Rd3Q== 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:references :in-reply-to:mime-version:dkim-signature; bh=Yw8dFDRTfEK72s1TvEU5mH4jhRhU2cchPv1Xp0OufHI=; b=CgpTZkxhm+A8XK6XBpnx+8pShJnD4myuDMl8/8/nYsPjDwcgNZsIIESqee2ch3M6SE aB5iQvZOjN2fxUUkkzj54j6ouwqkDKGJjUH2BFwFKJtZREFtCadcNelCkjXOPgfspl55 QtPdYyeOYDb/K59o7tmeKN22U2kcloi5Cmmpm4grezA2oYgqj4qvJXG9hxLmWB32voLb dA0OzBzQKTHqHBHJgLfNwcR4YRfMcJz/VIX/0mAVE9+QkMArtulgawLn5vm07X4hlsmo Qf8neahv+vxTCbEVmkWkMg2PImSNiT1EsGMnh5K3J3ocxyDgajGU7np6p3EBrmh6V2hx JtzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@eclypsium.com header.s=google header.b=CDi6GzUd; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=eclypsium.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b23-20020aa7df97000000b0043ab4f56513si13288390edy.592.2022.07.12.06.11.07; Tue, 12 Jul 2022 06:11:32 -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=@eclypsium.com header.s=google header.b=CDi6GzUd; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=eclypsium.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232075AbiGLM74 (ORCPT + 99 others); Tue, 12 Jul 2022 08:59:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbiGLM7z (ORCPT ); Tue, 12 Jul 2022 08:59:55 -0400 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E4CC2A709 for ; Tue, 12 Jul 2022 05:59:54 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id p129so13787063yba.7 for ; Tue, 12 Jul 2022 05:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yw8dFDRTfEK72s1TvEU5mH4jhRhU2cchPv1Xp0OufHI=; b=CDi6GzUd9o+Bp0LEGfow73v9sBErIFdvMxHm3LFd2Y7PQ/djhXmUcMBUARB0TBsBGJ 3WWNlR3xVPfAVN0ZdXPZmMWY3If1UOc7GqwkJDmRWCNVQF7nj0prrk4nupHSh1laqrle 0LJtME793vgTfUsyAdboZ5Z9AI407GmBu39tidCiiiPsOSCw/XdlAlwgYk1wYwHtriDF 7wZj5OFLOQ3l0lbfMdejd1Lp8MPYOrnqFfzc+SnWSqRdDOrbIaSBN3NIIFXQjoXHEgNe ffJXun5HW1Gfroy4LnONNvkwNfuQIYI3R//T+y6qT1dHfCXiMgYfUvDo6TUCMAZ+PpBE ijqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yw8dFDRTfEK72s1TvEU5mH4jhRhU2cchPv1Xp0OufHI=; b=V+AgqH+zFqHTzSOlSGP/UsjRGvLqciseZMeOfFOEmsBOD166G0UlHLB4kipBqFB5Jo BDIkSV0DSfyUIlKHJ5Meophmr99+Kbzodgvo7M3YPt6vx6I5+KXnNqCYFjjc3X2l06w9 gVYNhg3kvUgHxbwCwBUdKh6pKjm041ZqSVblr9dH9ZYvWxl7tzhmn95ypJX56o/hEkjj jc3kH04naFAHcxvPdyVuWk+DCHZj1s9cJbQcIeazVfvIiorxvVjS/bnOFEP54sM/9K2q mSi89ocdmNyAYyKdXfOrH2ITj1C7yzaOeFDvAsubCLS1EIbabOy1VMak6w1VhNFHSUhx qBJg== X-Gm-Message-State: AJIora/AL4faBP6+/6sePpTRrnSUOvLpImdrUbjL/fjNQLN8oJJRn5cg fxC6stRBg4HbA65yaPZ2XWOVBEHtyCq4ri1/MeP7bQ1R90M= X-Received: by 2002:a25:50d0:0:b0:66e:dd92:8170 with SMTP id e199-20020a2550d0000000b0066edd928170mr20595373ybb.311.1657630793297; Tue, 12 Jul 2022 05:59:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:b507:0:0:0:0:0 with HTTP; Tue, 12 Jul 2022 05:59:52 -0700 (PDT) In-Reply-To: <07ff13d590cf290a14232fb113ff4183a6fa352d.camel@intel.com> References: <20220704142250.1512726-1-martin.fernandez@eclypsium.com> <8d2a3175be8a3aff1d3fc535dd9ab6217cfe1e66.camel@intel.com> <07ff13d590cf290a14232fb113ff4183a6fa352d.camel@intel.com> From: Martin Fernandez Date: Tue, 12 Jul 2022 09:59:52 -0300 Message-ID: Subject: Re: [PATCH v2] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is disabled by BIOS To: Kai Huang Cc: Sean Christopherson , linux-kernel@vger.kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, mingo@redhat.com, tglx@linutronix.de, kirill.shutemov@linux.intel.com, daniel.gutson@eclypsium.com, hughsient@gmail.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,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 7/11/22, Kai Huang wrote: > >> >> > This patch basically tries to fix the issue that TME flag isn't cleared >> > when TME >> > is disabled by BIOS. And fir this purpose, the code change in this >> > patch looks >> > reasonable to me. Unless I am mistaken, detect_tme() will be called for >> > all >> > cpus if TME is supported in CPUID but isn't enabled by BIOS (either >> > LOCKED or >> > ENABLED bit isn't set). >> >> But this patch doesn't handle the bypass bit, which _does_ effectively >> disable >> TME when set. E.g. the MKTME spec says: >> >> Software must inspect the Hardware Encryption Enable (bit 1) and TME >> Encryption >> Bypass Enable (bit 31) to determine if TME encryption is enabled. > > Yeah so my original reply said: > > "But perhaps it's arguable whether we can also clear TME flag in this > case." > > And I only gave my Acked-by. > > It completely depends on the purpose of this patch, or what does this patch > claim to do. If it only claims to clear TME bit if BIOS doesn't enable it, > then > looks fine to me. If it wants to achieve "clear TME feature flag if > encryption > isn't active", then yes you are right. > > But as I said perhaps "whether we should clear TME flag when bypass is > enabled" > is arguable. After all, what does TME flag in /proc/cpuinfo imply? > What we want with this patch is to check whether some kind of memory encryption is active. Right now we are doing it by checking the "tme active in BIOS" log, so we are not checking the bypass. Can you change this bypass bit at runtime? ie, does it make sense to check it only once at boot time? If no, then maybe it's ok to check that bit in detect_tme and consider it for cpuinfo, If it can change, then probably it's ok to leave this patch as is, and for our use case maybe we can add a sysfs file that reads that msr.