2.6.19 - init problem - still not resolved

[kolargol]

Hi,

Recent kernel 2.6.19 + spender's parch from 3'Dec still kills init on PAX enabled config (just plain settings + grsec profile set to "high" ) also passing "nosep" to kernel parameters - dont help.

OS: Debian (unstable)

just to let You know...

[Tommy]

On my box, grsecurity-2.1.9-2.6.19-200612031550.patch crash system on any module load.

[PaX Team]

Recent kernel 2.6.19 + spender's parch from 3'Dec still kills init on PAX enabled config (just plain settings + grsec profile set to "high" ) also passing "nosep" to kernel parameters - dont help.

OS: Debian (unstable)

what glibc is that exactly? also, can you try to boot with vdso=0? other than this, i'm out of ideas until you can get some logs about the crash...

[PaX Team]

next time could you please open a separate thread?

On my box, grsecurity-2.1.9-2.6.19-200612031550.patch crash system on any module load.

what crashes exactly, the kernel? if so, can you capture/post the logs along with your .config? also, could you try the PaX patch alone?

[kolargol]

Recent kernel 2.6.19 + spender's parch from 3'Dec still kills init on PAX enabled config (just plain settings + grsec profile set to "high" ) also passing "nosep" to kernel parameters - dont help.

OS: Debian (unstable)

what glibc is that exactly? also, can you try to boot with vdso=0? other than this, i'm out of ideas until you can get some logs about the crash...

about glic - debian packages ver. 2.12.4-1

and i will try right away to disable VDSO...

[kolargol]

well, disabling VDSO resolves problem. It can be done by kernel config, or passing parameter during boot.

[PaX Team]

about glic - debian packages ver. 2.12.4-1

uhm, i think 2.12.x will be released in the far future , didn't you mean 2.1.2 or 2.2.4 or similar instead?

[PaX Team]

well, disabling VDSO resolves problem. It can be done by kernel config, or passing parameter during boot.

ok, that's interesting especially if your glibc is something like 2.2 or older as they should be oblivious to the presence of the vDSO. now once you managed to boot with vdso=0, you can re-enable it via /proc/sys/vm/vdso_enabled and can strace something to see how it crashes exactly. note that if you're unlucky, it'll render your system unusable (everything executed afterwards will keep crashing) and you'll need to reboot, so save your important work beforehand.

[kolargol]

of course it was debian build number (package),
glibc ver. is 2.3.6. Debian as i think have its own build glibc fixes, patches etc... (not sure what exactly).
i will check by strace what is going on (only if strace itself not crashes ; )

[kolargol]

well, disabling VDSO resolves problem. It can be done by kernel config, or passing parameter during boot.

ok, that's interesting especially if your glibc is something like 2.2 or older as they should be oblivious to the presence of the vDSO. now once you managed to boot with vdso=0, you can re-enable it via /proc/sys/vm/vdso_enabled and can strace something to see how it crashes exactly. note that if you're unlucky, it'll render your system unusable (everything executed afterwards will keep crashing) and you'll need to reboot, so save your important work beforehand.

as i assume, after echo "1" to vdso, everything starts to sigsegv, but i have tweaked ulimit (dumpcore size) and generated coredump, so if You want to see it write to me at prv.
Backtrace dont show much, as ls dont have any symbols:

Code: Select all

(no debugging symbols found)
Core was generated by `ls --color=auto'.
Program terminated with signal 11, Segmentation fault.
#0  0x4b19effc in ?? ()
(gdb) bt
#0  0x4b19effc in ?? ()
#1  0x00000000 in ?? ()


[PaX Team]

as i assume, after echo "1" to vdso, everything starts to sigsegv, but i have tweaked ulimit (dumpcore size) and generated coredump, so if You want to see it write to me at prv.
Backtrace dont show much, as ls dont have any symbols:

Code: Select all

(no debugging symbols found)
Core was generated by `ls --color=auto'.
Program terminated with signal 11, Segmentation fault.
#0  0x4b19effc in ?? ()
(gdb) bt
#0  0x4b19effc in ?? ()
#1  0x00000000 in ?? ()


ok, looks like some library (glibc ?) address. can you run a few more commands on it: x/10i $pc, info reg, x/8x $sp. also, if you grok i386 asm, the first insn listed will probably access some memory, i'd like to see what is at that address (if anything). if it's still not clear after this, i'd need the library binary in question. and someone tell debian and other distros that stripping debug info in this millennium is utterly useless and counter-productive.

[Tommy]

My problem is gone, grsecurity-2.1.9-2.6.19-200612061905.patch works perfect on medium+ lvl.

My confing if any one still want it
http://skyline.ltd.pl/config

[Hal9000]

Code: Select all

  OBJCOPY arch/i386/boot/compressed/vmlinux.bin
make[3]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 153
make[2]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make[1]: *** [bzImage] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.19'
make: *** [stamp-build] Error 2


i am unable to compile 2.6.19 with same settings as 2.6.17.11... any clue what could be wrong?

[kolargol]

ok, looks like some library (glibc ?) address. can you run a few more commands on it: x/10i $pc, info reg, x/8x $sp. also, if you grok i386 asm, the first insn listed will probably access some memory, i'd like to see what is at that address (if anything). if it's still not clear after this, i'd need the library binary in question. and someone tell debian and other distros that stripping debug info in this millennium is utterly useless and counter-productive.

ok:

x/10i $pc:

Code: Select all

0x4b19effc:     Cannot access memory at address 0x4b19effc


info reg:

Code: Select all

eax            0x4b19b838       1259976760
ecx            0xffffe000       -8192
edx            0x4      4
ebx            0x4b1b2ff4       1260072948
esp            0x597e76d0       0x597e76d0
ebp            0x597e7800       0x597e7800
esi            0x4b1ae387       1260053383
edi            0x0      0
eip            0x4b19effc       0x4b19effc
eflags         0x10202  [ IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0xc018007b       -1072168837
es             0xc03d007b       -1069744005
fs             0x0      0
gs             0x0      0


x/8x $sp:

Code: Select all

0x597e76d0:     0x00000000      0x00000000      0x00000000      0x00000000
0x597e76e0:     0x00000000      0x00000000      0x00000000      0x00000000


[PaX Team]

x/10i $pc:

Code: Select all

0x4b19effc:     Cannot access memory at address 0x4b19effc


doh, new strategy is needed. load your app (ls) in gdb (gdb /bin/ls) then enable the vdso then start ls in gdb (run <args>). this will break in gdb when the problem occurs but the child process will be still present and x/i will work better.

ecx 0xffffe000 -8192

this looks like the old vDSO base address, so chances are it's glibc assuming something that's not true anymore: the vDSO when enabled is randomized under .19 and glibc should take that into account (i wonder how this works under vanilla .19 without COMPAT_VDSO, can you try it?).