[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 6 May 2017 10:28:30 +0200
From: Daniel Gruss <daniel.gruss@...k.tugraz.at>
To: Jann Horn <jannh@...gle.com>
CC: kernel list <linux-kernel@...r.kernel.org>,
<kernel-hardening@...ts.openwall.com>,
"clementine.maurice@...k.tugraz.at"
<clementine.maurice@...k.tugraz.at>,
"moritz.lipp@...k.tugraz.at"
<moritz.lipp@...k.tugraz.at>,
Michael Schwarz
<michael.schwarz@...k.tugraz.at>,
Richard Fellner
<richard.fellner@...dent.tugraz.at>,
<kirill.shutemov@...ux.intel.com>, "Ingo
Molnar" <mingo@...nel.org>,
"anders.fogh@...ta-adan.de"
<anders.fogh@...ta-adan.de>
Subject: Re: [RFC, PATCH] x86_64: KAISER - do not map
kernel in user mode
On 2017-05-05 17:53, Jann Horn wrote:
> Ah, I think I understand. The kernel stacks are mapped, but
> cpu_current_top_of_stack isn't, so you can't find the stack until after the CR3
> switch in the syscall handler?
That's the idea. Only the absolute minimum that is required for a
context switch remains mapped (+ it is mapped at an offset which does
not depend on KASLR -> we do not leak the KASLR offsets).
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.
