On Mon, Nov 27, 2017 at 08:00:19PM +0100, Thomas Gleixner wrote: > On Mon, 27 Nov 2017, Dave Hansen wrote: > > > On 11/26/2017 03:14 PM, Thomas Gleixner wrote: > > > --- a/security/Kconfig > > > +++ b/security/Kconfig > > > @@ -56,7 +56,7 @@ config SECURITY_NETWORK > > > > > > config KAISER > > > bool "Remove the kernel mapping in user mode" > > > - depends on X86_64 && SMP && !PARAVIRT > > > + depends on X86_64 && SMP && !PARAVIRT && JUMP_LABEL > > > help > > > This feature reduces the number of hardware side channels by > > > ensuring that the majority of kernel addresses are not mapped > > > > One of the reasons for doing the runtime-disable was to get rid of the > > !PARAVIRT dependency. I can add a follow-on here that will act as if we > > did "nokaiser" whenever Xen is in play so we can remove this dependency. > > > > I just hope Xen is detectable early enough to do the static patching. > > Yes, it is. I'm currently trying to figure out why it fails on a KVM guest. > > If I boot with 'nokaiser' on the command line it works. If kaiser is > runtime enabled then some early klibc user space in the ramdisk > explodes. Not sure yet whats going on. I'm also seeing weirdness with PARAVIRT+KAISER on kvm. The symptoms aren't consistent. Sometimes it boots, sometimes it hangs before the login prompt, sometimes there are user space seg faults. It almost seems like the interrupt handler is corrupting user space state somehow. This is with tip/WIP.x86/mm plus a patch to remove the KAISER dependency on !PARAVIRT. -- Josh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
