grsecurity forums

Hi all,

I am experiencing a strange problem:
when compiling a 2.6.24.5 vanillia kernel without patching it, it works.
When i patch it, it compiles but does not start.
In both case, I am beginning with the same config file.

Details:

I downloaded the vanilla linux kernel 2.6.24.5.
I uncompressed it to linux-2.4.24.5.
I linked the new fodler with "linux".
I copied my actual config file into the linux folder.
I compiled (make-kpkg with Debian), and installed it.
No problem.

I deleted the linux-2.4.24.5 folder.
Once again, I uncompressed it to linux-2.4.24.5.
I linked the new fodler with "linux".
I patched the source with grsecurity.
I copied my actual config file into the linux folder.
I configured grsecurity in HIGH mode.
I compiled (make-kpkg) and installed it.
It hangs on :"Uncompressing Linux...Ok, booting the kernel"

Any idea ?

Thanks

evilangel wrote:Any idea ?

besides trying a newer kernel (.24 isn't supported), try to upgrade your binutils to 2.18 as older versions are known to produce non-working kernel images.

(.24 isn't supported)

I am surprised of this.
On the main page of the grsecurity website, in the news frame, it is written:

[04/21] grsecurity 2.1.11 patches updated, 2.6.24.5 supported

UPDATE:
I made another test, using the vanillia 2.6.24.5 kernel patched with grsecurity, but with grsecurity not activated.
I used my actual config file.
It compiles and boots.

We always track the latest 2.6 kernel, since we can't maintain each of the 2.6 kernel releases. For security reasons, it's not wise to be using older kernels due to the large amount of silently fixed vulnerabilities (especially now that it's the kernel developers' standard operating procedure). Just last night I uploaded a patch for 2.6.27.4, the latest "stable" 2.6 kernel release. These are available on http://grsecurity.net/test.php

-Brad

spender wrote:For security reasons, it's not wise to be using older kernels due to the large amount of silently fixed vulnerabilities (especially now that it's the kernel developers' standard operating procedure).

I can't tell you how much I've found this to be true. I've been maintaining the "stable" grsecurity patch (more or less .... 2.6.24.7) for a while now. I'm up to over 40 patches for it after grsecurity - a good portion of them from linux kernel CVEs I keep up on - the other chunk from me going through Linus' git tree every now and then and finding blatantly obvious things that never get any real attention. There were even a few times where I download a new CVE patch only to find that I already have the patch in the kernel, it was pulled out of git.

It's looking like I might rebase our kernel to 2.6.27.x for the next 6 months or so before I end up just rebasing it again

Thanks for all these info.

I upgraded my Debian from Etch to Lenny.
The exact same procedure (vanillia + patch + config file updated + make-kpkg ) is working now !

I closed the topic a bit too fast...
I am experiencing the problem again on a fresh Debian Lenny install.

I precise, I am testing it in a VirtualBox environement.

It seems the problem is known:
http://www.virtualbox.org/ticket/3

I'll try on VmWare

I reused the same configuration for the kernel on a REAL processor.
THere was no problem to compile and boot with the new kernel.