grsecurity forums

Hi,

I just tried to compile vanilla kernel 2.6.29.6 using the current grsec patch from the web site. Additionally DRBD is patched into
that kernel. When starting the resulting kernel the server hangs complaining about segfaults in init. COMPAT_VDSO (mentioned
in a recent post) is not activated. When compiling the kernel without grsec, all works as expected.
Please find further information on my web server using the URL http://www.unlieb.de/grsec/.

Please let me know what to do to get the kernel booting.

Thanks in advance,
Andreas

elahaase wrote:Please let me know what to do to get the kernel booting.

could you try to enable some PaX options to see which one gets it to work?

Hi,

I tried to enable the following additional config options:

CONFIG_PAX=y
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_HAVE_ACL_FLAGS=y
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_SECURE_VSYSCALL=y

After building the kernel the error remains the same. Because this is a production server I can't try all possibilities and reboot it many times. Do you have any suggestions for what constellation could the server make boot again?

Bye,
Andreas

elahaase wrote:After building the kernel the error remains the same. Because this is a production server I can't try all possibilities and reboot it many times. Do you have any suggestions for what constellation could the server make boot again?

i know it works (for me at least) when the non-exec pages related options are enabled. also can you tell me what your distro/userland is exactly? and what is the version of glibc?

Hi,

I'm using Debian 4.0r8 amd64 and the version of glibc is 2.3.6.ds1-13etch9. Why is it mandatory to
enable some pax features? Until now I've just used the grsec features and no one of pax without having
any problem.

elahaase wrote:I'm using Debian 4.0r8 amd64 and the version of glibc is 2.3.6.ds1-13etch9.

ok, that's an old glibc, i'll have to check how it uses the vsyscall page.

Why is it mandatory to enable some pax features?

it's not mandatory but to help me debug the problem it may help to know which, if any, feature fixes it.

If I'm correct Debian 4.0 standard installs an old version of binutils (which caused problems with pax).
I don't think there were other problems with that debian-version.
I assume you currently have a working version installed, since you did not run into problems.

viewtopic.php?f=3&t=2094&p=8679#p8679

I still have an x86-32 system running debian using a recent grsecurity patch. I thought the current libc-version was 2.3.6.ds1-13etch9+b1.

Hi,

would it be possible to use a Debian Lenny as build host and install the resulting kernel package on the Debian Etch hosts?
Do you expect any problems doing so?

Bye,
Andreas

Since lenny uses binutils 2.18.1 you can compile without errors.
The only package I replaced on etch was the binutils.
I used the lenny source-package to compile a working version and build a new package.

The pax guy could tell if the binutils are used after the compilation. I would not expect any specific problems.

That said, the only reason I still use etch/old stable is that I haven't found time to distupgrade yet.
The distupgrade was scheduled within the next month, but for a good reason I could postpone it a little.

Hi,

today I backported binutils from Lenny to Etch and after rebuilding the kernel using the new utils the error remains the same. So the old binutils don't seem to be the reason for the segfaults.

I never expected binutils to solve your problem. I'm a bit surprised you have been able to work with the old utils since the problems have been around more than a year.

I could try to run your PAX/GRSEC config on different hardware (debian oldstable) or the PAX/GRSEC-settings on debian unstable amd64.
I'd think the last one is most interesting.

The other issue which yields lose ends is the patch. You claim to have installed a DRBD-patch, but you never stated which patch.
Since grsecurity is a patch for a backported kernel it could be either 8.2 or 8.3.git I assume.
From what I have seen people are preparing DRBD to be part of the kernel, but there are a few "showstoppers".

The only test I can try is vanilla + grsec to see if it boots.

Hi specs,

sorry, the version of DRBD is 8.0.16. I generated a patch against the vanilla kernel plus grsec patch. Today I've had time to try some more constellations to find the problem. There are really strange things happening. The problematic host is a HP DL320 G5p. On another server (DL320 G6, Debian Etch) the kernel is booting without problems. Another thing I found out is that 2.6.29.2 with grsec and almost the same configuration as mentioned is working well. May be 2.6.29.3 also works, but I don't have the grsec patch for that anymore. 2.6.29.5 seems to be the first kernel version causing the problems.

Until now I have no good explanation for that :-/

I have tried compiling a kernel for my AMD64 with only the GRSEC and PAX-settings copied.
I also got a segfault with debian unstable (libc6 2.9-21).

Only problems are diskspace and time. So I can probably try 1 kernel at a time until I have time to free some diskspace.
Screenshot, config and vmlinux http://www.aoi-karin.net/grsec/index.html

I won't try compiling a kernel for a 32-bit oldstable system.
Also I won't try including DRBD.

elahaase wrote:Until now I have no good explanation for that :-/

the vsyscall removal feature was added around 2.6.29.4, that's what you're seeing here. except i don't know yet why it can fail the way it does.

specs wrote:I have tried compiling a kernel for my AMD64 with only the GRSEC and PAX-settings copied.
I also got a segfault with debian unstable (libc6 2.9-21).

could you try to enable the non-exec related options and see which one gets it to work?