[MODERATED] Re: [PATCH v5 1/8] L1TFv4 6

[Dave Hansen <dave.hansen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

On 05/23/2018 02:51 PM, speck for Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> Subject:  x86, l1tf: Increase 32bit PAE __PHYSICAL_PAGE_MASK
> 
> On 32bit PAE the max PTE mask is currently set to 44 bit because that is
> the limit imposed by 32bit unsigned long PFNs in the VMs.
> 
> The L1TF PROT_NONE protection code uses the PTE masks to determine
> what bits to invert to make sure the higher bits are set for unmapped
> entries to prevent L1TF speculation attacks against EPT inside guests.
> 
> But our inverted mask has to match the host, and the host is likely
> 64bit and may use more than 43 bits of memory. We want to set
> all possible bits to be safe here.
> 
> So increase the mask on 32bit PAE to 52 to match 64bit.
> 
> The real limit is still 44 bits.
> 
> All Linux PTEs are created from unsigned long PFNs, so cannot be
> higher than 44 bits on a 32bit kernel. So these extra PFN
> bits should be never set. The only users of this macro are using
> it to look at PTEs, so it's safe.

I'm scratching my head a bit at this description.  I've written another
summary so I could understand it a bit better.  Could you check if my
understanding is correct.  Feel free to steal any of this for your
description or toss it.

BTW, this reminds me: Let's say we trust guest kernels.  Do we need KVM
code to _prevent_ guests running in 32-bit non-PAE mode?  Wouldn't any
32-bit non-PAE guest effectively have the ability to read the bottom
~4GB of host memory?

If we don't trust guest kernels, then what is the point of this patch? :)

Problem:

This patch is intended to protect against a 32-bit unprivileged guest
application using PROT_NONE on normal guest memory to attack host memory.

Background:

32-bit 'unsigned long' PFNs can only point to 44 bits of memory
(32+PAGE_SHIFT).  We enforce this via __PHYSICAL_PAGE_MASK, but
unfortunately our L1TF workaround bits are also limited by
__PHYSICAL_PAGE_MASK as well.

Example:

Imagine a 32-bit PAE PTE pointing to memory at guest physical address 1GB:

	0x0000000040000067

Then the attacker calls mprotect(PROT_NONE).  We invert the PTE's
physical address bits (and add _PAGE_PROT_NONE), but only those bits set
in __PHYSICAL_PAGE_MASK.  We get:

	0x00000fffbffff100

Which is an address just below 16TB.  This might allow an attacker to
read *host* memory at that address.

The fix:

Increase __PHYSICAL_PAGE_MASK to allow us to set higher address bits in
the inverted PTEs.... and then all the other description you had.