On Wed, 2018-12-12 at 08:29 -0800, Andy Lutomirski wrote: > 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. This all should be summarized in the documentation (high-level model and corner cases). /Jarkko
