Messages in this thread | | | Subject | Re: [PATCH] Ability to read the MKTME status from userspace | From | Dave Hansen <> | Date | Fri, 19 Jun 2020 07:48:55 -0700 |
| |
On 6/19/20 7:36 AM, Richard Hughes wrote: > On Fri, 19 Jun 2020 at 15:23, Dave Hansen <dave.hansen@intel.com> wrote: >> Last night, I asked my kids if they brushed their teeth. They said: >> "Dad, my toothbrush was available." They argued that mere availability >> was a better situation than not *having* a toothbrush. They were >> logically right, of course, but they still got cavities. > > I don't see how that's comparable, sorry. Surely Intel wants to sell > hardware advertising TME as a security feature?
Of course! Just like AVX-512 or VNNI or whatever, Intel will totally tell you about the stuff baked into its silicon! But, just like AVX-512, there's a lot of work to do on top of mere presence in the silicon to ensure it is providing benefit.
>>> So my take-away from that is that it's currently impossible to >>> actually say if your system is *actually* using TME. >> Not in a generic way, and it can't be derived from cpuid or MSRs alone. > > Well, it seems not in any way at the moment. > >> I'm pretty sure I'm using TME, but I didn't become sure from >> poking at sysfs. > > How do you know that Lenovo didn't disable TME without looking at > dmesg? I don't think "pretty sure" is good enough when TME is > considered a security feature.
You cut out the important part. The "pretty sure" involves a bunch of preconditions and knowing what your hardware configuration is in the first place.
Let's take a step back. We add read-only ABIs so that decisions can be made. What decision will somebody make from the ABI being proposed here?
Someone does 'cat /proc/mktme' (or whatever) and it says "1" or whatever, which means yay, encryption is on. What do they do?
What do they do differently when it says "0"?
| |