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?
