book brokenness, etc
bobb at netslyder.net
Thu Feb 8 14:17:38 PST 2007
Welcome back. :)
I have been following your progress as I notice changes in the
2.4-branch of svn. First off thank you for your hard work. I had not
noticed the latest updates you mentioned here, but I will svn update and
have a look tonight. I will post any issues I come across to the list.
Robert Connolly wrote:
>Hello. I just realized linuxfromscratch.org is the mail server now, not
>mail.linuxfromscratch.org. 1800 messages later, I'm back.
>I fixed some of the uClibc 2.4-book issues this week. Chapter 5 builds now. I
>haven't finished a chapter 6 build in a very long time, and I know there are
>various problems. There was a post a while ago about adding the assertions to
>a header, so fputs=assert(fputs) all the time, and I think this is a better
>idea but I just haven't gotton to it yet. I apologize for the brokenness in
>chapter 6 and the kernel. I'll try to start removing the assertions stuff
>from chapter 6 and finish by adding a new header for <stdio.h> to wrap
>affected functions in assert().
>I'm concentrating mainly on the 2.4 branch but adding differences that work to
>the trunk too. I finally added the hardened-specs header, minus
>stack-protector, to the 2.4-branch. And switched uClibc-snapshot with
>I got rid of that Sed patch because it broke Sed.
>Regarding the two mail threads about testing the security of an HLFS system,
>there is a Paxtest package at the PaX website that I'd like to add to the
>book somewhere. There are also of course the test suites for each package.
>And fixing compiler warnings, including backporting gcc-4.3 fixes to the
>2.4-branch gcc-3.4 systems. Assertions aren't intended to be used on a
>production system because of performance loss, but I think it's a good idea
>because they will abort programs that have unforeseen errors. The
>gcc41 'unused return value' warning fixed with assertions should make sure
>every function has a contingency plan for errors.
>I'd like to mention that people who want to run linux-2.6 can still build the
>2.4-book and simply boot a 2.6 kernel. 2.6 isn't stable, even though it runs
>well without crashing. My cdrom used to be named /dev/hda in 2.6.18, and is
>named /dev/sr0 in 2.6.19. Using the 2.6 kernels involves constant adjustments
>to userland configuration, like Udev, which inherently means it's in the
>development stage. The 2.6.18.x branch seems to be being maintained parallel
>to the latest kernels, but who knows how long this will last. The 2.4-branch
>system will allow the system to boot anything after linux-2.4.20, or so, but
>won't have performance features from the later kernels.
>I've been thinking of adding pages to cross build a uClibc system, either at
>the end of chapter 5 or near the end of the book, with examples of building a
>4MB embedded system for a mips (netgear) router/firewall or an initrd for
>booting a loop-aes encrypted drive... a Busybox system. I think this is more
>what uClibc is intended for. It would preferably be built from an HLFS system
>so the host is more trusted, but doesn't necessarily have to be. The howto's
>for rescue systems are fairly out of date, aren't very specific, don't
>mention firewalling, often lack boot scripts, and adding loop-aes, sshd
>(dropbear), or addressing security concerns only complicates it. So I think
>it deserves a place in the (b)hlfs-book. The uClibc config for an embedded
>system isn't the same as for a full featured system because things like GCC
>(wchar) support are not needed, so the libraries can be cut smaller.
>So anyway, I'll start try to fix chapter 6 so the book isn't broken anymore.
More information about the hlfs-dev