Confused about COMPAT_VDSO+Pax together.

[tjh]

Hello.

I just stumbled on this thread and did some testing on my system and realised sh*t, the best features of GrSec are disabled on my system at the moment!

I'm sure the change where COMPAT_VSDO being enabled disables Pax must only be recent? Or has it been like this for a while?

I have COMPAT_VDSO turned on because I am running Debian stable as my system which has glibc 2.3.2 installed. Upgrading glibc isn't really an option.

Is there some way to have Pax enabled and a system that boots? I was told that if I turn off COMPAT_VDSO that the system won't boot up. I'm just about to test this on my test system, but my first attempt to compile a kernel failed with some very weird errors. I'll post them here if it happens again.

Any suggestions, short of going back to 2.4? I'd much rather be on 2.6 because it has better SMP support.

Thanks,

Tim

[tjh]

Second time I tried to compile with COMPAT_VSDO disabled, it died with the same errors:

Code: Select all

ld: vmlinux: warning: allocated section `.text.align' not in segment
ld: vmlinux: warning: allocated section `.module.text' not in segment
  SYSMAP  System.map
  MODPOST vmlinux
  AS      arch/i386/boot/bootsect.o
  AS      arch/i386/boot/setup.o
  AS      arch/i386/boot/compressed/head.o
  CC      arch/i386/boot/compressed/misc.o
  OBJCOPY arch/i386/boot/compressed/vmlinux.bin
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 153
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2


Thanks, Tim

[Thrawn]

Look at this thread http://forums.grsecurity.net/viewtopic.php?t=1627

No chance to compile 2.1.10 on an debian sarge system ( due to binutils < 2.17 ) - on etch it compiles fine ( binutils = 2.1.7)

Maybe spender or paxteam can help here.

[PaX Team]

I'm sure the change where COMPAT_VSDO being enabled disables Pax must only be recent? Or has it been like this for a while?

this kernel option is very new, it was introduced along with VDSO randomization, and since i decided to finally make use of it, i also had to take care of the COMPAT_VDSO option (which is not compatible with several PaX features due to technical reasons).

I have COMPAT_VDSO turned on because I am running Debian stable as my system which has glibc 2.3.2 installed. Upgrading glibc isn't really an option.

then you're between a rock and a hard place, as they say... however, since this whole affair was due to a genuine glibc bug and debian tends to backport such fixes, you may still have a chance. i suggest that you simply disable COMPAT_VDSO, enable the other PaX options you want and see if your box boots. also, the fix isn't terribly complex, you should tell the debian folks to backport it if they haven't done so already.

I'm just about to test this on my test system, but my first attempt to compile a kernel failed with some very weird errors. I'll post them here if it happens again.

as others said already, you'll need a newer binutils to compile the kernel, i'll see if i can find a workaround (but i can't test it as i have only 2.17 around).

[tjh]

@PaX Team:

Thanks for your answers.

I thought I'd just fix my problem by downgrading to 2.4, but that locked up as it was booting one of the two CPUs (I'm not sure which, I'm 600km's away from the machine in question)

I've actually managed to find an old version of 2.6.17 that I have with PaX enabled so I've booted the machine with that for the moment as I consider my options.

Thanks for your suggestions.

Tim

[Thrawn]

as others said already, you'll need a newer binutils to compile the kernel, i'll see if i can find a workaround (but i can't test it as i have only 2.17 around).

If you need someone for tests i'm willing to help.

[tjh]

Thrawn: If you can, do what I did, find a different machine to compile the Kernel on.

My server is Debian, but I had no problem compiling it all on my Ubuntu laptop and moving the compiled image to my server.

I feel almost stupid for not realising this earlier! Of course, only works if you have access to more than one machine.

Thanks again to PaX Team for their help though.

[Thrawn]

Let see if i understand you correctly - compiling a 2.6.19.2 grsec kernel on a for example debian etch machine and move this kernel to a sarge machine?

Mhh I'll give it a try and report back.

[tjh]

Let see if i understand you correctly - compiling a 2.6.19.2 grsec kernel on a for example debian etch machine and move this kernel to a sarge machine?

Mhh I'll give it a try and report back.

Yup. Works perfectly.

Seems silly now you think about it huh?

[cocobello]

Look at this thread http://forums.grsecurity.net/viewtopic.php?t=1627

No chance to compile 2.1.10 on an debian sarge system ( due to binutils < 2.17 ) - on etch it compiles fine ( binutils = 2.1.7)

Maybe spender or paxteam can help here.

To compile on a debian sarge system with binutils < 2.17

1) Download the latest binutils. wget http://ftp.gnu.org/gnu/binutils/binutils-2.17.tar.bz2
2) tar xjpf binutils-2.17.tar.bz2
3) cd binutils-2.17
4) ./configure --prefix=/usr/local/binutils-2.17
5) make && make install

then you have binutils 2.17 installed in /usr/local/binutils-2.17

6) export OLD_PATH=$PATH
7) export PATH=/usr/local/binutils-2.17/bin/:$OLD_PATH

8) echo $PATH
output should be :
/usr/local/binutils-2.17/bin/:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin

then configure and compile your new kernel.