On Mon, 27 Nov 2017, Josh Poimboeuf wrote: > 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. See the patches I posted. Its the PV patching of flush_tlb_single() ... Thanks, tglx -- 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>
