Patch for 2.6.20?

[mguevara]

After little change to http://www.grsecurity.net/~paxguy1/pax-linux-2.6.20.1-test5.patch (renamed to pax-linux-2.6.20.patch) the i686 build ended successfully (for config options above).

Code: Select all

diff -u SOURCES/pax-linux-2.6.20.patch:1.1.2.8 SOURCES/pax-linux-2.6.20.patch:1.1.2.9
--- SOURCES/pax-linux-2.6.20.patch:1.1.2.8   Fri Mar  2 11:46:31 2007
+++ SOURCES/pax-linux-2.6.20.patch   Tue Mar  6 10:43:49 2007
@@ -3620,7 +3620,7 @@
    .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { *(.exit.data) }
    . = ALIGN(4096);
    .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
-@@ -193,11 +121,131 @@ SECTIONS
+@@ -193,11 +121,134 @@ SECTIONS
     *(.data.percpu)
     __per_cpu_end = .;
    }
@@ -3750,7 +3750,9 @@
 +  . = ALIGN(4096);
 +
    .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
--   __init_end = .;
++#ifndef CONFIG_PAX_KERNEXEC
+    __init_end = .;
++#endif
     __bss_start = .;      /* BSS */
     *(.bss.page_aligned)
     *(.bss)

[PaX Team]

After little change to http://www.grsecurity.net/~paxguy1/pax-linux-2.6.20.1-test5.patch (renamed to pax-linux-2.6.20.patch) the i686 build ended successfully (for config options above).

-test6 fixes it properly, yours would free a little bit too much memory .

[mguevara]

Thanks. I have encountered another problem with compiling pax enabled 2.6.20.2 for ppc architecture:

Code: Select all

  CC      arch/ppc/mm/fault.o
In file included from include/linux/uaccess.h:5,
                 from include/linux/highmem.h:6,
                 from arch/ppc/mm/fault.c:26:
arch/ppc/include/asm/uaccess.h: In function 'strncpy_from_user':
arch/ppc/include/asm/uaccess.h:437: warning: comparison of unsigned expression >= 0 is always true
arch/ppc/mm/fault.c: At top level:
arch/ppc/mm/fault.c:404: error: redefinition of 'pax_handle_fetch_fault'
arch/ppc/mm/fault.c:119: error: previous definition of 'pax_handle_fetch_fault' was here
make[1]: *** [arch/ppc/mm/fault.o] Error 1
make: *** [arch/ppc/mm] Error 2


My config for ppc is:

Code: Select all

$ grep PAX .config
CONFIG_PAX=y
CONFIG_PAX_SOFTMODE=y
# CONFIG_PAX_EI_PAX is not set
CONFIG_PAX_PT_PAX_FLAGS=y
# 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=y
CONFIG_PAX_EMUSIGRT=y
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_EMUPLT=y
CONFIG_PAX_SYSCALL=y
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
# CONFIG_PAX_MEMORY_SANITIZE is not set

Looks like the error message is right - we have two definitions of 'pax_handle_fetch_fault' (not yet tested removing one of them).

[voidptr]

Hi,

If you are using PPC you should check out some of the changes made by the PaX team in September 2006, and using a new feature offered by gcc-4. They allow you to use PPC without the use of emuplt. It does however require your entire system to be built with the newer gcc-4. This action is probably only really feasible on something like gentoo which makes rebuilding your toolchain a bit easier... but still a long wait time :)

The reason why to do it is, you'll get a serious performance increase... as in a less that 1% change from vanilla as shown by the following time outputs from kernel compiles under pax and under vanilla.

pax-2.6.18-test4
2099.90user 188.97system 37:24.76elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (31major+7986444minor)pagefaults 0swaps

2105.04user 190.85system 37:11.33elapsed 102%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (16major+7986081minor)pagefaults 0swaps

2103.76user 192.32system 37:11.06elapsed 102%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (16major+7986800minor)pagefaults 0swaps


2.6.18-vanilla
2086.58user 197.04system 37:19.54elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (60major+7975605minor)pagefaults 0swaps

