Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] Ability to read the MKTME status from userspace
Date:   Fri, 19 Jun 2020 08:48:47 -0700
Message-Id: <0DD7FAE4-3976-4835-8090-80B84B737F3E@amacapital.net>
References: <CAD2FfiFRqwYGB50KK=aA0sU6uCALYneoyD=V4EfOsk-Ex=C+xg@mail.gmail.com>
Cc:     Borislav Petkov <bp@alien8.de>,
        Daniel Gutson <daniel@eclypsium.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "David S. Miller" <davem@davemloft.net>,
        Rob Herring <robh@kernel.org>, Tony Luck <tony.luck@intel.com>,
        Rahul Tanwar <rahul.tanwar@linux.intel.com>,
        Xiaoyao Li <xiaoyao.li@intel.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <CAD2FfiFRqwYGB50KK=aA0sU6uCALYneoyD=V4EfOsk-Ex=C+xg@mail.gmail.com>
To:     Richard Hughes <hughsient@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jun 19, 2020, at 6:50 AM, Richard Hughes <hughsient@gmail.com> wrote:
>=20
> =EF=BB=BFOn Fri, 19 Jun 2020 at 14:44, Borislav Petkov <bp@alien8.de> wrot=
e:
>> Yes, this is what I'm proposing with clearing the flag in /proc/cpuinfo.
>> The needed information is there:
>> 1. TME in CPUID
>> 2. TME *not* in /proc/cpuinfo
>=20
> No, it's not a boolean at all. If the platform disable is a BIOS
> configuration we don't know if TME isn't available because the CPU
> doesn't support it or because the firmware has disabled it. In the
> latter case, a firmware update or firmware configuration change might
> actually enable it. If the user installs a CPU with TME support and
> then we tell the user "your system doesn't support TME" then we're
> going to have some very confused users unless we can differentiate the
> two cases.
>=20
>> Along with proper ABI definition, design,
>> documentation and all that belongs to a proper interface with userspace.
>=20
> I don't think Daniels patch was a "final version" and I'm sure
> follow-ups can add this kind of thing. At the moment it's just people
> telling him "you don't need this" when as a potential consumer I'm
> saying we really do.

I think it=E2=80=99s reasonable for the kernel to ask why.

Is the idea that some GUI would show a big warning like =E2=80=9Cyour silly B=
IOS has TME disabled=E2=80=9D?

Boris, it wouldn=E2=80=99t be totally crazy for cpuinfo to learn to distingu=
ish between =E2=80=9Cyour platform has this feature but Linux isn=E2=80=99t u=
sing it=E2=80=9D and =E2=80=9Cyour platform doesn=E2=80=99t have this featur=
e in the first place=E2=80=9D. And I suppose there=E2=80=99s this extra sill=
y state =E2=80=9Cyour platform has this feature, but your firmware didn=E2=80=
=99t enable it=E2=80=9D.  This would be a big job.

Regardless, knowing what the actual point of this patch is would be nice.

>=20
> Richard.