Date: Fri, 5 May 2017 17:49:15 +0200 From: Jann Horn <jannh@...gle.com> To: Daniel Gruss <daniel.gruss@...k.tugraz.at> 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 Thu, May 4, 2017 at 12:02 PM, Daniel Gruss <daniel.gruss@...k.tugraz.at> wrote: > After several recent works [1,2,3] KASLR on x86_64 was basically considered > dead by many researchers. We have been working on an efficient but effective > fix for this problem and found that not mapping the kernel space when > running in user mode is the solution to this problem  (the corresponding > paper  will be presented at ESSoS17). > > With this RFC patch we allow anybody to configure their kernel with the flag > CONFIG_KAISER to add our defense mechanism. > > If there are any questions we would love to answer them. > We also appreciate any comments! Why do you need this SWITCH_KERNEL_CR3_NO_STACK logic? It would make sense if the kernel stacks weren't mapped, but if they weren't mapped, I don't see how the entry_INT80_compat entry point could work at all - the software interrupt itself already pushes values on the kernel stack. You could maybe work around that using some sort of trampoline stack, but I don't see anything like that. Am I missing something?
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.