Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a7cc85fd-b261-0c83-8636-eb57c9ba71f9@iaik.tugraz.at>
Date: Sat, 6 May 2017 10:38:23 +0200
From: Daniel Gruss <daniel.gruss@...k.tugraz.at>
To: David Gens <david.gens@...tu-darmstadt.de>,
        Thomas Garnier
	<thgarnie@...gle.com>
CC: 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

On 2017-05-06 06:02, David Gens wrote:
> Assuming that their patch indeed leaks per-cpu addresses.. it might not
> necessarily
> be required to change it.

I think we're not leaking them (unless we still have some bug in our 
code). The basic idea is that any part that is required for the context 
switch is at a fixed location (unrelated to the location of code / data 
/ per-cpu data / ...) and thus does not reveal any randomized offsets. 
Then the attacker cannot gain any knowledge through the side channel 
anymore.
For any attack the attacker could then only use the few KBs of memory 
that cannot be unmapped because of the way x86 works. Hardening these 
few KBs seems like an easier task than doing the same for the entire kernel.

(The best solution would of course be Intel introducing CR3A and CR3B 
just like ARM has TTBR0 and TTBR1 - on ARM this entirely prevents any 
prefetch / double-fault side-channel attacks.)

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.