[MODERATED] Re: [PATCH 3/8] L1TFv3 1

[Michal Hocko <mhocko@suse.com>]

On Thu 03-05-18 20:23:24, speck for Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> Subject:  x86, l1tf: Protect PROT_NONE PTEs against speculation
> 
> We also need to protect PTEs that are set to PROT_NONE against
> L1TF speculation attacks.
> 
> This is important inside guests, because L1TF speculation
> bypasses physical page remapping. While the VM has its own
> migitations preventing leaking data from other VMs into
> the guest, this would still risk leaking the wrong page
> inside the current guest.
> 
> This uses the same technique as Linus' swap entry patch:
> while an entry is is in PROTNONE state we invert the
> complete PFN part part of it. This ensures that the
> the highest bit will point to non existing memory.
> 
> The invert is done by pte/pmd/pud_modify and pfn/pmd/pud_pte for
> PROTNONE and pte/pmd/pud_pfn undo it.
> 
> We assume that noone tries to touch the PFN part of
> a PTE without using these primitives.
> 
> This doesn't handle the case that MMIO is on the top
> of the CPU physical memory. If such an MMIO region
> was exposed by an unpriviledged driver for mmap
> it would be possible to attack some real memory.
> However this situation is all rather unlikely.
> 
> For 32bit non PAE we don't try inversion because
> there are really not enough bits to protect anything.
> 
> Q: Why does the guest need to be protected when the
> HyperVisor already has L1TF mitigations?
> A: Here's an example:
> You have physical pages 1 2. They get mapped into a guest as
> GPA 1 -> PA 2
> GPA 2 -> PA 1
> through EPT.
> 
> The L1TF speculation ignores the EPT remapping.
> 
> Now the guest kernel maps GPA 1 to process A and GPA 2 to process B,
> and they belong to different users and should be isolated.
> 
> A sets the GPA 1 PA 2 PTE to PROT_NONE to bypass the EPT remapping
> and gets read access to the underlying physical page. Which
> in this case points to PA 2, so it can read process B's data,
> if it happened to be in L1.
> 
> So we broke isolation inside the guest.
> 
> There's nothing the hypervisor can do about this. This
> mitigation has to be done in the guest.
> 
> v2: Use new helper to generate XOR mask to invert (Linus)
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> Acked-by: Michal Hocko <mhocko@suse.com>

Thanks for extending the changelog. The implementation is different but
my ack still applies. I like how this ended up being smaller than
the original patch.
-- 
Michal Hocko
SUSE Labs