unbootable kernel 2.6.14.6

Sebastian Faulborn sfaulborn at web.de
Sun Apr 23 07:40:50 PDT 2006


I hope this gets through your new spam filter!

I have had the same problems with kernel 2.6.14.6 not booting correctly
like lots of other people. I have done some investigation on this and
found out the following:

First of all - all tests have been done on a 3GHz Pentium 4. I have made
sure that there are no hardware problems: other kernels compile fine,
glibc and memtest86 passe all tests.

All sources were taken from hlfs-packages-unstable-glibc-20060406.tar.

- if I compile the kernel without any patches applied, it boots fine.
So kernel 2.6.14.6 is ok.
- if I patch with linux-2.6.14.6-pseudo_random-1.patch only, the kernel
panics way before init is started. The exact place depends on the kernel
features which are enabled. This behaviour does not depend on the
toolchain used. I have tried an old LFS-6.1 and the current hlfs-20060220.
Both exhibit the same behaviour.
- if I patch with the old linux-2.6.14.3-pseudo_random-1.patch only, the
kernel boots fine.

The kernel panic looks as follows (typed off a photograph!):
************************************************************************
vesafb: mode is 1280x1024x32, linelength=5120, pages=0
vesafb: protected mode interface info at c000:dfe0
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:0:0:0, shift=24:16:8:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
Unable to handle kernel NULL pointer dereference at virtual address 00000000
  printing eip:
c0227baa
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:
CPU: 0
EIP: 0060:[<c0227baa>] Not tainted VLI
EFLAGS: 00010283 (2.6.14.6-sslx-single)
EIP is at vsnprintf+0x2a/0x540
eax: dff345cf   ebx: dff34580   ecx: 00000000   edx: 000000d0
esi: dff345d0   edi: dff29c80   ebp: dff345e3   esp: c14fff68
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=c14fe000 task=c14d7a50)
Stack: ...

Call Trace:
  [<c013b545>] kzalloc+0x15/0x40
  [<c0261a48>] class_device_create+0x58/0x80
  [<c0250c3d>] frandom_init_module+0x10d/0x185
  [<c035f1c7>] vty_init+0x107/0x120
  [<c035ea4c>] tty_init+0x18c/0x1a0
  [<c034c7ed>] do_initcalls+0x4d/0xb0
  [<c01002a0>] init+0x0/0x180
  [<c01002c7>] init+0x27/0x180
  [<c0100ea5>] kernel_thread_helper+0x5/0x10
Code: 00 55 57 56 53..
.. 4c 24
<0>Kernel panic - not syncing: Attempted to kill init!
************************************************************************

Note: this happens way before init is started - even if the last message
states otherwise.

The only change between the two patches is this line (this is a diff of
diffs!):

 > diff -Naur linux-2.6.14.6.orig/drivers/char/frandom.c 
linux-2.6.14.6.frandom/drivers/char/frandom.c
 > --- linux-2.6.14.6.orig/drivers/char/frandom.c        1970-01-01 
00:00:00.000000000 +0000
 > +++ linux-2.6.14.6.frandom/drivers/char/frandom.c     2006-01-22 
06:30:35.000000000 +0000
452c452
< +             class_device_create(frandom_class,
---
 > +             class_device_create(frandom_class, NULL,
466,468c466,468

I'm not sure why some people get their kernel to work even with the new
patch. It possibly depends on some settings in the kernel configuration.

- grsec hangs when mounting the root filesystem on an ext3 partition after
the "kjournald" message appears. There is no panic but the kernel does not
continue to boot. This is still before the init process is started. I have
found out that this behaviour only happens when
"pax/Non-executable pages/Paging based non-executable pages" is enabled.
When using "Segmentation based non-executable pages" the kernel boots fine.
According to the documentation both do the same but by using a different
"hack". On i386 architectures, non-executable pages are not supported by
the hardware, and therefore one of the hacks is used (you can enable both
but then you have to select which one of them you want to use. One of them
offers more memory per process, the other is slightly faster). Since
different CPUs offer different ways of memory  management, different 
types of
registeres and tricks are used even for the same hack. So its not surprising
that if there is a bug in this code, that it would work on some hardware and
that it breaks on other ones.

Maybe it would be a good idea to open up a new directory in the download 
area
with working .config files for each kernel version (with a note on the 
applied
patches) so that people with problems could check whether their problems
depend on kernel settings?

To get a working 2.6.14.6 kernel:
- un-tar linux-2.6.14.6.tar.bz2
- patch with linux-2.6.14.3-pseudo_random-1.patch
- patch with grsecurity-2.1.8-2.6.14.6-200601211647.patch.bz2

make menuconfig:
enable "pax/Non-executable pages/Segmentation based non-executable pages
disable Paging based non-executable pages

you can enable all other pax/grsec features (leave out kmem/privileged IO in
case of XOrg)

I have not tested how stable the system is, but it seems to work fine.

I hope this helps some of those who reverted to kernel 2.6.14.3 and that the
problems with frandom/pax will be found soon!

Sebastian Faulborn
Homepage: http://www.secure-slinux.org





More information about the hlfs-dev mailing list