xen + pax + 2.6.27

[cormander]

OK I was able to enable most PAX options after setting the control to hook and it booted. Here is my PAX config:

Code: Select all

CONFIG_PAX=y
CONFIG_PAX_SOFTMODE=y
# CONFIG_PAX_EI_PAX is not set
# CONFIG_PAX_PT_PAX_FLAGS is not set
# CONFIG_PAX_NO_ACL_FLAGS is not set
# CONFIG_PAX_HAVE_ACL_FLAGS is not set
CONFIG_PAX_HOOK_ACL_FLAGS=y
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
# CONFIG_PAX_EMUTRAMP is not set
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_NOELFRELOCS is not set
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_REFCOUNT=y


I tried to compile both versions of paxtest but they die with:

Code: Select all

make[1]: Entering directory `/root/paxtest-0.9.7-pre4'
gcc    -c -o crt1S.o crt1S.S
crt1S.S: Assembler messages:
crt1S.S:5: Error: suffix or operands invalid for `pop'
crt1S.S:10: Error: suffix or operands invalid for `pop'
crt1S.S:12: Error: suffix or operands invalid for `push'
crt1S.S:13: Error: suffix or operands invalid for `push'
crt1S.S:14: Error: suffix or operands invalid for `push'
crt1S.S:15: Error: suffix or operands invalid for `push'
crt1S.S:16: Error: suffix or operands invalid for `push'
crt1S.S:17: Error: suffix or operands invalid for `push'
crt1S.S:18: Error: suffix or operands invalid for `push'
crt1S.S:19: Error: suffix or operands invalid for `push'
crt1S.S:20: Error: suffix or operands invalid for `push'
crt1S.S:21: Error: suffix or operands invalid for `push'
make[1]: *** [crt1S.o] Error 1
make[1]: Leaving directory `/root/paxtest-0.9.7-pre4'


This was on a 64bit box ... so I jumped over to a 32 bit box and it built just fine. I then copied over the resulting afer "make generic" and ran the paxtest on the 2.6.27.4 with test13 and got these results:

Code: Select all

Mode: blackhat
Linux localhost.localdomain 2.6.27.4 #4 SMP Tue Nov 4 14:02:09 MST 2008 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)              : Vulnerable
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (ET_DYN)         : 8 bits (guessed)
Main executable randomisation (ET_EXEC)  : 10 bits (guessed)
Main executable randomisation (ET_DYN)   : 10 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 10 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 10 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Killed
Executable shared library data           : Killed
Writable text segments                   : Vulnerable


Also, in dmesg I see:

Code: Select all

[   28.046913] anonmap[1514]: segfault at f7f5a000 ip 00000000f7f5a000 sp 00000000ffffea8c error 15
[   28.052187] execbss[1517]: segfault at 8049b34 ip 0000000008049b34 sp 00000000ffffe29c error 15 in execbss[8049000+1000]
[   28.054438] execdata[1520]: segfault at 8049b28 ip 0000000008049b28 sp 00000000ffffdc5c error 15 in execdata[8049000+1000]
[   28.056580] execheap[1523]: segfault at 8049cb8 ip 0000000008049cb8 sp 00000000ffffe76c error 15 in execheap[8049000+1000]
[   28.064803] execstack[1526]: segfault at ffffc388 ip 00000000ffffc388 sp 00000000ffffc37c error 15
[   28.620987] shlibbss[1770]: segfault at f7f06548 ip 00000000f7f06548 sp 00000000ffffde0c error 15 in shlibtest2.so[f7f06000+1000]
[   28.623402] shlibdata[1773]: segfault at 0 ip 0000000000000000 sp 00000000ffffe9fc error 14 in shlibdata[8048000+1000]


Does this look right to you?

Thanks!

[PaX Team]

I tried to compile both versions of paxtest but they die with:

both as in? note that the version in my temp directory has a few Makefiles, Makefile.psm is probably the most generic that may work on amd64 as well. note also that paxtest doesn't/cannot use the ACL system therefore at least for testing, you should enable one of the ELF marking methods else you're testing default OS behaviour only (which explains why the MPROTECT tests failed or why the ASLR values are so low).

Code: Select all

[   28.623402] shlibdata[1773]: segfault at 0 ip 0000000000000000 sp 00000000ffffe9fc error 14 in shlibdata[8048000+1000]


Does this look right to you?

that one is wrong for example (a bug in that version of paxtest), so you'd better use the one in my temp dir.

[bplant]

Hi Corey,

Code: Select all

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed


Well it looks like the NX-bit is working for you. I've been talking to Jeremy Fitzhardinge and the NX-bit is working for him too. I tried his config, but still no luck. No idea why it isn't working for me. I have uploaded my vmlinux image (no pax) to http://www.ayuda.com.au/pub/xen/vmlinux ... bplant.bz2. Can you please download it and try it on your system. It is a 64-bit image, but it should boot a 32-bit domU.

Cheers,

Brad

[bplant]

