Messages in this thread | | | From | Jann Horn <> | Date | Fri, 5 May 2017 17:53:30 +0200 | Subject | Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| |
On Fri, May 5, 2017 at 5:49 PM, Jann Horn <jannh@google.com> wrote: > On Thu, May 4, 2017 at 12:02 PM, Daniel Gruss > <daniel.gruss@iaik.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 [4] (the corresponding >> paper [5] 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?
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?
| |