Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd7fd5dd-8038-a871-bdee-7b253078b933@iaik.tugraz.at>
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.