Well it looks like the NX-bit is working for you. I've been talking to Jeremy Fitzhardinge and the NX-bit is working for him too. I tried his config, but still no luck. No idea why it isn't working for me. I have uploaded my vmlinux image (no pax) to http://www.ayuda.com.au/pub/xen/vmlinux ... bplant.bz2. Can you please download it and try it on your system. It is a 64-bit image, but it should boot a 32-bit domU.

Forget about trying my vmlinux image. I think the issue is with paxtest itself.

If I compile paxtest-0.9.7-pre5 on my xen box using "make -f Makefile.psm", then everything is reported as vulnerable. If I compile paxtest-0.9.7-pre5 using "make -f Makefile.psm" on my laptop (ubuntu 8.10) and scp the complied files across to my xen guest, then some of the tests are killed (not all because this is a vanilla kernel). Any idea why this is so?

Now when running paxtest (compiled on my laptop) on a pax enabled kernel, I get the following:

Code: Select all

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 33 bits (guessed)
Heap randomisation test (ET_EXEC)        : 40 bits (guessed)
Heap randomisation test (ET_DYN)         : 40 bits (guessed)
Main executable randomisation (ET_EXEC)  : 32 bits (guessed)
Main executable randomisation (ET_DYN)   : 32 bits (guessed)
Shared library randomisation test        : 33 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 40 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)
Return to function (strcpy)              : Killed
Return to function (memcpy)              : Killed
Return to function (strcpy, RANDEXEC)    : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Looks promising

[PaX Team]

If I compile paxtest-0.9.7-pre5 on my xen box using "make -f Makefile.psm", then everything is reported as vulnerable. If I compile paxtest-0.9.7-pre5 using "make -f Makefile.psm" on my laptop (ubuntu 8.10) and scp the complied files across to my xen guest, then some of the tests are killed (not all because this is a vanilla kernel). Any idea why this is so?

you didn't tell me what PaX control method you chose and what your toolchain generates on the two systems but apparently there's some difference. i guess it's either PAX_FLAGS or, more likely, GNU_STACK.

[bplant]

If I compile paxtest-0.9.7-pre5 on my xen box using "make -f Makefile.psm", then everything is reported as vulnerable. If I compile paxtest-0.9.7-pre5 using "make -f Makefile.psm" on my laptop (ubuntu 8.10) and scp the complied files across to my xen guest, then some of the tests are killed (not all because this is a vanilla kernel). Any idea why this is so?

you didn't tell me what PaX control method you chose and what your toolchain generates on the two systems but apparently there's some difference. i guess it's either PAX_FLAGS or, more likely, GNU_STACK.

I don't follow. I had CONFIG_PAX_PT_PAX_FLAGS=y if that's relevant. Something must have changed, as now that I have added grsec into the mix, paxtest works again.

[PaX Team]

I don't follow. I had CONFIG_PAX_PT_PAX_FLAGS=y if that's relevant. Something must have changed, as now that I have added grsec into the mix, paxtest works again.

if you enabled only PT_PAX_FLAGS support (but not EI_PAX) then the paxtest binaries must have that program header else they won't get any PaX features enabled on them, which would explain what happened in the first case. now to get that program header into the binaries you must have a patched binutils and i'm left wondering why on earth your ubuntu toolchain would have it . can you post readelf -l on any paxtest binary from both compilations?

[bplant]

Ok, I think I see where you're coming from. As expected, there are no pax flags in the ubuntu compiled binary.

Code: Select all

Entry point 0x400910
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000ecc 0x0000000000000ecc  R E    200000
  LOAD           0x0000000000001e08 0x0000000000601e08 0x0000000000601e08
                 0x0000000000000280 0x00000000000002a8  RW     200000
  DYNAMIC        0x0000000000001e30 0x0000000000601e30 0x0000000000601e30
                 0x00000000000001b0 0x00000000000001b0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000020 0x0000000000000020  R      4
  GNU_EH_FRAME   0x0000000000000d4c 0x0000000000400d4c 0x0000000000400d4c
                 0x0000000000000054 0x0000000000000054  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     8
  GNU_RELRO      0x0000000000001e08 0x0000000000601e08 0x0000000000601e08
                 0x00000000000001f8 0x00000000000001f8  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp
   02     .interp .note.ABI-tag .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag
   06     .eh_frame_hdr
   07     
   08     .ctors .dtors .jcr .dynamic .got

There are in the gentoo binary, but all I see is zeros in the PAX_FLAGS field.

Code: Select all

