grsecurity forums

by **bplant** » Mon Oct 20, 2008 12:33 am

Hi PaX Team,

64-bit xen went into mainline in 2.6.27. I just tried booting a vanilla paravirt_ops 2.6.27.2 kernel patched with the 2.6.27 test6 patch. Unfortunately I got ~20 whitespace characters printed before the VM crashed. No other output at all.

I'm keen to get xen and pax working together, so please let me know what info you require and I will more than happy to provide it.

Cheers,

Brad

by **bplant** » Mon Oct 20, 2008 4:38 pm

Just a quick update on this. I thought it would be good to know which feature was causing the VM not to boot. I disabled SMP and all PaX options but the VM still fails to boot as before. It would appear that simply applying the PaX patch is enough to break it.

by **cormander** » Mon Oct 20, 2008 10:55 pm

Yeah I did the same thing you did and wasn't able to boot a .27 pax kernel under xen either.

From prevoius kernels the culprit seemed to be the linker script for the linux binary not working right:

arch/x86/kernel/vmlinux_64.lds.S

But removing the changes that pax does to it in .27 cause a compile failure. I haven't had any time to dig any deeper.

The consensus from previous kernels seemed to be that xen couldn't boot a pax patched kernel because it wasn't even able to load the ELF image - it got all zeros instead of data (since pax messes with the format of the kernel image)

by **bplant** » Tue Oct 21, 2008 6:59 pm

HI Corey,

cormander wrote:But removing the changes that pax does to it in .27 cause a compile failure. I haven't had any time to dig any deeper.

