grsecurity forums

Hi,

when will a patch release for the 2.6.27 kernel?

I am waiting for. I don't want to install a old Kernel.

I've uploaded a test patch for 2.6.27.4.

-Brad

# make
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf -s arch/x86/Kconfig
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/linux/utsrelease.h
UPD include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-x86
/usr/src/linux-2.6.27.4/arch/x86/Makefile:243: ***
*** 2.6 PaX kernels no longer build correctly with old versions of binutils.
*** Please upgrade your binutils to 2.18 or newer. Schluss.

Whats that? I can't compile a Kernel with grsec on Debian etch?

A-N wrote:Whats that? I can't compile a Kernel with grsec on Debian etch?

if etch doesn't have binutils 2.18+ then it's not safe for PaX.

Can I disable PAX and run only grsecurity?

A-N wrote:Can I disable PAX and run only grsecurity?

the changes that most likely trigger the bug in earlier binutils versions are not under .config control.

so you are going to 'cut off' all the Etch comunity from next grsec version ?

RHEL5 has 2.17 and I ran into this problem ... I rebuilt 2.18 from the latest fedora and then was able to build the kernel just fine.

This begs the question, does just the kernel need to be built with the new binutils, or does the whole OS need to be recompiled, for full safety? I haven't noticed any problems with running the kernel yet...

jaaa wrote:so you are going to 'cut off' all the Etch comunity from next grsec version ?

if the only alternative is to revert some (yet to be determined, at that) PaX feature, then definitely yes. it's seemingly a toolchain bug, not something in PaX, so i could at most provide a workaround if i knew what it was. since i'm using neither debian nor such an old binutils, i won't debug this myself, but you're free to help out (my guess would be something around my percpu segment changes) and if it turns out that the binutils bug can be worked around, i'll put it into PaX. also since you're already compiling your own kernel, what prevents you from compiling your own binutils?

cormander wrote:This begs the question, does just the kernel need to be built with the new binutils, or does the whole OS need to be recompiled, for full safety? I haven't noticed any problems with running the kernel yet...

since i don't know what this binutils bug is, i cannot tell for sure, but i've never seen any similar userland breakage so i don't think you'll need to bother with userland.

Is there a chance to know when a new release of Grsec is ready?

There is almost 2.6.31 kernel. The last one stable was for 2.6.27.10

ngsupb wrote:Is there a chance to know when a new release of Grsec is ready?

There is almost 2.6.31 kernel. The last one stable was for 2.6.27.10

do you know about the 'test' patches? we've been following every single 2.6 release for some years now... as for when something makes it on the 'stable' page: there's no rule, and in reality it doesn't really matter, what we use and support is always the latest one.

[quote="PaX Team"]do you know about the 'test' patches? we've been following every single 2.6 release for some years now... as for when something makes it on the 'stable' page: there's no rule, and in reality it doesn't really matter, what we use and support is always the latest one.[/quote]

Thank you. Yes, I know about the test patches. But unfortunately only the stable worked last time without any problems. That is why I am afraid about the test patches :(

What was the last test patch you tried? What problem did you have? Did you report the problem? As you can tell from the forums, we respond very quickly to bug reports.

-Brad

It didn't even boot, so can't say what was wrong. If I remember correctly it was 2.6.29.6 on 32bit servers, but worked on 64bits.
Anyway it doesn't meter at this time, it was a month ago. I have used the stable one for 2.6.27.10 it worked fine.

Next time I will try to use the test patch for the latest kernel and report any problem if I find.

Thank you.