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;
Date:   Wed, 15 Jun 2022 13:59:33 -0700
From:   Alison Schofield <alison.schofield@intel.com>
To:     Martin Fernandez <martin.fernandez@eclypsium.com>
Cc:     Daniel Gutson <daniel.gutson@eclypsium.com>,
        Richard Hughes <hughsient@gmail.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Alex Bazhaniuk <alex.bazhaniuk@eclypsium.com>
Subject: Re: [PATCH] x86/cpuinfo: Clear X86_FEATURE_TME if TME/MKTME is
 disabled by BIOS
Message-ID: <20220615205933.GA1524841@alison-desk>
References: <20220614210217.1940563-1-martin.fernandez@eclypsium.com>
 <20220615190519.GA1524500@alison-desk>
 <CAD2FfiGxy=9ARK5FT_iaLACZSzR+R4crmGJv7T+v_w3+ktOzCQ@mail.gmail.com>
 <20220615195425.GA1524649@alison-desk>
 <CAFmMkTGFpehSFOsnDuQN4aTnwfgYGwTbGBxtvUU_byDcoRVPPA@mail.gmail.com>
 <CAKgze5aQsh2VY4tjsDco_Wc6CTU+KXZM3bhFR+73AVp3gLWHuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKgze5aQsh2VY4tjsDco_Wc6CTU+KXZM3bhFR+73AVp3gLWHuA@mail.gmail.com>
Precedence: bulk

On Wed, Jun 15, 2022 at 05:48:34PM -0300, Martin Fernandez wrote:
> On 6/15/22, Daniel Gutson <daniel.gutson@eclypsium.com> wrote:
> > On Wed, Jun 15, 2022 at 4:54 PM Alison Schofield
> > <alison.schofield@intel.com> wrote:
> >>
> >> On Wed, Jun 15, 2022 at 08:34:58PM +0100, Richard Hughes wrote:
> >> > On Wed, 15 Jun 2022 at 20:06, Alison Schofield
> >> > <alison.schofield@intel.com> 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.
> >> >
> >> Disagree on sending folks to use __get_cpuid_count() when they already
> >> have cpuinfo.
> >>
> >> Why is a sysfs entry TME-enabled 0/1 a bad thing?
> >
> > :)))
> > This was my very first patch, and I got half of the community complaining
> > It was so long ago that I don't recall everything, maybe Mart?n does?
> > or Richard?
> 
> The discussion triggered the fact that checking that TME is active is
> not enough to tell if memory is being encrypted or not (which we
> thought it was true by that time), and that triggered a series of patches to
> address the other checks required, which is currently going nowhere
> [1].
> 
> The sysfs _wasn't_ discarded perse, but since Boris suggested the
> change in cpuinfo (several times now that I recalled that Daniel patch
> [2]) I think that is cleaner, besides the backwards compatibility.
> 
> [1] https://lore.kernel.org/linux-efi/20220429201717.1946178-1-martin.fernandez@eclypsium.com/
> 
> [2] https://lkml.iu.edu/hypermail/linux/kernel/2006.2/05231.html
> 

Martin,
The commit message here seemed to assume that we've all been following
along on this journey with you. Perhaps a commit message that explains
the need and includes alternatives considered/rejected. Links are good!
Alison


> >> It can be documented
> >> to have the same meaning as the log message.
> >>
> >> You keep referring to AMD. How is their exception documented?
> >>
> >> Alison
> >>
> >> > > 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.
> >