Hello everybody, today I was trying to update my domU to linux kernel v3. At the moment it''s running with a 2.6.38 kernel and it''s running smooth. I simply took the .config and run a make oldconfig in linux v3 sources and what I get is that it won''t boot. No kernel bootlog to inspect. I''m running xen 4.2.0 on a 32bit paravirt environment. The dom0 kernel is Linux 3.3.8 and the other domU machine I have is running with the same version of the kernel. The sole machine that is giving me troubles is the hardened one, currently running with grsec+pax on the 2.6.38. This is my current configuration: - kernel config file (domU): http://codepad.org/sgnyXLqL - domU configuration file (xen): http://codepad.org/jdqO3W9H This is the output: xevelon ~ # xl create -c /xen/configs/caprica Parsing config from /xen/configs/caprica Daemon running with PID 4460 libxl: error: libxl_dom.c:34:libxl__domain_type: unable to get domain type for domid=6 Unable to attach console libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1 xevelon ~ # cat /var/log/xen/xl-caprica.log Waiting for domain caprica (domid 6) to die [pid 4461] Domain 6 has shut down, reason code 3 0x3 Action for shutdown reason code 3 is destroy Domain 6 needs to be cleaned up: destroying the domain Done. Exiting now xl dmesg: XEN) d6:v0: unhandled page fault (ec=0000) (XEN) Pagetable walk from 00000e94: (XEN) L3[0x000] = 0000000000000000 ffffffff (XEN) domain_crash_sync called from entry.S (ff1ef878) (XEN) Domain 6 (vcpu#0) crashed on cpu#3: (XEN) ----[ Xen-4.2.0 x86_32p debug=n Not tainted ]---- (XEN) CPU: 3 (XEN) EIP: e019:[<c10b2fc2>] (XEN) EFLAGS: 00000206 EM: 1 CONTEXT: pv guest (XEN) eax: 00003f3f ebx: 00000000 ecx: 00000000 edx: 00000000 (XEN) esi: c1a80000 edi: c14b1000 ebp: 00000000 esp: c1601f3c (XEN) cr0: 8005003b cr4: 000006f4 cr3: 28e51000 cr2: 00000e94 (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 (XEN) Guest stack trace from esp=c1601f3c: (XEN) 00000000 c10b2fc2 0001e019 00010006 00000000 c16561b2 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 c1a80000 c14b1000 (XEN) 00000000 00000000 c16dad04 00000068 00000000 00000000 00000000 00000000 (XEN) 014a5000 c1023a28 00000082 00000000 00000000 00000000 00000000 c16dad04 (XEN) 00000000 00000000 00000000 00000068 00000060 00000068 00000068 000000d8 (XEN) 00000000 00000000 80000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 - xl info: http://codepad.org/wJCTXtoD - xl create (-vvv ultraverbose): http://codepad.org/XhXN5ztl Does somebody have any clue about it? Thank you so much!-- Fabiano Francesconi [GPG key: 0x81E53461]
Fabiano Francesconi
2013-Feb-12 10:20 UTC
Re: Xen domU PV linux-3.7.0-hardened won''t boot
On Monday 11 February 2013 at 16:25, Fabiano Francesconi wrote:> Hello everybody, > today I was trying to update my domU to linux kernel v3. > > At the moment it''s running with a 2.6.38 kernel and it''s running smooth. > I simply took the .config and run a make oldconfig in linux v3 sources and what I get is that it won''t boot. No kernel bootlog to inspect. > > I''m running xen 4.2.0 on a 32bit paravirt environment. > The dom0 kernel is Linux 3.3.8 and the other domU machine I have is running with the same version of the kernel. > > The sole machine that is giving me troubles is the hardened one, currently running with grsec+pax on the 2.6.38. > > This is my current configuration: > - kernel config file (domU): http://codepad.org/sgnyXLqL > - domU configuration file (xen): http://codepad.org/jdqO3W9H > > This is the output: > > xevelon ~ # xl create -c /xen/configs/caprica > Parsing config from /xen/configs/caprica > Daemon running with PID 4460 > libxl: error: libxl_dom.c:34:libxl__domain_type: unable to get domain type for domid=6 > Unable to attach console > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1 > > > xevelon ~ # cat /var/log/xen/xl-caprica.log > Waiting for domain caprica (domid 6) to die [pid 4461] > Domain 6 has shut down, reason code 3 0x3 > Action for shutdown reason code 3 is destroy > Domain 6 needs to be cleaned up: destroying the domain > Done. Exiting now > > > > xl dmesg: > XEN) d6:v0: unhandled page fault (ec=0000) > (XEN) Pagetable walk from 00000e94: > (XEN) L3[0x000] = 0000000000000000 ffffffff > (XEN) domain_crash_sync called from entry.S (ff1ef878) > (XEN) Domain 6 (vcpu#0) crashed on cpu#3: > (XEN) ----[ Xen-4.2.0 x86_32p debug=n Not tainted ]---- > (XEN) CPU: 3 > (XEN) EIP: e019:[<c10b2fc2>] > (XEN) EFLAGS: 00000206 EM: 1 CONTEXT: pv guest > (XEN) eax: 00003f3f ebx: 00000000 ecx: 00000000 edx: 00000000 > (XEN) esi: c1a80000 edi: c14b1000 ebp: 00000000 esp: c1601f3c > (XEN) cr0: 8005003b cr4: 000006f4 cr3: 28e51000 cr2: 00000e94 > (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 > (XEN) Guest stack trace from esp=c1601f3c: > (XEN) 00000000 c10b2fc2 0001e019 00010006 00000000 c16561b2 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 c1a80000 c14b1000 > (XEN) 00000000 00000000 c16dad04 00000068 00000000 00000000 00000000 00000000 > (XEN) 014a5000 c1023a28 00000082 00000000 00000000 00000000 00000000 c16dad04 > (XEN) 00000000 00000000 00000000 00000068 00000060 00000068 00000068 000000d8 > (XEN) 00000000 00000000 80000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > > > - xl info: http://codepad.org/wJCTXtoD > - xl create (-vvv ultraverbose): http://codepad.org/XhXN5ztl > > Does somebody have any clue about it? > > Thank you so much!-- > Fabiano Francesconi [GPG key: 0x81E53461]I think I found what the problem was. The problem comes from the grsec section in the kernel. In particular, it is related to one of the miscellaneous hardening features of PaX. According to what I discovered, it may be one of the following (I disabled all three): - CONFIG_PAX_MEMORY_SANITIZE - CONFIG_PAX_MEMORY_STACKLEAK - CONFIG_PAX_USERCOPY I tend to be more biased towards the last since I get a lot of warning during the compile phase about copy_to_user and copy_from_user syscalls. I think this should be pointed out to the GRSEC team. -- Fabiano Francesconi [GPG key: 0x81E53461]