On 6/19/20 7:36 AM, Richard Hughes wrote: > On Fri, 19 Jun 2020 at 15:23, Dave Hansen <dave.han...@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"?
