On Wed, Dec 12, 2018 at 7:31 AM Sakkinen, Jarkko <jarkko.sakkinen@xxxxxxxxx> wrote: > > On Fri, 2018-12-07 at 15:45 -0800, Jarkko Sakkinen wrote: > > The brutal fact is that a physical address is an astronomical stretch > > from a random value or increasing counter. Thus, it is fair to say that > > MKTME provides only naive measures against replay attacks... > > I'll try to summarize how I understand the high level security > model of MKTME because (would be good idea to document it). > > Assumptions: > > 1. The hypervisor has not been infiltrated. > 2. The hypervisor does not leak secrets. > > When (1) and (2) hold [1], we harden VMs in two different ways: > > A. VMs cannot leak data to each other or can they with L1TF when HT > is enabled? I strongly suspect that, on L1TF-vulnerable CPUs, MKTME provides no protection whatsoever. It sounds like MKTME is implemented in the memory controller -- as far as the rest of the CPU and the cache hierarchy are concerned, the MKTME key selction bits are just part of the physical address. So an attack like L1TF that leaks a cacheline that's selected by physical address will leak the cleartext if the key selection bits are set correctly. (I suppose that, if the attacker needs to brute-force the physical address, then MKTME makes it a bit harder because the effective physical address space is larger.) > B. Protects against cold boot attacks. TME does this, AFAIK. MKTME does, too, unless the "user" mode is used, in which case the protection is weaker. > > Isn't this what this about in the nutshell roughly? > > [1] XPFO could potentially be an opt-in feature that reduces the > damage when either of these assumptions has been broken. > > /Jarkko