2093.63user 197.42system 37:06.98elapsed 102%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7975667minor)pagefaults 0swaps

2096.61user 195.19system 37:03.96elapsed 103%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7975665minor)pagefaults 0swaps

The downside to this all is that you wont get PIE/SSP support from the hardened profile under gentoo, since you'll need gcc-4 which is not supported by hardened gentoo yet. If you can live without it, fine :)


A summary from emails I sent earlier over time to various people:

So as some of you know I've been working on building ppc with msecure-plt that comes with gcc4. This is to facilitate in making the plt non-writable.

What I did was edit toolchain.eclass and toolchain-binutils.eclass to add "--enable-secureplt" to the configure arguments. (I could have used EXTRA_ECONF)

Also I used ~arch of binutils, 2.17, which seems to be required.

After that I don't know exactly what I did, but it comes down to bootstrapping, and perhaps handmerging binutils/gcc in case of trouble. (most notably the "assembler doesn't support msecure-plt" error.)

After this I've added msecure-plt to cflags in make.conf.

Emerge -e system and be a happy man, apart from the new automake-wrapper changes kicking in on random software: coreutils, dev-libs/popt and sys-process/time.


I am using kernel pax-linux-2.6.18-test4 without emuplt.

sanity ~ # uname -a
Linux sanity 2.6.18 #3 SMP Fri Sep 22 01:25:56 CEST 2006 ppc 7400, altivec supported GNU/Linux

sanity ~ # cat /etc/make.conf
CFLAGS="-O2 -mcpu=7400 -mtune=7400 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -msecure-plt"
CHOST="powerpc-unknown-linux-gnu"
CXXFLAGS="${CFLAGS}"
FEATURES="nostrip buildpkg"
MAKEOPTS="-j3"
USE="crypt hardened nls pam pic readline ssl tcpd userlocales zlib -gtk -fortran -ldap -X"

sanity ~ # cat /proc/self/maps
00100000-00103000 r-xp 00100000 00:00 0 [vdso]
10000000-10005000 r-xp 00000000 03:05 2334423 /bin/cat
10014000-10015000 rw-p 00004000 03:05 2334423 /bin/cat
10015000-1003b000 rw-p 10015000 00:00 0 [heap]
31ee1000-31efe000 r-xp 00000000 03:05 82719 /lib/ld-2.4.so
31efe000-31eff000 rw-p 31efe000 00:00 0
31f0d000-31f0e000 r--p 0001c000 03:05 82719 /lib/ld-2.4.so
31f0e000-31f0f000 rw-p 0001d000 03:05 82719 /lib/ld-2.4.so
31f0f000-31f10000 rw-p 31f0f000 00:00 0
31f13000-3204f000 r-xp 00000000 03:05 82720 /lib/libc-2.4.so
3204f000-3205e000 ---p 0013c000 03:05 82720 /lib/libc-2.4.so
3205e000-32063000 r--p 0013b000 03:05 82720 /lib/libc-2.4.so
32063000-32064000 rw-p 00140000 03:05 82720 /lib/libc-2.4.so
32064000-32067000 rw-p 32064000 00:00 0
7ddf8000-7de0d000 rw-p 7ddf8000 00:00 0 [stack]


Note: On hardened-2.6.17-r1 the stack showed up as rwx, which was a bit silly.

Readelf -ed reports:

LOAD 0x000000 0x10000000 0x10000000 0x04468 0x04468 R E 0x10000
LOAD 0x004468 0x10014468 0x10014468 0x001d8 0x00320 RW 0x10000

02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .got2 .dynamic .got .plt .data .sdata .sbss .bss

You might see here that .plt is in RW, however the pax author told me it was not the actual plt, but probably something remaining for compatibility reasons. Under my circumstances nothing executes from it atleast :) The actually plt was apparently embedded in .text.

[dweekly]

Now it's 2.6.20.2 time and still no grsec release. I'm willing to pay money to get a quality release out the door for this.

[spender]

