[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 May 2017 12:51:27 +0200
From: Daniel Gruss <daniel.gruss@...k.tugraz.at>
To: Mark Rutland <mark.rutland@....com>
CC: David Gens <david.gens@...tu-darmstadt.de>,
Thomas Garnier
<thgarnie@...gle.com>,
kernel list <linux-kernel@...r.kernel.org>,
"Kernel
Hardening" <kernel-hardening@...ts.openwall.com>,
<clementine.maurice@...k.tugraz.at>, <moritz.lipp@...k.tugraz.at>,
"Michael
Schwarz" <michael.schwarz@...k.tugraz.at>,
Richard Fellner
<richard.fellner@...dent.tugraz.at>,
"Kirill A. Shutemov"
<kirill.shutemov@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>, <anders.fogh@...ta-adan.de>
Subject: Re: [RFC, PATCH] x86_64: KAISER - do not map
kernel in user mode
> 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
