I'd rather they opened up Intel CAT to consumer products to help protect against side channel attacks. Memory encryption isn't enough and doesn't address current exploits that are already being used against VM providers.
Can someone explain the context here? Is the intended use for this to prevent a cold boot attack, or also provides protection against an active buffer overflow attack or something?
On the first page of the Introduction, it's clear that the ME should not have access to the actual key in TME. In MKTME, there seems to be one key that is held only by the CPU while the others can be provided by software.
I think the use case for this is a) to defend runtime application memory on systems that use non-volatile memory as RAM (e.g., 3D XPoint), b) to defend against cold boot attacks, and c) to defend against attacks where one VM can read the data pages of another VM, possibly through an re-assignment of a previously used and uninitialized memory page.
too many interfaces for applications to control keys / entropy imo. risky considering attacks against previous low level interfaces. i'd prefer to see less control by/from applications. it's even stated in the spec there's a lot for the programmer to consider and implement to make it really secure.
probarbly itl or "that bald guy who breaks all low level things" (forget his name, sorry guy!) will show how to subvert / break this when it gets implemented more widely.
in my eyes:
a root mode hypervisor can break al lthe things for it's guests (nothing new, but no added benefit for that.)
pconfig command might be used to influence system if BIOS is compromised early on.
SOC vulnerabilities will break this for sure. (and they seem common enough glares at ME).
Ofcourse, can't complain that they try to add these kinds of layer. change has to start somewhere! :-)
https://www.anandtech.com/show/11551/amds-future-in-servers-...