2.6.29.3 compilation problem

[forsaken]

I'm getting this error when I'm compiling 2.6.29.3 with grsecurity-2.1.14-2.6.29.3-200905131918.patch:

LD vmlinux
ld: vmlinux: section .rodata vma 0xffffffff8060b000 overlaps previous sections
ld: vmlinux: section __bug_table vma 0xffffffff806e8840 overlaps previous sections
ld: vmlinux: section .pci_fixup vma 0xffffffff806ef630 overlaps previous sections
ld: vmlinux: section __param vma 0xffffffff806f0bd0 overlaps previous sections
ld: vmlinux: section `.rodata' can't be allocated in segment 2
LOAD: .vsyscall_0 .vsyscall_fn .vsyscall_gtod_data .vsyscall_1 .vsyscall_2 .vgetcpu_mode .jiffies .rodata __bug_table .pci_fixup __param
ld: final link failed: Bad value
make: *** [vmlinux] Error 1

On Gentoo hardened with gcc-4.3.3.
Edit: x86_64 aswell

[joshuapl]

Hi,

I'm experiencing the same problem.
First I thought that it was something about my .config (copied from 2.6.27.5+grsecurity), but then I tried to compile the raw kernel with few grsecurity and PAX options enabled (make mrproper && make menuconfig && make bzImage)

Ah, one thing worth mentioning - this system is on x86_64.

Greetings,
--
Jacek
Poland

[spender]

Hang in there, the PaX team is aware of the problem and will have a fix for it soon hopefully.

And when it's all over with, modifying the vsyscall table with a single write to reliably transfer from interrupt to process context (like in the remote root exploit at http://kernelbof.blogspot.com/) won't be possible anymore.

-Brad

[forsaken]

Nice.

[hanno]

Ping?

The 2.6.29.3 update is a security update with real-world exploits floating around on milw0rm. Not the kind of update you wanna keep back.

[spender]

The vsyscall patch still needs more work, so for now I've reverted it and uploaded a new patch.

-Brad

[forsaken]

The new patch works fine, thanks.

[spender]

I've uploaded new patches that have the read-only vsyscall shadow map on x64 kernels. I also added /proc/<pid>/cmdline as one of the things protected (along with /proc/<pid>/fd and /proc/<pid>/mem) by the "d" subject flag in the RBAC system.

-Brad

[joshuapl]

Works for me too, after rebooting everything seems go run smoothly. Thanks!