grsecurity forums

The following config, using either the 3.14.30 or 3.14.31 kernel and patch, gives a protection fault while booting under Xen PV:

http://pastebin.com/339T4drA

xm dmesg:

http://pastebin.com/pzE0YSpq

WIth the 3.14.15 kernel and patch everything is fine. The crash occurs even if grsecurity is disabled in the config (just the patch is applied).

Thanks for any help.

can you resolve c1016c97 (the reported RIP) via addr2line in the guest vmlinux? for best results you should enable DEBUG_INFO and DEBUG_INFO_REDUCED and reproduce the crash then use the newly reported RIP value. you could also resolve a few more similar values in the stack dump (e.g., c14e1a5f and c1409183 look like code addresses in the one you posted). or you can just send me your vmlinux (the one in the build root) with the debug info and the new xm dmesg and i'll take a look (i might need the vmlinux anyway for checking the disassembly around the reported RIP).

The dmesg is here:

http://pastebin.com/nme7H5Cr

addr2line:

# addr2line -e vmlinux c1016d5b
/usr/src/kernel/linux-3.14.31/arch/x86/kernel/cpu/common.c:381

vmlinux is here:

http://www.massaker.de/vmlinux

thanks, can you try this patch:

Code: Select all

--- a/arch/x86/xen/enlighten.c       2015-01-19 16:36:09.836363381 +0100
+++ b/arch/x86/xen/enlighten.c    2015-02-02 15:41:54.499513599 +0100
@@ -1452,7 +1452,9 @@ static void __ref xen_setup_gdt(int cpu)
        pv_cpu_ops.load_gdt = xen_load_gdt_boot;

        setup_stack_canary_segment(cpu);
+#ifdef CONFIG_X86_64
        load_percpu_segment(cpu);
+#endif
        switch_to_new_gdt(cpu);

        pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry;


Looks good. I've gone through a full cycle (boot, hotplug cpu, hotplug ram, migrate, hot-remove cpu, hot-remove ram, shutdown) without problems.