book brokenness, etc

Robert Baker 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.

R. Baker

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 
>uClibc-0.9.28.1.
>
>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.
>
>Robert
>  
>



More information about the hlfs-dev mailing list