From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dave.hansen@linux.intel.com>
Received: from mga04.intel.com ([192.55.52.120])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <dave.hansen@linux.intel.com>)
	id 1fLcyu-0003oY-Nl
	for speck@linutronix.de; Thu, 24 May 2018 01:15:45 +0200
Subject: [MODERATED] Re: [PATCH v5 1/8] L1TFv4 6
References: <cover.1527111786.git.ak@linux.intel.com>
 <20180523215737.7C50E61169@crypto-ml.lab.linutronix.de>
From: Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <70cc1acf-95a1-6de4-7bc8-46dfd54c686a@linux.intel.com>
Date: Wed, 23 May 2018 16:15:41 -0700
MIME-Version: 1.0
In-Reply-To: <20180523215737.7C50E61169@crypto-ml.lab.linutronix.de>
Content-Type: multipart/mixed; boundary="vcVCv80Y1SxkVgmBVs9RghsE88gwexrYz"; protected-headers="v1"
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--vcVCv80Y1SxkVgmBVs9RghsE88gwexrYz
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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
>=20
> On 32bit PAE the max PTE mask is currently set to 44 bit because that i=
s
> the limit imposed by 32bit unsigned long PFNs in the VMs.
>=20
> 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.
>=20
> 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.
>=20
> So increase the mask on 32bit PAE to 52 to match 64bit.
>=20
> The real limit is still 44 bits.
>=20
> 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.


--vcVCv80Y1SxkVgmBVs9RghsE88gwexrYz--