Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

From: Daniel Gruss <daniel.gruss@iaik.tugraz.at>
To: Mark Rutland <mark.rutland@arm.com>
Cc: David Gens <david.gens@cs.tu-darmstadt.de>,
	Thomas Garnier <thgarnie@google.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
	<clementine.maurice@iaik.tugraz.at>, <moritz.lipp@iaik.tugraz.at>,
	"Michael Schwarz" <michael.schwarz@iaik.tugraz.at>,
	Richard Fellner <richard.fellner@student.tugraz.at>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>, <anders.fogh@gdata-adan.de>
Subject: Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Date: Mon, 8 May 2017 12:51:27 +0200	[thread overview]
Message-ID: <db80ae9d-15bc-5d32-afce-ea98a6059fb8@iaik.tugraz.at> (raw)
In-Reply-To: <20170508102100.GA5480@leverpostej>

> While it may be the case that in practice ARM systems do not have such a
> side channel, I think that it is erroneous to believe that the
> architectural TTBR{0,1} split ensures this.
>
> The use of TTBR0 for user and TTBR1 for kernel is entirely a SW policy,
> and not an architectural requirement. It is possible to map data in
> TTBR1 which is accessible to userspace, and data in TTBR0 which is only
> accessible by the kernel. In either case, this is determined by the page
> tables themselves.

Absolutely right, but TTBR0 and TTBR1 are usually used in this way.

> Given this, I think that the statements in the KAISER paper regarding
> the TTBRs (in section 2.1) are not quite right. Architecturally,
> permission checks and lookups cannot be elided based on the TTBR used.

As we say in section 2.1, they are "typically" used in this way, and this prevents the attacks. Not just the presence of 
a second register, but the way how the two registers are used to split the translation tables for user and kernel.