Bug with 2.6.24 as xen domU

[xstasi]

Hello,

I'd like to report a bug with 2.6.24+grsec running as Xen domU.

As some of you may have noticed, 2.6.24 includes native support for running as domU, and the lastest grsec patch is aware of it.
Though, i'm having a few issues with it..
Let me explain:

When I boot a vanilla 2.6.24 kernel, everything goes ok.
When I boot the very same kernel, with grsec patch (nothing of it is enabled, just patch -p1 and make oldconfig with "N" at everything), the hypervisor seems to have problems loading the kernel image, saying that "Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000]", with subsequent domain_crash_sync
(full crash dump at: http://www.prato.linux.it/~mnencia/past ... d0e2255464 ).

After some gdb, it seems like the kernel hangs in function xen_start_kernel, declared in arch/x86/xen/enlighten.c, line:

Code: Select all

       BUG_ON(memcmp(xen_start_info->magic, "xen-3", 5) != 0);


BUG_ON is throwing the ud2a instruction (always unvalid opcode) which makes the hypervisor call the domain_crash_sync

Since the previous line ( if(!xen_start_info) return; ) tells us that the struct xen_start_info is not empty, but the xen_start_info->magic is not "xen-3"
(and to be honest, i don't know how to debug a live kernel to discover what's in there), i think that something strange is going on.
Maybe there is some alignment or memory layout issue in some exported symbols, because as i've seen from the Xen hypervisor code, the structure should be filled correctly.

Does anyone have a clue about what's wrong with him?

Thanks in advance

xstasi

[xstasi]

Update: I found out with gdb that the reason why memcmp(xen_start_info->magic,"xen-3",5) fails is not because xen_start_info struct is empty, but instead... "xen-3" is empty.
Being it a static string, its emptiness is quite absurd.
From this investigation, it appears that the problem is not an offset issue, but a linking issue instead.
The situation is becoming harder for me to analyze, but maybe easier for you.

If you ask me, I can provide all the info you may need

Thanks for attention

[PaX Team]

Since the previous line ( if(!xen_start_info) return; ) tells us that the struct xen_start_info is not empty, but the xen_start_info->magic is not "xen-3"
(and to be honest, i don't know how to debug a live kernel to discover what's in there), i think that something strange is going on.

printk("%s\n", xen_start_info->magic); or similar should do it. other than that i have no idea why this struct would be wrong, the guest kernel gets it passed directly from the hypervisor, it has no control over it really. also as i said elsewhere on the forum, i never checked PaX under a real Xen so these kinds of problems are to be expected (just watch the fireworks when you actually enable features, say trying to execute code from the 'hypercall_page' allocated in the non-executable .bss , so we'll have to work them out one by one, if you have the time.