On Fri, May 5, 2017 at 5:49 PM, Jann Horn <[email protected]> wrote: > On Thu, May 4, 2017 at 12:02 PM, Daniel Gruss > <[email protected]> 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?