PaX isn't ready for a stable release yet for 2.6.20. I've ported my side of the code to 2.6.20 already, but won't be uploading the test patch yet until PaX boots on SMP.

-Brad

[dweekly]

Okay - is there a rough ETA? I guess where my toes got bruised is that I had had the (mistaken!) impression that as soon as 2.6.20.1 was out the door we'd see a grsec release. It's ok that that is not the case, but I'm just hoping for a rough ETA on when we can expect a grsecurity for 2.6.20 so I know how to plan. There's actually a fair amount of stuff in 2.6.20 we need in our cluster, but we only deploy grsecurity kernels.

And I'm not just trying to whine about the release schedule - I really am willing to help fund some ongoing development.

[mguevara]

I've ported my side of the code to 2.6.20 already, but won't be uploading the test patch yet until PaX boots on SMP.

Just FYI - I'm running smp-enabled 2.6.20.3 kernel on an (unfortunatelly) single i686 class CPU with test7 PaX patches. Are the SMP booting problems visible on real SMP machines or with some architecture or with some CONFIG_PAX options (KERNEXEC for example?).

[spender]

SMP kernels on actual UP hardware seems fine, but SMP kernels on SMP hardware panics at bootup.

-Brad

[atomik]

Here I use an SMP kernel on a Athlon X2 (in 64bit) and test6,7 works OK

[PaX Team]

the test9 patch should fix the early boot crash, please try it and let me know.

[stkn]

yes, test9 is finally booting on our box (core2 duo)

there's a build-time issue since test8 though:

Code: Select all

  CC      arch/i386/kernel/asm-offsets.s
In file included from include/asm/elf.h:52,
                 from include/linux/elf.h:7,
                 from include/linux/module.h:15,
                 from include/linux/crypto.h:21,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/desc.h: In function 'native_set_ldt':
include/asm/desc.h:125: error: read-only variable 'ret__' used as 'asm' output
include/asm/desc.h:125: error: read-only variable 'ret__' used as 'asm' output
include/asm/desc.h:125: error: read-only variable 'ret__' used as 'asm' output
In file included from include/linux/crypto.h:21,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/module.h: In function '__module_get':
include/linux/module.h:400: error: read-only variable 'ret__' used as 'asm' output
include/linux/module.h:400: error: read-only variable 'ret__' used as 'asm' output
include/linux/module.h:400: error: read-only variable 'ret__' used as 'asm' output
include/linux/module.h: In function 'try_module_get':
include/linux/module.h:410: error: read-only variable 'ret__' used as 'asm' output
include/linux/module.h:410: error: read-only variable 'ret__' used as 'asm' output
include/linux/module.h:410: error: read-only variable 'ret__' used as 'asm' output
In file included from include/asm/suspend.h:7,
                 from include/linux/suspend.h:5,
                 from arch/i386/kernel/asm-offsets.c:11:
include/asm/i387.h: In function '__save_init_fpu':
include/asm/i387.h:63: error: read-only variable 'ret__' used as 'asm' output
include/asm/i387.h:63: error: read-only variable 'ret__' used as 'asm' output
include/asm/i387.h:63: error: read-only variable 'ret__' used as 'asm' output
make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1


that one is caused by

Code: Select all

include/asm-i386/pda.h:16   const int cpu_number;


removing the "const" fixes it.

[MrTux]

I've a problem with vanilla 2.6.20.4 and grsecurity-2.1.10-2.6.20.3-200703231034.patch for i586 (grsecurity completely disabled):

Code: Select all

  CC      arch/i386/mm/fault.o
arch/i386/mm/fault.c: In function 'do_page_fault':
arch/i386/mm/fault.c:668: error: invalid operands to binary -
make[1]: *** [arch/i386/mm/fault.o] Fehler 1
make: *** [arch/i386/mm] Fehler 2

W/o the grsecurity-patch it compiles cleanly.

[spender]

Have you tried the latest patch against 2.6.20.4?

-Brad

[MrTux]

Have you tried the latest patch against 2.6.20.4?

I tried grsecurity-2.1.10-2.6.20.4-200703261947.patch, same problem.

Sven