kernel panic after build HLFS

Sebastian Faulborn sfaulborn at web.de
Thu Jun 22 14:42:34 PDT 2006


>On Wed, 2006-06-21 at 14:49 +0200, sacarde wrote:
>> 
>> I have correct file-patch, and now kernel works OK
>> 
>> thankyou
>> 
>> but now, ......... ?
>> 
>> BLFS is the right continuing to HLFS ?
>> can I apply BLFS without any changes ?
>
>Except where it barfs :-).
>
>There are a few gotchas to that process. If you have
>CONFIG_PAX_NOELFRELOCS  and randomised positioning of executables, then
>your executables can land anywhere and are not allowed to move to where
>they want to.

This is not a problem. Most packages work out of the box, others simply
need paxctl -m.

>
>This is a problem for: static libraries - The ones ending in .a, but
>it's never quite that simple; It is a problem for assembler which has
>hard addresses  in the binary. Gentoo-hardened used a check-textrel
>script with readelf -d |grep TEXTREL  as the key active line to check
>libs and executables.
>
>You have to strictly ban all precompiled code. No downloading of
>binaries - suffer with the source.

Not true. All precompiled binaries I have tried so far work (eg.
Java and MySQL).

>
>Expect fun with DRI, Mesa, & multimedia stuff where coders seem less
>fussy about form than performance. The hlfs stuff uses the line
>
>CFLAGS += -fpic -fPIC
>
>or somesuch added to Makefiles and it goes on after all the other
>CFLAGS. It ensures the options are passed.

Most people wont need DRI (unless you use HLFS to play games or use
it as a 3D graphics workstation). I use vesa framebuffer, don't need
any graphics drivers and with modern CPU you still don't see any
speed problems when using X.

>
>When you do barf, don't expect too much help. You're a big boy now :-).
>And fix it up, tell us how in one neat mail and we won't flame you :-). 
>
>
>-- 
>        With Best Regards,
>
>        Declan Moriarty.

Well, I don't quite agree.

I have comiled a few dozend packages from BLFS and other sources and mostly they work
without problems/changes. The gcc hardened specs file makes sure that everything is compiled
with ssp and pic (though not pie, but thats an optimisation anyway as far as I
understand). Disallowing TEXTRELs is no problem. If there is a program which has
TEXTRELs simply use "paxctl -m" on it and it will work (eg. zip/unzip or samhain).
So basically you can enable all PAX/GRSec features. 

There are problems with "early user space" a.k. initramfs - it causes kernel panics. 
I am back to initrd.

Loop-AES crashes with AES cipher (though not with serpent - which is more secure anyway). I
assume this is because I have PAX/kexec enabled in the kernel.

MySQL developers still believe that the 2.4.* kernel is the only acceptable base for a stable
system. So you have to patch the configure script so that it checks correctly for NTPL (See
BLFS wiki).
I have been running MySQL on a production system with HLFS for over 1 year without a crash of either
MySQL or HLFS and no reboot during that time!

Binary downloads are no problem. Eg: Java: install the binaries according to instructions at
java.sun.com and change all the pax flags with:

chpax -m /path/to/jdk/{jre,}/bin/*
(use paxctl if you compiled java yourself)

(Gentoo recommends -pemrxs but -m should be enough). Note that you will need to install chpax
(download from www.grsecurity.net). Whenever you download binaries, they will not be compiled
with the new ELF headers of the HLFS toolchain (binutil/gcc). Paxctl only operates on those new
headers, chpax changes the old style of ELF headers. Maybe you should put a note about this in
the book! Also enable the use of both new and old ELF headers in PAX.

Also: grsec will warn you about signal 11 beeing send to java ever so often
(grsec: From 207.46.98.45: signal 11 sent to /opt/j2sdk1.4.2_12/bin/java[java:18271] uid/euid:1007/1007
 gid/egid:1006/1006, parent ...). This is normal and does not mean that Java is crashing. It has
to do with the way Java handles its threads. Java should work 100% reliable. GRSecurity just 
shows what is going on (if you have logging of signals enabled).

Openssl, openssh, gnupg: build according to instructions in HLFS
Xorg: build according to instructions in HLFS

Everything else: build according to BLFS (I use development book) or if package
not in BLFS: according to instructions of package developer.

My System currenty consists of the following packages from BLFS:
- most of chapter 3
- chapter 4: cracklib, iptables, stunnel, sudo
- chapter 5: reiserfs
- chapter 6: about 1/2 of the libs
- chapter 7: all dependencies for XOrg
- chapter 11: most of it
- chapter 17: lynx
- chapter 18: most of it
- chapter 19: most of it
- chapter 21: vsftpd
- chapter 22: postfix
- chapter 23: Berkeley-DB, MySQL (latest 4.*)
- chapter 24: rsync
then Xorg with all its dependancies
- Xfce desktop environment with all its dependancies (gtk+ etc.)
- Firefox: you need to disable hardened specs, otherwise it will segfault on startup
(probably problem with SSP) 
- Gimp, OpenOffice
- CDR-tools, ghostscript, apache, PHP, resin, fcron

Other packages from other sources:
- Loop-AES with additional ciphers (use serpent)
- raidtools (need gcc patch), mdadm
- lvm2
- samhain (need paxctl -m)

So basically, most packages should install without problems or changes. If there are
TEXTRELs, use paxctl -m (or try to disable Assembler if possible during compilation).
Most problems are during compilation because of incompatiblities with kernel 2.6.*
respectively NTPL threading library. BLFS takes care of these problems in most
cases. Some problems arise when packages don't compile with gcc 3.4.5 because
of C/C++ language changes (newer compilers tend to be more strict - look for
patches in the internet). But those problems are the same for a current LFS system.

Note: I am using the glibc branch of HLFS. Some people still seem to have problems with
stability or even have problems compiling HLFS. The current version should work
with the exception of the kernel's frandom patch and possibly one setting of PAX (page exec)
-> see the postings in this mailing list over the past few weeks.

Hope this helps!

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








More information about the hlfs-dev mailing list