grsecurity forums

Hi.

The subject says it all really. I get a kernel panic on this Debian Sarge machine when I turn on grsecurity in the kernel. I can apply the patch and the kernel boots, it's only when the patch is actually enabled that I get problems.

Hardware:
Cyrix 6x86 P166+
64mb ram
2.1gb HD.
2.4.27 kernel with 2.0.1 grsecurity patch.
Custom security level. Most pretty much everything turned on (don't have details to hand right now, the machine which has the config file on it refuses to start )

This is what's one the screen when the kernel panics (please excuse the typos, typeing this by hand was enough of a pain in the ass!):

Code: Select all

Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Enabling CPUID on Cyrix processor.
CPU: Cyrix 6x86L 2x Core/Bus Clock stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
invalid operand: 0000
CPU:     0
EIP:     0010:[<00000c01>]   Not tainted
EFLAGS: 00010046
eax: 0000001  ebx: c0112000  ecx: c0112000  edx: 0000001
esi: c0113fc4  edi: c0546000  ebp: 0008e000   exp: c0113f88
ds: 0018  es: 0018  ss: 0018
Process swapper (pid: 0, stackpage=c0113000)
Stack: c0112000 00001f5d 00010f00 00000270 00000000 c0113fc4 c0546000 0008e000
      00000001 00000018 00000078 0000077a c10e0010 00000206 00000000
      c0112000 0000eff6 00000270 00000000 00010e00 00000000 000a0600 00000221
Call trace: [<00001f5d>]  [<00010f00>] [<00000270>] [<00000000>] [<0008e000>]
[<00000001 [<00000018>] [<00000018>] [<00000078>] [<00000077a>] [<00000206>]
[<00000000 [<0000eff6>] [<00000270>] [<00000000>] [<00010e00>] [<00000000>]
[<000a0600 [<00000221>] [<00000270>] [<00000000>] [<00010e00>] [<00000189>]

Code: 0f 31 83 e0 1f 8d 1c 85 00 00 00 00 9c 59 fa b8 00 50 11 00
  <0> Kernel panic: Attempted to kill the idle task!
In idle task - not syncing

Any ideas?

PS. I attempted a Gentoo install on the same machine, got the same problems with the kernel, so tried Debian. so I'm fairly sure it's not a distro problem.

Thanks in advance.

-Ribs.

Ribs wrote:Cyrix 6x86 P166+

what's your CPU type in .config? it seems that whatever you chose, you enabled TSC (time stamp counter) support which your CPU apparently doesn't have. then you also enabled RANDKSTACK (you wouldn't be able to if your CPU doesn't have a TSC) which relies on the TSC and that ended up in a crash.

This I know from memory;
It's set up as a 586. The exact entry is:
586/K5/5x86/6x86/6x86MX

Which falls under the CPU I use. I think all this does it add -march 586 to the gcc commands, which optimises it for my CPU. This setting should be working.

In addition, I add MTRR (Memory Type Range Register) support to the kernel. Again, this applies to my CPU correctly, so should work.

Wouldn't the TSC support cause the kernel to crash anyway without grsecurity? Or am I talking out of my arse?

How should I fix this? Compile for 386/486?

Thanks,

-Ribs.

Ribs wrote:Wouldn't the TSC support cause the kernel to crash anyway without grsecurity?

it would and that's why TSC support is not enabled for your CPU normally, and that's why i don't understand how you could enable RANDKSTACK at all (which has a dependency on the TSC).

How should I fix this? Compile for 386/486?

no, just don't use RANDKSTACK.

Hi,

I managed to get the system booted thanks to the Debian woody install CD. It seems I haven't got the varible you mention in my kernel config. I have a varible which is similar to it (CONFIG_GRKERNSEC_PAX_RANDUSTACK), which I have turned off, and I'm now waiting for my system to re-compile the kernel before I try again (it takes a while on this old hardware!)

Here is the GRSecurity part of my config. I didn't want to paste the whole thing in fear of getting told off for an excessivly long post:

Code: Select all

#
# Grsecurity
#
CONFIG_GRKERNSEC=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_SHA256=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MID is not set
# CONFIG_GRKERNSEC_HI is not set
CONFIG_GRKERNSEC_CUSTOM=y

#
# PaX Control
#
# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set
CONFIG_GRKERNSEC_PAX_EI_PAX=y
CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set

#
# Address Space Protection
#
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_KERNEXEC=y
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_IO=y
CONFIG_RTC=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_HIDESYM=y

#
# Role Based Access Control Options
#
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set
# CONFIG_GRKERNSEC_AUDIT_CHDIR is not set
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
# CONFIG_GRKERNSEC_AUDIT_IPC is not set
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
# CONFIG_GRKERNSEC_AUDIT_TEXTREL is not set

#
# Executable Protections
#
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
# CONFIG_GRKERNSEC_TPE is not set

#
# Network Protections
#
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
CONFIG_GRKERNSEC_SOCKET=y
CONFIG_GRKERNSEC_SOCKET_ALL=y
CONFIG_GRKERNSEC_SOCKET_ALL_GID=1004
CONFIG_GRKERNSEC_SOCKET_CLIENT=y
CONFIG_GRKERNSEC_SOCKET_CLIENT_GID=1003
CONFIG_GRKERNSEC_SOCKET_SERVER=y
CONFIG_GRKERNSEC_SOCKET_SERVER_GID=1002

#
# Sysctl support
#
# CONFIG_GRKERNSEC_SYSCTL is not set

#
# Logging options
#
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4

-Ribs.

Ribs wrote:I managed to get the system booted thanks to the Debian woody install CD. It seems I haven't got the varible you mention in my kernel config. I have a varible which is similar to it (CONFIG_GRKERNSEC_PAX_RANDUSTACK), which I have turned off, and I'm now waiting for my system to re-compile the kernel before I try again (it takes a while on this old hardware!)

RANDUSTACK won't change anything, it's RANDKSTACK that you ran into. the fact that you don't have it in your .config but apparently have it compiled in suggests that maybe you haven't fully recompiled your kernel after a configuration change? other than that, i see no way you can end up with having the RANDKSTACK code in your kernel.

This is the thing, it never was turned on... I have just a kernel, no modules or anything, and the kernel is 'completley' remade each time (make clean && make dep && make bzImage). I just tried to boot the kernel, and, as you predicted, it doesn't make any difference. Same error.

I'll try make mrproper and explictly add no to the .config file for that option. See if that helps..

-Ribs.

Ribs wrote:I'll try make mrproper and explictly add no to the .config file for that option. See if that helps..

check include/linux/autoconf.h for the RANDKSTACK define, it must not be in there.

PaX Team wrote:check include/linux/autoconf.h for the RANDKSTACK define, it must not be in there.

Not there. And the kernel is still panicing on boot. I'm pretty certain this option is not running now.

I don't think that grsecurity will work on this CPU. Which is a great shame.

This time, I've noticed I get a 'unable to handle kernel paging request at virtual address 00114000'

It still complains about the swapper task, but this time it says 'Attempted to kill init!' at the end...

-Ribs.

Ribs wrote:This time, I've noticed I get a 'unable to handle kernel paging request at virtual address 00114000'

It still complains about the swapper task, but this time it says 'Attempted to kill init!' at the end...

can you post the related oops messages? also, the corresponding System.map file would be helpful (gzip/email it to me directly).

Well, after much research, I think I've got it.

It seems that support for the SiS5513 chipset in the kernel breaks a lot of things. Turning it off allows the kernel to boot with GRSecurity without any problems, at the cost of DMA support. Seems it was nothing to do with GRSecurity at all.

Thanks for all the help, I'm glad this is finally sorted.

-Ribs.