Entry point 0xd50
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x0000000000000230 0x0000000000000230  R E    8
  INTERP         0x0000000000000270 0x0000000000000270 0x0000000000000270
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001314 0x0000000000001314  R E    100000
  LOAD           0x0000000000001d30 0x0000000000101d30 0x0000000000101d30
                 0x00000000000002e8 0x00000000000002f0  RW     100000
  DYNAMIC        0x0000000000001d58 0x0000000000101d58 0x0000000000101d58
                 0x00000000000001c0 0x00000000000001c0  RW     8
  NOTE           0x000000000000028c 0x000000000000028c 0x000000000000028c
                 0x0000000000000020 0x0000000000000020  R      4
  GNU_EH_FRAME   0x00000000000011ac 0x00000000000011ac 0x00000000000011ac
                 0x0000000000000054 0x0000000000000054  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RWE    8
  GNU_RELRO      0x0000000000001d30 0x0000000000101d30 0x0000000000101d30
                 0x00000000000002d0 0x00000000000002d0  R      1
  PAX_FLAGS      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000         8

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .ctors .dtors .jcr .dynamic .got .data .bss
   04     .dynamic
   05     .note.ABI-tag
   06     .eh_frame_hdr
   07     
   08     .ctors .dtors .jcr .dynamic .got
   09     

Unfortunately, for disk space reasons, I had to delete the kernel source tree that I was using to test PaX when I started testing the grsec patch so I can't verify that I _only_ had PT_PAX_FLAGS enabled.

[PaX Team]

Ok, I think I see where you're coming from. As expected, there are no pax flags in the ubuntu compiled binary.

hmm then the ubuntu binaries could have produced the reported result only if EI_PAX had been enabled as well, but then any binaries should have produced the same result since the EI_PAX field is always present. in other words, i don't understand what exactly you tested at each step. just to be clear, you tried not two but three sets of paxtest binaries: first one compiled under the xen guest, second one compiled on your ubuntu and the third one compiled under some gentoo, is that correct? and of these, you're'saying that the latter two produced correct output (despite only the third one carrying the PT_PAX_FLAGS marking) whereas the first one didn't?

There are in the gentoo binary, but all I see is zeros in the PAX_FLAGS field.

that's normal, the actually important bits are not printed out by readelf, only paxctl.

[bplant]

hmm then the ubuntu binaries could have produced the reported result only if EI_PAX had been enabled as well, but then any binaries should have produced the same result since the EI_PAX field is always present. in other words, i don't understand what exactly you tested at each step. just to be clear, you tried not two but three sets of paxtest binaries: first one compiled under the xen guest, second one compiled on your ubuntu and the third one compiled under some gentoo, is that correct? and of these, you're'saying that the latter two produced correct output (despite only the third one carrying the PT_PAX_FLAGS marking) whereas the first one didn't?

xen guest == gentoo, so there was only 2 sets of binaries. Only the ubuntu set produced the correct output, but it didn't have any PAX_FLAGS markings.

Ok, I'm an idiot. I think I've just realised what I've done. The initrd that I was using had an old glibc so I had to turn on COMPAT_VDSO. At the time I forgot that this disabled some PaX features. I'm now using a new initrd so COMPAT_VDSO is off and all is good.

[generic_username]

Forgive the dumb question, but... so does this work? I've been following the grsec/xen threads for a while now, does grsec work with Xen in mainline? Is it stable? (for whatever definition of stable)

[bplant]

Forgive the dumb question, but... so does this work? I've been following the grsec/xen threads for a while now, does grsec work with Xen in mainline? Is it stable? (for whatever definition of stable)

I've had good results running it on several VMs. I haven't tried the latest patches however.

[bplant]

Hi PaX Team,

I've just tried test patch 15 for 2.6.28. The VM is calling BUG() in the exact same place (which you successfully fixed) as when I first tried the test patch for 2.6.27 a few months ago: viewtopic.php?f=1&t=2063&st=0&sk=t&sd=a#p8465 Is it possible that whatever fix(es) you included for 2.6.27 aren't currently included in 2.6.28 or are we looking at a new issue?

Background info - 2.6.28.4 kernel patched only with PaX with no PaX options enabled. The same .config boots a vanilla kernel fine.

Cheers,

Brad

[PaX Team]

I've just tried test patch 15 for 2.6.28. The VM is calling BUG() in the exact same place (which you successfully fixed) as when I first tried the test patch for 2.6.27 a few months ago: viewtopic.php?f=1&t=2063&st=0&sk=t&sd=a#p8465 Is it possible that whatever fix(es) you included for 2.6.27 aren't currently included in 2.6.28 or are we looking at a new issue?

can you be more specific with the BUG message?

[bplant]

I've just tried test patch 15 for 2.6.28. The VM is calling BUG() in the exact same place (which you successfully fixed) as when I first tried the test patch for 2.6.27 a few months ago: viewtopic.php?f=1&t=2063&st=0&sk=t&sd=a#p8465 Is it possible that whatever fix(es) you included for 2.6.27 aren't currently included in 2.6.28 or are we looking at a new issue?

can you be more specific with the BUG message?

What specify info are you after? This is the back trace:

Code: Select all

pin_pagetable_pfn (cmd=2154807176, pfn=4294967274) at arch/x86/xen/enlighten.c:854
854         BUG();
(gdb) bt
#0  pin_pagetable_pfn (cmd=2154807176, pfn=4294967274) at arch/x86/xen/enlighten.c:854
#1  0xffffffff80711d67 in xen_start_kernel () at arch/x86/xen/enlighten.c:1557