Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 19 Jun 2020 12:41:14 -0700 | Subject | Re: [PATCH] Ability to read the MKTME status from userspace |
| |
On Fri, Jun 19, 2020 at 9:47 AM Richard Hughes <hughsient@gmail.com> wrote: > > On Fri, 19 Jun 2020 at 17:41, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > Yes. I want to show the user *why* TME is not available. > > So even if it is "available" that's fine, even if it is not being used? > > No, it's just one more thing we can check and report. For instance, > "Full memory encryption: NO [firmware-disabled, unencrypted-swap, EFI > memory map incomplete]
The list is bigger than this, and it will probably get even bigger in the future. For example, if the specific thing you care about is "is my memory encrypted on the DIMM", choices include:
- Yes, mostly, TME - Yes, mostly, SME - Yes, mostly, SEV (which comes in several variants) - Yes, because this is actually a Graphene SGX enclave or similar. - No, your memory controller can't do this. - No. Although your memory controller can do this, it isn't right now, because [reason]. - (in the future, maybe) Partially, because *MK* TME is enabled and encryption depends on the specific policy. - (in the future, maybe) No, but you think yes, because MKTME is enabled and you used a fixed key that is stored somewhere. - (in the future, maybe) Maybe, because some memory is encrypted and some isn't.
But if what you *actually* care about is whether someone who resets the system and takes over gets to learn the contents of the DIMMs (i.e. a "cold-boot attack"), then there are more answers:
- Protected because of TXT: the memory controller will not allow reads until the DIMMs are cleared. - Protected because of whatever AMD's equivalent is. - Protected to some extent because the installed firmware will wipe memory on reset.
If you care about whether the contents of anonymous memory will be encrypted at rest on swap, then you care about what the swap backing store is *and* where the key came from.
If you care about whether and to what degree the contents of anonymous memory are protected from a malicious hypervisor, the answer is complicated.
I don't object in principle to Linux giving userspace more visibility into what's going on, but I'm not convinced that adding a new must-support-for-a-long-time interface that only solves 5% of your problem is worth it. Especially if, some day, the shiny new interface says "TME is on", but this really means "MKTME is on and the administrator configured it to only encrypt specific things for performance reasons".
| |