Interesting point. I tried reverting arch/x86/kernel/vmlinux_64.lds.S and arch/x86/kernel/setup.c (it'll compile if you revert both) but it didn't appear to make any difference.

Cheers,

Brad

by **bplant** » Tue Oct 21, 2008 7:08 pm

One extra piece of info. "xm dmesg" gives you a print out with register contents etc.

Code: Select all: (XEN) printk: 2 messages suppressed. (XEN) mm.c:2006:d35 Bad type (saw 00000000e8000001 != exp 0000000060000000) for mfn a6465 (pfn 511) (XEN) mm.c:794:d35 Attempt to create linear p.t. with write perms (XEN) mm.c:1275:d35 Failure in alloc_l4_table: entry 388 (XEN) mm.c:2041:d35 Error while validating mfn a6467 (pfn 50f) for type 0000000080000000: caf=80000003 taf=0000000080000001 (XEN) mm.c:2331:d35 Error while pinning mfn a6467 (XEN) traps.c:437:d35 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] (XEN) domain_crash_sync called from entry.S (XEN) Domain 35 (vcpu#0) crashed on cpu#1: (XEN) ----[ Xen-3.3.0 x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: e033:[<ffffffff80203593>] (XEN) RFLAGS: 0000000000000282 EM: 1 CONTEXT: pv guest (XEN) rax: 00000000ffffffea rbx: 0000000000000800 rcx: 0000000000000053 (XEN) rdx: 0000000000000000 rsi: 0000000000000001 rdi: ffffffff80659f88 (XEN) rbp: ffffffff806cf080 rsp: ffffffff80659f48 r8: ffffffff807662a0 (XEN) r9: ffffffff807662a0 r10: 0000000000007ff0 r11: 0000000000000020 (XEN) r12: 0000000001c00000 r13: 00000000000001ff r14: 0000000000001c00 (XEN) r15: 0000000000000800 cr0: 000000008005003b cr4: 00000000000026b0 (XEN) cr3: 00000000a597e000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff80659f48: (XEN) 0000000000000053 0000000000000020 ffffffff80203593 000000010000e030 (XEN) 0000000000010082 ffffffff80659f88 000000000000e02b ffffffff8020358f (XEN) 0000000000000003 00000000000a6467 0000000001c00000 00000000000001ff (XEN) 0000000000001c00 ffffffff8068b8e9 0000000e00000000 0000000000010000 (XEN) ffffffff80ff8000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) mm.c:2006:d36 Bad type (saw 00000000e8000001 != exp 0000000060000000) for mfn 96463 (pfn 511) (XEN) mm.c:794:d36 Attempt to create linear p.t. with write perms (XEN) mm.c:1275:d36 Failure in alloc_l4_table: entry 388 (XEN) mm.c:2041:d36 Error while validating mfn 96465 (pfn 50f) for type 0000000080000000: caf=80000003 taf=0000000080000001 (XEN) domain_crash_sync called from entry.S (XEN) Domain 36 (vcpu#0) crashed on cpu#1: (XEN) ----[ Xen-3.3.0 x86_64 debug=n Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: e033:[<ffffffff80203593>] (XEN) RFLAGS: 0000000000000282 EM: 1 CONTEXT: pv guest (XEN) rax: 00000000ffffffea rbx: 0000000000000800 rcx: 0000000000000053 (XEN) rdx: 0000000000000000 rsi: 0000000000000001 rdi: ffffffff80659f88 (XEN) rbp: ffffffff806cf080 rsp: ffffffff80659f48 r8: ffffffff807662a0 (XEN) r9: ffffffff807662a0 r10: 0000000000007ff0 r11: 0000000000000020 (XEN) r12: 0000000001c00000 r13: 00000000000001ff r14: 0000000000001c00 (XEN) r15: 0000000000000800 cr0: 000000008005003b cr4: 00000000000026b0 (XEN) cr3: 000000009597c000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff80659f48: (XEN) 0000000000000053 0000000000000020 ffffffff80203593 000000010000e030 (XEN) 0000000000010082 ffffffff80659f88 000000000000e02b ffffffff8020358f (XEN) 0000000000000003 0000000000096465 0000000001c00000 00000000000001ff (XEN) 0000000000001c00 ffffffff8068b8e9 0000000e00000000 0000000000010000 (XEN) ffffffff80ff8000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff (XEN) ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff

Hopefully this sheds some more light on what is happening.

by **PaX Team** » Thu Oct 23, 2008 6:39 pm

bplant wrote:Hopefully this sheds some more light on what is happening.

unfortunately i won't have time to look into xen anytime soon, so unless you guys do some background research on what xen complains about, i won't be able to fix the problems (if it's on the PaX side at all, that is).

by **bplant** » Mon Oct 27, 2008 2:38 am

PaX Team wrote:unfortunately i won't have time to look into xen anytime soon, so unless you guys do some background research on what xen complains about, i won't be able to fix the problems (if it's on the PaX side at all, that is).

Ok, I've spent all day trying to do some background research. I haven't gotten far, but thought I would share anyway. The PaX patched kernel is calling BUG() in pin_pagetable_pfn in arch/x86/xen/enlighten.c, line 836. The call stack is as follows:

arch/x86/xen/enlighten.c:1711 xen_start_kernel calls xen_setup_kernel_pagetable
arch/x86/xen/enlighten.c:1600 xen_setup_kernel_pagetable calls pin_pagetable_pfn
arch/x86/xen/enlighten.c:836 pin_pagetable_pfn calls BUG()

I found this thread here: viewtopic.php?f=1&t=1913, however that seemed to be a different issue. Perhaps because I am using a later version of xen (3.3.0). In that thread, the rodata apparently got lost when the kernel was relocated and the kernel was bailing out at arch/x86/xen/enlighten.c:1667. A 2.6.27 x86_64 kernel under xen-3.3.0 passes this point so the rodata is being relocated correctly.

I have connected to both a PaX and vanilla 2.6.27.3 kernel with gdbserver-xen and traced through them both simultaneously looking for something obviously different. Nothing stood out though. I.e. one didn't have a null pointer argument while the other didn't etc. The only difference was slightly different parameters to functions called which I initially thought were due to the different size of the kernel data structures etc. Those variations were apparently important however since the vanilla kernel boots while the PaX kernel doesn't.

When the PaX guest VM calls HYPERVISOR_mmuext_op (from arch/x86/xen/enlighten.c:835), the xen hypervisor prints the following error:

(XEN) mm.c:2006:d21 Bad type (saw 00000000e8000001 != exp 0000000060000000) for mfn 12b9c9 (pfn 328)
(XEN) mm.c:794:d21 Attempt to create linear p.t. with write perms
(XEN) mm.c:1275:d21 Failure in alloc_l4_table: entry 388
(XEN) mm.c:2041:d21 Error while validating mfn 12b9cb (pfn 326) for type 0000000080000000: caf=80000003 taf=0000000080000001
(XEN) mm.c:2331:d21 Error while pinning mfn 12b9cb

Any tips on where to go from here? I'm guessing I need to dig deeper as to what happening with HYPERVISOR_mmuext_op and find out exactly what the xen hypervisor is expecting.

by **PaX Team** » Mon Oct 27, 2008 6:10 am

bplant wrote:Ok, I've spent all day trying to do some background research. I haven't gotten far, but thought I would share anyway. The PaX patched kernel is calling BUG() in pin_pagetable_pfn in arch/x86/xen/enlighten.c, line 836. The call stack is as follows:

arch/x86/xen/enlighten.c:1711 xen_start_kernel calls xen_setup_kernel_pagetable
arch/x86/xen/enlighten.c:1600 xen_setup_kernel_pagetable calls pin_pagetable_pfn
arch/x86/xen/enlighten.c:836 pin_pagetable_pfn calls BUG()

ok, i tried to fix this in test10, but no idea if it's enough...

by **bplant** » Mon Oct 27, 2008 7:44 am

PaX Team wrote:ok, i tried to fix this in test10, but no idea if it's enough...

At first it wouldn't boot, but after a couple of hours of debugging I decided that 64MB wasn't enough RAM for the guest machine (although the vanilla kernel seemed to get by). It was calling panic() in __reserve_early. After increasing the RAM I managed to boot a minimal kernel (UP, no filesystems, drivers, etc). Obviously it didn't get very far though without any filesystems etc compiled in to mount /.

I tried a full blown config, but it crashed early on. I'll progressively turn on features (SMP and the like) tomorrow to try and track down where the problem is.

This is good progress though. Good work!

by **PaX Team** » Mon Oct 27, 2008 10:55 am

bplant wrote:At first it wouldn't boot, but after a couple of hours of debugging I decided that 64MB wasn't enough RAM for the guest machine (although the vanilla kernel seemed to get by). It was calling panic() in __reserve_early.

what was the panic message? there're two panic calls in that function, would be better to know what the message was exactly. that may be a hint why 64MB wasn't enough, otherwise i have no idea, unlike on i386, i don't really change the kernel memory layout on amd64, save for some alignment on the kernel code/data segments. makes me think, try to compare readelf outputs of both kernels plus the dmesg where the initial memory layout is logged.

I tried a full blown config, but it crashed early on.

again, logs would speak more than the mere fact that something went wrong

.

by **cormander** » Mon Oct 27, 2008 12:59 pm

PaX Team wrote:
bplant wrote:Ok, I've spent all day trying to do some background research. I haven't gotten far, but thought I would share anyway. The PaX patched kernel is calling BUG() in pin_pagetable_pfn in arch/x86/xen/enlighten.c, line 836. The call stack is as follows:

arch/x86/xen/enlighten.c:1711 xen_start_kernel calls xen_setup_kernel_pagetable
arch/x86/xen/enlighten.c:1600 xen_setup_kernel_pagetable calls pin_pagetable_pfn
arch/x86/xen/enlighten.c:836 pin_pagetable_pfn calls BUG()
ok, i tried to fix this in test10, but no idea if it's enough...

I built out a test dom0 with xen 3.3.0 and used the test10 patch on a 2.6.27.4 kernel as a guest... I can confirm that the above error doesn't happen anymore, but the console still doesn't even print any bootup messages, it just hangs (whereas the same config boots a vanilla kernel just fine).

Do you need a diff on the readelf outputs of the two different kernels?

by **bplant** » Mon Oct 27, 2008 7:07 pm

It was "Overlapping early reservations". Here is the backtrace in case you want it. Note: this is a UP kernel running with 64MB RAM.

Code: Select all: #0 0xffffffff802c0f10 in delay_loop (loops=1) at arch/x86/lib/delay.c:32 #1 0xffffffff802c0f8a in __delay (loops=1) at arch/x86/lib/delay.c:109 #2 0xffffffff802c0fb7 in __const_udelay (xloops=1) at arch/x86/lib/delay.c:123 #3 0xffffffff80224064 in panic (fmt=0x18c7d7d9 <Address 0x18c7d7d9 out of bounds>) at kernel/panic.c:139 #4 0xffffffff803b00ef in __reserve_early (start=2097152, end=6291456, name=0xffffffff8034c820 "TEXT DATA BSS", overlap_ok=0) at arch/x86/kernel/e820.c:806 #5 0xffffffff803b02b2 in reserve_early (start=2097152, end=6291456, name=0xffffffff8034c820 "TEXT DATA BSS") at arch/x86/kernel/e820.c:854 #6 0xffffffff803ac26f in x86_64_start_reservations (real_mode_data=0x1 <Address 0x1 out of bounds>) at arch/x86/kernel/head64.c:124 #7 0xffffffff803adb03 in xen_start_kernel () at arch/x86/xen/enlighten.c:1764

I was curious as to how much you had to increase the memory assigned to the VM as I previously assigned 1024MB when things worked. After a binary search I found that 881MB was the minimum required to make the machine boot. I'm guessing here, but is 880MB the maximum address in the lowmem region? I'm guessing that when highmem is involved the page table structure is different which is why one boots and the other does not.

Let me know if you want to know the parameters passed to reserve_early when the memory assigned is greater than 880MB and I'll trace through to find them.

Next I started turned on features to see what breaks. Turning on SMP (still only 1 CPU assigned to the guest VM though) caused some other troubles.

Code: Select all: #0 make_lowmem_page_readwrite (vaddr=0xffffffff80331000) at arch/x86/xen/mmu.c:228 #1 0xffffffff803e913f in xen_smp_prepare_boot_cpu () at include/asm/desc.h:176 #2 0xffffffff803e79c7 in start_kernel () at include/asm/smp.h:76 #3 0xffffffff803e7279 in x86_64_start_reservations (real_mode_data=0xffffffff80331000 "") at arch/x86/kernel/head64.c:144 #4 0xffffffff803e8cf0 in xen_start_kernel () at arch/x86/xen/enlighten.c:1764

For what it's worth; I tried booting with 2 cpus assigned to the VM, but it made no difference.

I stuck with UP and compiled in some filesytems, the xen frontend block device driver and initrd support. The use of initrd wasn't welcomed however.

Code: Select all: #0 __delay (loops=1) at arch/x86/lib/delay.c:108 #1 0xffffffff80315317 in __const_udelay (xloops=1) at arch/x86/lib/delay.c:123 #2 0xffffffff80223864 in panic (fmt=0x4490f68e <Address 0x4490f68e out of bounds>) at kernel/panic.c:139 #3 0xffffffff8042334f in __reserve_early (start=5001216, end=13393920, name=0xffffffff803ae116 "RAMDISK", overlap_ok=0) at arch/x86/kernel/e820.c:806 #4 0xffffffff80423512 in reserve_early (start=5001216, end=13393920, name=0xffffffff803ae116 "RAMDISK") at arch/x86/kernel/e820.c:854 #5 0xffffffff8041a2c8 in x86_64_start_reservations (real_mode_data=0x1 <Address 0x1 out of bounds>) at arch/x86/kernel/head64.c:132 #6 0xffffffff80420c53 in xen_start_kernel () at arch/x86/xen/enlighten.c:1764

Because my initrd is greater than 4MB, I was passing ramdisk=8192 on the command line. I tried compiling this option into the kernel (CONFIG_BLK_DEV_RAM_SIZE) just in case this was an issue, but it made no difference.

It seems that SMP and initrd are the only hitches at this stage. I found a small debian image on the net (I can't boot my own VMs without initrd because I am using evms/lvm). Using this image I was able to boot a system, log in via ssh etc.

Do you still want the "readelf -e" output comparing the vanilla and PaX patched images?

by **PaX Team** » Mon Oct 27, 2008 10:54 pm

bplant wrote:It was "Overlapping early reservations". Here is the backtrace in case you want it. Note: this is a UP kernel running with 64MB RAM.

thanks but i'd need to see the full message to know what previous region was reserved over the same range (as you can guess there should be nothing else in the kernel's code/data area, so there's definitely something wrong here).

Code: Select all
#0 make_lowmem_page_readwrite (vaddr=0xffffffff80331000) at arch/x86/xen/mmu.c:228 #1 0xffffffff803e913f in xen_smp_prepare_boot_cpu () at include/asm/desc.h:176 #2 0xffffffff803e79c7 in start_kernel () at include/asm/smp.h:76 #3 0xffffffff803e7279 in x86_64_start_reservations (real_mode_data=0xffffffff80331000 "") at arch/x86/kernel/head64.c:144 #4 0xffffffff803e8cf0 in xen_start_kernel () at arch/x86/xen/enlighten.c:1764

i think i know what xen's trying to do here, i'll try to fix it in the next test patch. if you want to experiment, you could remove the make_lowmem_page_readwrite() call in xen_smp_prepare_boot_cpu().

Do you still want the "readelf -e" output comparing the vanilla and PaX patched images?

yes, it won't hurt to have some extra info.

by **bplant** » Tue Oct 28, 2008 1:17 am

PaX Team wrote:
bplant wrote:It was "Overlapping early reservations". Here is the backtrace in case you want it. Note: this is a UP kernel running with 64MB RAM.
thanks but i'd need to see the full message to know what previous region was reserved over the same range (as you can guess there should be nothing else in the kernel's code/data area, so there's definitely something wrong here).

So you want me to set a breakpoint at reserve_early and __reserve_early and record all the parameters passed? If not, what "full message" are you referring to?

PaX Team wrote:
bplant wrote:Do you still want the "readelf -e" output comparing the vanilla and PaX patched images?
yes, it won't hurt to have some extra info.

As in "readelf -a"? I can email this to you shortly if you like.

by **bplant** » Tue Oct 28, 2008 2:02 am

bplant wrote:
PaX Team wrote:
bplant wrote:It was "Overlapping early reservations". Here is the backtrace in case you want it. Note: this is a UP kernel running with 64MB RAM.
thanks but i'd need to see the full message to know what previous region was reserved over the same range (as you can guess there should be nothing else in the kernel's code/data area, so there's definitely something wrong here).

Ok, I put a breakpoint at reserve_early and __reserve_early and got a backtrace at each. Note, the VM has 64MB of memory assigned.

Code: Select all: #0 reserve_early (start=4616192, end=2048, name=0x1000 <Address 0x1000 out of bounds>) at arch/x86/kernel/e820.c:852 #1 0xffffffff803a7ab5 in xen_start_kernel () at arch/x86/xen/enlighten.c:1623 #0 __reserve_early (start=4644864, end=4644864, name=0xffffffff803482ba "XEN PAGETABLES", overlap_ok=-2143449088) at arch/x86/kernel/e820.c:797 #1 0xffffffff803aa262 in reserve_early (start=4616192, end=4644864, name=0xffffffff803482ba "XEN PAGETABLES") at arch/x86/kernel/e820.c:854 #2 0xffffffff803a7ab5 in xen_start_kernel () at arch/x86/xen/enlighten.c:1623 #0 reserve_early (start=2097152, end=2048, name=0x1000 <Address 0x1000 out of bounds>) at arch/x86/kernel/e820.c:852 #1 0xffffffff803a626f in x86_64_start_reservations (real_mode_data=0x200000 <Address 0x200000 out of bounds>) at arch/x86/kernel/head64.c:124 #2 0xffffffff803a7b76 in xen_start_kernel () at arch/x86/xen/enlighten.c:1769 #0 __reserve_early (start=6291456, end=6291456, name=0xffffffff80347b90 "TEXT DATA BSS", overlap_ok=-2143449088) at arch/x86/kernel/e820.c:797 #1 0xffffffff803aa262 in reserve_early (start=2097152, end=6291456, name=0xffffffff80347b90 "TEXT DATA BSS") at arch/x86/kernel/e820.c:854 #2 0xffffffff803a626f in x86_64_start_reservations (real_mode_data=0x200000 <Address 0x200000 out of bounds>) at arch/x86/kernel/head64.c:124 #3 0xffffffff803a7b76 in xen_start_kernel () at arch/x86/xen/enlighten.c:1769

Here is the same for the non-PaX kernel

Code: Select all: #0 reserve_early (start=4603904, end=2048, name=0x1000 <Address 0x1000 out of bounds>) at arch/x86/kernel/e820.c:852 #1 0xffffffff803a4aa1 in xen_start_kernel () at arch/x86/xen/enlighten.c:1618 #0 __reserve_early (start=4632576, end=4632576, name=0xffffffff803422ba "XEN PAGETABLES", overlap_ok=-2143461376) at arch/x86/kernel/e820.c:797 #1 0xffffffff803a7252 in reserve_early (start=4603904, end=4632576, name=0xffffffff803422ba "XEN PAGETABLES") at arch/x86/kernel/e820.c:854 #2 0xffffffff803a4aa1 in xen_start_kernel () at arch/x86/xen/enlighten.c:1618 #0 reserve_early (start=2097152, end=2048, name=0x1000 <Address 0x1000 out of bounds>) at arch/x86/kernel/e820.c:852 #1 0xffffffff803a32af in x86_64_start_reservations (real_mode_data=0x200000 <Address 0x200000 out of bounds>) at arch/x86/kernel/head64.c:124 #2 0xffffffff803a4b62 in xen_start_kernel () at arch/x86/xen/enlighten.c:1764 #0 __reserve_early (start=4456536, end=4456536, name=0xffffffff80341b98 "TEXT DATA BSS", overlap_ok=-2143461376) at arch/x86/kernel/e820.c:797 #1 0xffffffff803a7252 in reserve_early (start=2097152, end=4456536, name=0xffffffff80341b98 "TEXT DATA BSS") at arch/x86/kernel/e820.c:854 #2 0xffffffff803a32af in x86_64_start_reservations (real_mode_data=0x200000 <Address 0x200000 out of bounds>) at arch/x86/kernel/head64.c:124 #3 0xffffffff803a4b62 in xen_start_kernel () at arch/x86/xen/enlighten.c:1764

bplant wrote:
PaX Team wrote:
bplant wrote:Do you still want the "readelf -e" output comparing the vanilla and PaX patched images?
yes, it won't hurt to have some extra info.

As in "readelf -a"? I can email this to you shortly if you like.

Sorry, I misread what you said here. Here is the output from "readelf -e"

First, the PaX patched kernel

Code: Select all: ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x200000 Start of program headers: 64 (bytes into file) Start of section headers: 20166104 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 5 Size of section headers: 64 (bytes) Number of section headers: 43 Section header string table index: 40 Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS ffffffff80200000 00200000 00000000000fef5a 0000000000000000 AX 0 0 4096 [ 2] .notes NOTE ffffffff802fef5c 002fef5c 000000000000017c 0000000000000000 AX 0 0 4 [ 3] __ex_table PROGBITS ffffffff802ff0e0 002ff0e0 0000000000001180 0000000000000000 A 0 0 8 [ 4] .rodata PROGBITS ffffffff80301000 00301000 0000000000057260 0000000000000000 WA 0 0 4096 [ 5] __bug_table PROGBITS ffffffff80358260 00358260 0000000000003ac8 0000000000000000 A 0 0 1 [ 6] .pci_fixup PROGBITS ffffffff8035bd30 0035bd30 00000000000001d0 0000000000000000 A 0 0 16 [ 7] __param PROGBITS ffffffff8035bf00 0035bf00 0000000000001100 0000000000000000 A 0 0 8 [ 8] .data PROGBITS ffffffff8035d000 0035d000 000000000001f550 0000000000000000 WA 0 0 64 [ 9] .data.cacheline_a PROGBITS ffffffff8037d000 0037d000 0000000000000d00 0000000000000000 WA 0 0 64 [10] .data.read_mostly PROGBITS ffffffff8037dd00 0037dd00 0000000000002664 0000000000000000 WA 0 0 64 [11] .data.init_task PROGBITS ffffffff80382000 00382000 0000000000002000 0000000000000000 WA 0 0 32 [12] .data.page_aligne PROGBITS ffffffff80384000 00384000 0000000000021000 0000000000000000 WA 0 0 4096 [13] .vsyscall_0 PROGBITS ffffffffff600000 00400000 000000000000011b 0000000000000000 AX 0 0 16 [14] .vsyscall_fn PROGBITS ffffffffff600140 00400140 000000000000003f 0000000000000000 AX 0 0 16 [15] .vsyscall_gtod_da PROGBITS ffffffffff600180 00400180 0000000000000050 0000000000000000 WA 0 0 16 [16] .vsyscall_1 PROGBITS ffffffffff600400 00400400 000000000000003d 0000000000000000 AX 0 0 16 [17] .vsyscall_2 PROGBITS ffffffffff600800 00400800 0000000000000065 0000000000000000 AX 0 0 16 [18] .vgetcpu_mode PROGBITS ffffffffff600870 00400870 0000000000000004 0000000000000000 WA 0 0 16 [19] .jiffies PROGBITS ffffffffff600880 00400880 0000000000000008 0000000000000000 WA 0 0 16 [20] .init.text PROGBITS ffffffff803a6000 005a6000 0000000000016bb6 0000000000000000 AX 0 0 16 [21] .init.data PROGBITS ffffffff803bcbc0 005bcbc0 000000000000af08 0000000000000000 WA 0 0 32 [22] .init.setup PROGBITS ffffffff803c7ad0 005c7ad0 0000000000000828 0000000000000000 WA 0 0 8 [23] .initcall.init PROGBITS ffffffff803c82f8 005c82f8 0000000000000300 0000000000000000 WA 0 0 8 [24] .con_initcall.ini PROGBITS ffffffff803c85f8 005c85f8 0000000000000018 0000000000000000 WA 0 0 8 [25] .x86cpuvendor.ini PROGBITS ffffffff803c8610 005c8610 0000000000000030 0000000000000000 WA 0 0 16 [26] .parainstructions PROGBITS ffffffff803c8640 005c8640 000000000000b4fc 0000000000000000 A 0 0 8 [27] .altinstructions PROGBITS ffffffff803d3b40 005d3b40 00000000000002fb 0000000000000000 A 0 0 8 [28] .altinstr_replace PROGBITS ffffffff803d3e3b 005d3e3b 0000000000000086 0000000000000000 A 0 0 1 [29] .exit.text PROGBITS ffffffff803d3ed0 005d3ed0 0000000000000242 0000000000000000 AX 0 0 16 [30] .bss NOBITS ffffffff803d5000 005d4112 000000000006e018 0000000000000000 WA 0 0 4096 [31] .comment PROGBITS 0000000000000000 005d4112 000000000000771c 0000000000000000 0 0 1 [32] .debug_aranges PROGBITS 0000000000000000 005db830 0000000000007060 0000000000000000 0 0 16 [33] .debug_pubnames PROGBITS 0000000000000000 005e2890 0000000000015b71 0000000000000000 0 0 1 [34] .debug_info PROGBITS 0000000000000000 005f8401 0000000000b813ee 0000000000000000 0 0 1 [35] .debug_abbrev PROGBITS 0000000000000000 011797ef 0000000000064173 0000000000000000 0 0 1 [36] .debug_line PROGBITS 0000000000000000 011dd962 00000000000b8be5 0000000000000000 0 0 1 [37] .debug_frame PROGBITS 0000000000000000 01296548 000000000003c760 0000000000000000 0 0 8 [38] .debug_str PROGBITS 0000000000000000 012d2ca8 000000000003d500 0000000000000001 MS 0 0 1 [39] .debug_ranges PROGBITS 0000000000000000 013101b0 000000000002b210 0000000000000000 0 0 16 [40] .shstrtab STRTAB 0000000000000000 0133b3c0 0000000000000211 0000000000000000 0 0 1 [41] .symtab SYMTAB 0000000000000000 0133c098 000000000003afe0 0000000000000018 42 5736 8 [42] .strtab STRTAB 0000000000000000 01377078 000000000002610f 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000200000 0xffffffff80200000 0x0000000000200000 0x000000000015d000 0x000000000015d000 R E 200000 LOAD 0x000000000035d000 0xffffffff8035d000 0x000000000035d000 0x0000000000048000 0x0000000000048000 RW 200000 LOAD 0x0000000000400000 0xffffffffff600000 0x00000000003a5000 0x0000000000000888 0x0000000000000888 RWE 200000 LOAD 0x00000000005a6000 0xffffffff803a6000 0x00000000003a6000 0x000000000002e112 0x000000000009d018 RWE 200000 NOTE 0x00000000002fef5c 0xffffffff802fef5c 0x00000000002fef5c 0x000000000000017c 0x000000000000017c 4 Section to Segment mapping: Segment Sections... 00 .text .notes __ex_table .rodata __bug_table .pci_fixup __param 01 .data .data.cacheline_aligned .data.read_mostly .data.init_task .data.page_aligned 02 .vsyscall_0 .vsyscall_fn .vsyscall_gtod_data .vsyscall_1 .vsyscall_2 .vgetcpu_mode .jiffies 03 .init.text .init.data .init.setup .initcall.init .con_initcall.init .x86cpuvendor.init .parainstructions .altinstructions .altinstr_replacement .exit.text .bss 04 .notes

And the vanilla

Code: Select all: ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x200000 Start of program headers: 64 (bytes into file) Start of section headers: 19998072 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 5 Size of section headers: 64 (bytes) Number of section headers: 43 Section header string table index: 40 Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS ffffffff80200000 00200000 00000000001067f6 0000000000000000 AX 0 0 4096 [ 2] .notes NOTE ffffffff803067f8 003067f8 000000000000017c 0000000000000000 AX 0 0 4 [ 3] __ex_table PROGBITS ffffffff80306980 00306980 0000000000001180 0000000000000000 A 0 0 8 [ 4] .rodata PROGBITS ffffffff80308000 00308000 0000000000049e28 0000000000000000 A 0 0 32 [ 5] __bug_table PROGBITS ffffffff80351e28 00351e28 0000000000003a68 0000000000000000 A 0 0 1 [ 6] .pci_fixup PROGBITS ffffffff80355890 00355890 00000000000001d0 0000000000000000 A 0 0 16 [ 7] __param PROGBITS ffffffff80355a60 00355a60 00000000000005a0 0000000000000000 A 0 0 8 [ 8] .data PROGBITS ffffffff80356000 00356000 0000000000023930 0000000000000000 WA 0 0 4096 [ 9] .data.cacheline_a PROGBITS ffffffff8037a000 0037a000 0000000000000d00 0000000000000000 WA 0 0 64 [10] .data.read_mostly PROGBITS ffffffff8037ad00 0037ad00 0000000000002664 0000000000000000 WA 0 0 64 [11] .vsyscall_0 PROGBITS ffffffffff600000 00400000 000000000000011b 0000000000000000 AX 0 0 16 [12] .vsyscall_fn PROGBITS ffffffffff600140 00400140 000000000000003f 0000000000000000 AX 0 0 16 [13] .vsyscall_gtod_da PROGBITS ffffffffff600180 00400180 0000000000000050 0000000000000000 WA 0 0 16 [14] .vsyscall_1 PROGBITS ffffffffff600400 00400400 000000000000003d 0000000000000000 AX 0 0 16 [15] .vsyscall_2 PROGBITS ffffffffff600800 00400800 0000000000000065 0000000000000000 AX 0 0 16 [16] .vgetcpu_mode PROGBITS ffffffffff600870 00400870 0000000000000004 0000000000000000 WA 0 0 16 [17] .jiffies PROGBITS ffffffffff600880 00400880 0000000000000008 0000000000000000 WA 0 0 16 [18] .data.init_task PROGBITS ffffffff80380000 00580000 0000000000002000 0000000000000000 WA 0 0 32 [19] .data.page_aligne PROGBITS ffffffff80382000 00582000 0000000000021000 0000000000000000 WA 0 0 4096 [20] .init.text PROGBITS ffffffff803a3000 005a3000 0000000000016c06 0000000000000000 AX 0 0 16 [21] .init.data PROGBITS ffffffff803b9c20 005b9c20 000000000000af08 0000000000000000 WA 0 0 32 [22] .init.setup PROGBITS ffffffff803c4b30 005c4b30 0000000000000828 0000000000000000 WA 0 0 8 [23] .initcall.init PROGBITS ffffffff803c5358 005c5358 0000000000000300 0000000000000000 WA 0 0 8 [24] .con_initcall.ini PROGBITS ffffffff803c5658 005c5658 0000000000000018 0000000000000000 WA 0 0 8 [25] .x86cpuvendor.ini PROGBITS ffffffff803c5670 005c5670 0000000000000030 0000000000000000 WA 0 0 16 [26] .parainstructions PROGBITS ffffffff803c56a0 005c56a0 000000000000b52c 0000000000000000 A 0 0 8 [27] .altinstructions PROGBITS ffffffff803d0bd0 005d0bd0 00000000000002fb 0000000000000000 A 0 0 8 [28] .altinstr_replace PROGBITS ffffffff803d0ecb 005d0ecb 0000000000000086 0000000000000000 AX 0 0 1 [29] .exit.text PROGBITS ffffffff803d0f60 005d0f60 0000000000000242 0000000000000000 AX 0 0 16 [30] .bss NOBITS ffffffff803d2000 005d11a2 000000000006e058 0000000000000000 WA 0 0 4096 [31] .comment PROGBITS 0000000000000000 005d11a2 0000000000007769 0000000000000000 0 0 1 [32] .debug_aranges PROGBITS 0000000000000000 005d8910 00000000000070a0 0000000000000000 0 0 16 [33] .debug_pubnames PROGBITS 0000000000000000 005df9b0 0000000000015be2 0000000000000000 0 0 1 [34] .debug_info PROGBITS 0000000000000000 005f5592 0000000000b5d623 0000000000000000 0 0 1 [35] .debug_abbrev PROGBITS 0000000000000000 01152bb5 00000000000634f3 0000000000000000 0 0 1 [36] .debug_line PROGBITS 0000000000000000 011b60a8 00000000000b744f 0000000000000000 0 0 1 [37] .debug_frame PROGBITS 0000000000000000 0126d4f8 000000000003c7b0 0000000000000000 0 0 8 [38] .debug_str PROGBITS 0000000000000000 012a9ca8 000000000003d4d0 0000000000000001 MS 0 0 1 [39] .debug_ranges PROGBITS 0000000000000000 012e7180 000000000002b1e0 0000000000000000 0 0 16 [40] .shstrtab STRTAB 0000000000000000 01312360 0000000000000211 0000000000000000 0 0 1 [41] .symtab SYMTAB 0000000000000000 01313038 000000000003af98 0000000000000018 42 5734 8 [42] .strtab STRTAB 0000000000000000 0134dfd0 00000000000260ce 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000200000 0xffffffff80200000 0x0000000000200000 0x0000000000156000 0x0000000000156000 R E 200000 LOAD 0x0000000000356000 0xffffffff80356000 0x0000000000356000 0x0000000000027364 0x0000000000027364 RWE 200000 LOAD 0x0000000000400000 0xffffffffff600000 0x000000000037e000 0x0000000000000888 0x0000000000000888 RWE 200000 LOAD 0x0000000000580000 0xffffffff80380000 0x0000000000380000 0x00000000000511a2 0x00000000000c0058 RWE 200000 NOTE 0x00000000003067f8 0xffffffff803067f8 0x00000000003067f8 0x000000000000017c 0x000000000000017c 4 Section to Segment mapping: Segment Sections... 00 .text .notes __ex_table .rodata __bug_table .pci_fixup __param 01 .data .data.cacheline_aligned .data.read_mostly 02 .vsyscall_0 .vsyscall_fn .vsyscall_gtod_data .vsyscall_1 .vsyscall_2 .vgetcpu_mode .jiffies 03 .data.init_task .data.page_aligned .init.text .init.data .init.setup .initcall.init .con_initcall.init .x86cpuvendor.init .parainstructions .altinstructions .altinstr_replacement .exit.text .bss 04 .notes

grsecurity forums

xen + pax + 2.6.27

xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27

Re: xen + pax + 2.6.27