Continued support for the Lemote Yeeloong: Gentoo Mips is alive and well!

A few years back the Lemote Yeeloong made a splash in the open source community as the world’s first completely “open” system requiring no proprietary software.  Even its BIOS is open source.  It wasn’t long before pictures of Richard Stallman hugging his Yeeloong started popping up throughout the Internet, further boosting its popularity.  I became interested because the Yeeloong involves everything that’s near and dear to my heart: 1) Its loongson2f processor is a mips64el system and I love the slick nature of RISC architectures.  I can actually make sense of its ISA and the assembly.  2) As a 64-bit mips, it supports multiple ABIs, and I love playing with different ABIs.  The images I push come with o32, n32 and n64.  3) While other distros, like Debian, have ported their wares to the Yeeloong, these don’t have the hardening goodness that Gentoo does and so this was an added challenge.  Thanks to Magnus Granberg (zorry) for getting his hardened gcc patches work in mips.  4) Finally, it is “free” as in “libre”.  It is manufactured by Lemote in China, and I like to fantisize that hackers at the NSA curse everytime they encounter one in the wild, although the reality is more likely that I’m owned by the Chinese government :/

So here was the possibility of creating a free and secure system on my favorite architecture!  A couple of summers back, I took on the challenge.  I updated some older stages3 that Matt Turner (mattst88) had prepared and went through the process of seeing what desktop packages would build, which needed patching and which were hopelessly broken on mips, usually because of dependance on x86/amd64 assembly.  The end result was a minimal XFCE4 desktop with full userland hardening.  Unfortunatley, I still don’t have a PaX kernel working, but the issues do not appear to be insurmountable.

Building the initial images was more fun than maintaining them, but I’ve been good about it and I recently prepared release 20140630.  I even started to feel out the community more, so I announced this work as a project on freecode.com, just before the site closed down :(   If you get  a new Lemote Yeeloong, give these images a try.  It’ll save you about 4 days of compiling if you want to bootstrap from a stage3 to a full desktop, not counting all the broken packages you’ll probably hit along the way.  If you’re already running one of my images then you can try to update on your own but expect a lot of conflicts/blockings etc since mips is not a stable arch.  Perhaps the next step to making this more user-friendly is for me to provide the binpkgs on some host.

 

Lilblue Linux: release 20140520

A couple of days ago, I pushed out a new build of Lilblue Linux [1] which is my attempt to turn embedded Linux on its head and use uClibc [2] instead of glibc as the standard C library for a fully featured XFCE4 desktop for amd64. Its userland is built with Gentoo’s hardened toolchain, and the image ships with a kernel built using hardened-sources which include the Grsec/PaX patches for added security, but its main distinguishing feature from mainstream Gentoo is uClibc. Even though Lilblue is something of an experimental project which grew out of my attempt to get more and more packages to build against uClibc, the system works better than I’d originally expected and there are very few glitches which are uClibc specific. You get pretty much everything you’d expect in a desktop, including all your multimedia goodies, office software, games and browsers. mplayer2 works flawlessly!

But all is not well in the land of uClibc these days. It has been over two years since the last release, 0.9.33.2 on May 15, 2012, and there are about 80 commits sitting in the 0.9.33 branch, many of which address critical issues since 0.9.33.2. This causes problems for people building around uClibc, such as buildroot, and there has even been talk on the email lists of dropping uClibc as its main libc in favor of either glibc or musl [3]. Buildroot is maintaining about 50 backported patches, while Mike’s (aka vapier’s) latest patchset has 20. I seem to always have to insert a backported patch of my own here or there, or ask Mike to include it in his patchset.

For this release, I did something that I have mixed feelings about. Instead of 0.9.33.2 + backported patches, I used the latest HEAD of the 0.9.33 git branch. This saved me the trouble of getting more patches backported into a new revision of our 0.9.33.2 ebuild, or by “cheating” and putting the patches into /etc/portage/patches/sys-libs/uclibc, but it did expose a well known problem in uClibc, namely the problem of how its header files stack. A libc’s header files typically include one another to form a stack [4]. For example, on glibc, sched.h stacks as follows

    sched.h
        features.h
            sys/cdefs.h
                features.h
                bits/wordsize.h
            gnu/stubs.h
        bits/types.h
            features.h
            bits/wordsize.h
            bits/typesizes.h
        stddef.h
        time.h
            features.h
            stddef.h
            bits/time.h
                bits/types.h
                bits/timex.h
                    bits/types.h
            bits/types.h
            xlocale.h
        bits/sched.h

Here sched.h includes features.h, bits/types.h, stddef.h, time.h and bits/sched.h. In turn, features.h includes sys/cdefs.h and gnu/stubs.h, and so on. Each indentation indicates another level of inclusion. Circular inclusions are avoided by using #ifdef shields.

At least one reason for this structure is to abstract away differences in architectures and ABIs in an effort to present a hopefully POSIX compliant interface to the rest of userland. So, for example, glibc’s sys/syscall.h looks the same on amd64 as on mipsel, but it includes asm/unistd.h which is different on the two architectures. Each architecture’s asm/unistd.h have their own internal #ifdefs for the different ABIs proper to the architecture, and each #ifdef section in turn defines the values of the various syscalls appropriately for their ABI [5]. Another reason for this stacked inclusion is to make sure that certain definitions, macros or prototypes defined in one header are made available in another header in the same way as they are made available in a c file. This is the reason given, for instance, in the uClibc commit 2e2dc998 which I examine below.

Let’s see where uClibc’s header problems begin. Take a look at Gentoo’s bug #486782, where cdrtools-3.01_alpha17 fails to build against uClibc because its readcd/readcd.c defines “BOOL clone;” which collides with the definition of clone() in bits/sched.h [6]. Nowhere is sched.h included in readcd.c, instead bits/sched.h gets pulled in indirectly because stdio.h is included! Comment 7 reveals the stacking problem. stdio.h’s stacking is complex, but following just the bad chain, we see that stdio.h includes bits/uClibc_stdio.h which includes bits/uClibc_mutex.h which includes pthread.h which includes sched.h which includes bits/sched.h — wheh! If you’re wondering what stdio.h should have to do with sched.h, then you see the problem: too much information is being exposed here. Joerg’s comment on the bug pretty much sums it up: “The related include files (starting from what stdio.h includes) most likely expose the problem because they seem to expose implementation details that do not belong to the scope of visibility of the using code.”

Back to my bump from 0.9.33.2 to the HEAD of the 0.9.33 branch. This bump unexpectedly exposed bugs #510766 and #510770. Here we find that =media-libs/nas-1.9.4 and =app-text/texlive-core-2012-r1, both of which build just fine against 0.9.33.2, fail against HEAD 0.9.33 because of a name collision with abs(). Unlike the case with cdrtools, where the blame is squarely on uClibc, I think this is a case of enough blame to go around. Both of those packages define abs() as a macro even though it is supposed to be a function prototyped in stdlib.h, as per POSIX.1-2001 [7]. At least nas tries to check if abs() has been already defined as a macro, but its still not enough of a check to avoid the name collision. Unfortunately, given its archaic imake system, its not as easy as just adding AC_CHECK_FUNCS([abs]) to configure.ac. texlive-core at least uses GNU autotools, but its collection of utilities define abs() in several different places making a fix messy. On the other hand, why do we suddenly have stdlib.h being pulled in after those macros with HEAD 0.9.33 whereas we didn’t with release 0.9.33.2? It turns out to be uClibc’s tiny commit 2e2dc998 which I quote here:

	sched.h: include stdlib.h for malloc/free
	Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>

	diff --git a/libc/sysdeps/linux/common/bits/sched.h b/libc/sysdeps/linux/common/bits/sched.h
	index 7d6273f..878550d 100644
	--- a/libc/sysdeps/linux/common/bits/sched.h
	+++ b/libc/sysdeps/linux/common/bits/sched.h
	@@ -109,6 +109,7 @@ struct __sched_param
	 /* Size definition for CPU sets.  */
	 # define __CPU_SETSIZE	1024
	 # define __NCPUBITS	(8 * sizeof (__cpu_mask))
	+# include <stdlib.h>
	 
	 /* Type for array elements in 'cpu_set_t'.  */
	 typedef unsigned long int __cpu_mask;

Both packages pull in stdio.h after their macro definition of abs(). But now stdio.h, which pulls in bits/sched.h, further pulls in stdlib.h with the function prototype of abs() and … BOOM! … we get

/usr/include/stdlib.h:713:12: error: expected identifier or '(' before 'int'
/usr/include/stdlib.h:713:12: error: expected ')' before '>' token

Untangling the implementation details is a going to be a thorny problem. And, given uClibc’s faltering release schedule schedule, things are probably not going to get better soon. I have looked at the issue a bit, but not enough to start unraveling it. Its easier just to apply hacky patches to the odd package here and there than to rethink uClibc’s internal implementations. If we are going to start rethinking implementation, the musl [8] is much more exciting. uClibc is used in lots of embedded systems and the header issue is not going to be a show stopper for it or for Liblue, but it does make alternatives look like musl more attractive.

References:

[1] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue

[2] http://www.uclibc.org

[3] See Petazzoni’s email to the uClibc community.

[4] I wrote a little python script to generate these stacks since creating them manually . You can download it from my dev space: header-stack.py. Note that the stacking is influenced by #ifdef’s throughout, eg #ifdef __USE_GNU, which the script ignores, but it does give a good starting place for how the stacking goes.

[5] As of glibc 2.17, on mips, asm/unistd.h defines the various __NR_* values in a flat file with three #ifdefs sections for _MIPS_SIM_ABI32, _MIPS_SIM_ABI64 and _MIPS_SIM_NABI32, respectively ABI=o32, n64 and n32. Using my script from [4], the stacking looks as follows:

    sys/syscall.h
        asm/unistd.h
            asm/sgidefs.h
        bits/syscall.h
            sgidefs.h

In contrast, on amd64, each ABI is broken out further into their own file, with asm/unistd_32.h, asm/unistd_x32.h or asm/unistd_64.h included into asm/unistd.h for __i386__, __ILP32__, or __ILP64__ respectively. Here the stacking is

    sys/syscall.h
        asm/unistd.h
            asm/unistd_32.h
            asm/unistd_x32.h
            asm/unistd_64.h
        bits/syscall.h

Remember, on both architectures, sys/syscall.h are identical, and that is the file you should include in your c programs, not any of the asm/* which often carry warnings not to include them directly.

[6] man 2 clone

[7] man 3 abs

[8] http://www.musl-libc.org/

Tor-ramdisk: a tiny embedded image to host a tor relay

I hate being watched as much as the next person. Even the NSA loves its privacy otherwise it would be a transparent organization. What’s frightening and exciting about the technology we’re building today is that we are poised on a pivot point between extremes: deep invasion of our privacy and wide scale efforts to protect it. For those of you who don’t know the Tor Project [1] you really should look into it. Encrypted communication hides what you are saying from third party eavesdropping, but it does not hide who’s doing the talking, ie. it cannot hide the identity of one of the parties and so does not preserve your anonymity. If you decide to aim your browser at https://www.google.com/ then you can remain fairly certain that no one else is watching what you are googling for: you know, and google knows. But unfortunately, so does anyone google decides to tell! Given some of the exceptionally coercive methods governments use to make their demands [3], you might as well just announce your browsing habits publicly and be done with it.

Here’s where tor steps in. It doesn’t just encrypt your traffic, but also bounces it around the world via tor relays in such a way that even the nodes themselves can’t expose the origin of the traffic. Thus, tor provides its users with pretty good anonymity [4]. Now when google looks at its logs, it won’t see your ip address, but the ip address of one of the tor exit nodes. These are themselves publicly known [5], but the original ip from where the traffic is coming remains hidden. I’ve been using tor since about 2005. In July 2007, a tor operator in Germany [6] was arrested. Luckily his computers were not confiscated, but they could have been. The police wouldn’t have gotten much off of them, but there would have been the private keys and some other “evidence.” Running tor or any system of anonymity is not illegal, and it should never be illegal as it is in some countries, but today the line between what is legal and what powers governments will abuse has been blurred if not erased entirely. 2007 was also about the time the cloud computing was catching on, so I got the idea of creating a micro Linux distribution whose only purpose was to house a tor relay in an environment that maximizes security and privacy. The image boots from an ISO into ram, any keys or configs are scp-ed in, and upon power down … poof! … nothing to see here, move along. This was also about the time that I was getting involved with hardened Gentoo development and I met up with Magnus Granberg (zorry) who was working on migrating toolchain hardening from gcc-3 to gcc-4. I was teaching a course on embedded Linux, primarily building systems with uClibc and buildroot, and so tor-ramdisk was born [7]. I originally targeted only i686, but later added amd64 and mips32r2 for router boards like the Mikrotik RB450G.

So what goes into tor-ramdisk? You can read the build scripts [8] for details, but basically the kernel is Gentoo’s hardened-sources kernel with PaX and Grsec turned on full force. A minimal userland is provided by a crippled busybox with most of its applets turned off. You need openssl for tor itself as well as openssh which provides for scp-ing keys and config files in and out of the image. Tor critically depends on the time being right, so I used openntpd for synchronization. You also need a good source of entropy for key generation and encryption, which is always a problem on embedded systems [9], so haveged is used shore up the kernel’s /dev/random. Finally we need uClibc and libevent. I cheat a little and build on uClibc virtual machines, so I can just copy over the needed libraries rather than cross compiling them. Everything is built using Gentoo’s hardened toolchains and so all the ELFs binaries have SSP, PIE + ASLR, relro, bind_now and other security goodies [10]. For i686 and amd64, kernel and userland are bundled up in a bootable ISO image, while for mips I embed the initramfs in the bootlable Linux image which can be delivered via tftp. When the system boots, the user is presented with a menu driven system on tty1 to configure and start tor. The menu is a shell script spawned by init as “tty1::respawn:/bin/setup”. On tty2, tty3 amd tty3 we have, respectively, the output of nmeter (ascii based system usage meter provided by busybox), ntpd and haveged.

I don’t know why I haven’t blogged about tor-ramdisk before on Planet Gentoo, but it is a Gentoo “derivative.” It is also popular project, at least according to freecode.com. The i686 image is the most popular, followed by the amd64, with several hundred downloads per release. I’ve stopped producing the mips32r2 image because no one was using it, even though it was the most fun to build! There have been suggestions for new features but I’ve tended to resist because I like the ~6 MB image. If you can think of something I can add without growing that image much, send patches my way!

 

 

References:

[1] https://www.torproject.org/. The Gentoo package is net-misc/tor.

[2] “fairly certain” but not 100% certain as we recently learned from CVE-2014-0160, aka the “heartbleed” bug. See https://en.wikipedia.org/wiki/Heartbleed

[3] You can read the story of lavabit’s owner as told by him at http://www.theguardian.com/commentisfree/2014/may/20/why-did-lavabit-shut-down-snowden-email

[4] There are attacks against tor so it isn’t perfect, but it is by far the best anonymity software out there. See the wiki page on tor for its weaknesses: http://en.wikipedia.org/wiki/Tor_(anonymity_network)

[5] There are various lists of exit and relay nodes. For a live list, check out http://torstatus.blutmagie.de/

[6] http://www.cnet.com/news/tor-anonymity-server-admin-arrested/

[7] The main development site is http://opensource.dyc.edu/tor-ramdisk. I announce releases at https://freecode.com/projects/tor-ramdisk.

[8] https://gitweb.torproject.org/tor-ramdisk.git

[9] See Josh Ayers’ email to the tor-ramdisk list http://opensource.dyc.edu/pipermail/tor-ramdisk/2014-February/000119.html.

[10] You can read a little bit about these hardening techniques from the “Project Description” of a related project, Lilblue Linux: https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue

 

Lilblue Linux: release 20140218

I just pushed out a new release of Lilblue Linux 20140218 [1] which you can download from any Gentoo mirror [2].  For those of you who don’t know, Lilblue Linux is a security-enhanced fully featured XFCE4 desktop system for amd64.  It is built with Gentoo’s hardened toolchain [3] and uses Gentoo’s hardened-sources for the kernel which include the Grsec/PaX patches [4] for added security.  Lilblue Linux really is Gentoo, so the name is a bit pretentious, but there is one important and interesting twist: it is built using uClibc [5] as its standard C library rather than glibc, giving it some advantages of an embedded system, such as speed.

Release 20140218 is primarily a maintenance release in which I updated all the packages so as to sync up with maintream Gentoo’s stable amd64 set.  I didn’t touch the toolchain since there was no pressing need, but I did update the kernel to hardened-sources-3.12.6.  There were no known major security issue nor major bugs in the previous release.  But, there was a lot of package flux, with lots of fixes that resolved some annoying issues which plagued the earlier release.  One such annoyance was SMPlayer that used to open up a second window to play a video rather than rendering it in the main window.

If you are already running Lilblue, you can probably just do a `emerge –sync; layman -S; emerge -uvND world` and get caught up [6], but if you are starting a fresh system, the newer image cleans out those annoyances, so you want to start there.  One of the reasons I push out new images every few months is that there are always glitches when updating.  This is true of any Gentoo system but all the moreso of Lilblue because most software is developed under the assumption that we are building against glibc.  These assumptions (GNU-isms) manifest themselves in varioius ways: 1) assumptions about the availability of functions which are GNU extensions, such as secure_getenv() in systemd’s code base which eudev removes [7],  2) assumptions about header stacking, eg. using variadic functions without including stdarg.h (You can sometimes get away with this on a glibc system because it sneaks in via some other included header, but not in uClibc), [8] and 3) missing LDFLAGS like, -liconv -lintl or -largp, which are needed to find these breakout libraries [9].  There are, however, some very deep issue which require serious investigation, such as the removal of poll_waiting in glib (versions above 2.30.3) which lead to a dead lock for all applications linking against it.  It turned out that the issue there was in uClibc’s implementation of eventfd() [10].  Another interesting bug in uClibc-0.9.33.2 was the non-atomic implementation of pread() and pwrite() in terms of open() and lseek() [11].  This caused a race in git-1.8.x which does a multithreaded unpacking of the deltas and requires atomic pread/pwrite.  Mike Frysinger (vapier) had already worked out the implementation in terms of SYS_pread64/pwrite64 but these had not yet been backported.  The latest adventure was on arm architecture (yes I’m thinking of porting Lilblue to arm) where the syscall for pread/pwrite was being done using _syscall5() rather than _syscall6() and not properly aligning the 64-bit value on even register pairs.  This again broke pread/pwrite and git, but only on arm arch! [12]  Mike again had the fix and backported it.

Lilblue is built form a stage3-amd64-uclibc-hardened tarball that can be found on any gentoo mirror under /experimental/uclibc along side the Lilblue image itself [2].  I keep the build scripts on Gentoo’s releng (release engineering) git repo [13] and I run them occassionally to see if any major issues are creeping in as mainstream Gentoo evolves.  If everything goes well, then I don’t push out another release to avoid taxing the mirrors.  But when things get complicated, or a large number of packages need updating, I get the feeling I’d better push out another release.  I hope one day to have a binpkg system going where you can donwload a ~200MB seed image and then install from a binhost but this is more involved than I first suspected.

So give it a try in a virtual machine if you like.  It runs out-of-the-box on VirtualBox.  Installation instructions are on the home page [1].  Or run it as you main desktop as I do on one of my boxes at home!

References:

[1] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue

[2] The image is named desktop-amd64-uclibc-hardened-[release].tar.bz2 and can be found at http://distfiles.gentoo.org/experimental/amd64/uclibc/

[3] https://wiki.gentoo.org/wiki/Hardened/Toolchain

[4] http://grsecurity.net/

[5] http://uclibc.org/

[6] While I’ve tried to get most of the fixes either into the main Gentoo tree, or upstream, some patches still remain and so I maintain a repository for them: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=shortlog;h=refs/heads/uclibc

[7] See man 3 getenv.  While getenv conforms to SVr4, POSIX.1-2001, 4.3BSD, C89 and C99, secure_getenv() is a GNU extension.

[8] The header stacking problem works both ways.  In https://bugs.gentoo.org/show_bug.cgi?id=497200, sys-apps/kbd failed to build on uClibc because of a missing stdarg.h when trying to prototype functions with variadic parameters.  Contrast this to https://bugs.gentoo.org/show_bug.cgi?id=486782, where app-cdr/cdrtools fails to build because including stdio.h indirectly includes bits/sched.h which defines clone() (as in man 2 clone).  But this clashes with a definition of clone() in cdrtools’ readcd.c.  Upstream felt that this was a poor implementation on the part of uClibc and the stacking problem there should be fixed.  I can’t disagree, but it is a thorny issue!

BTW, for those interested, you can get a little python script I wrote to analyse header stacking from my dev space: http://dev.gentoo.org/~blueness/misc/header-stack.py

[9] In this way Lilblue is similar to Gentoo on FreeBSD.  Rather than using uClibc’s iconv which has issues, Lilblue pulls in dev-libs/libiconv. The additional LDFLAGS are added on a per package basis using /etc/portage/package.env.

[10] https://bugzilla.gnome.org/show_bug.cgi?id=691168

[11] https://bugs.gentoo.org/show_bug.cgi?id=500382

[12] https://bugs.gentoo.org/show_bug.cgi?id=500382

[13] http://git.overlays.gentoo.org/gitweb/?p=proj/releng.git;a=tree;f=tools-uclibc/desktop

The Gentoo Profile Stacking Problem

I thought I’d write a bit about a long standing problem that the hardened team has been facing with Gentoo’s profile system.  Ever since I joined the team around 2009, we’ve had to deal with the “profile stacking problem”.  Most users and devs just merily go along using `eselect profile` to pick the profile closest to the type of system they want and then tweak the various files under /etc/portage, adding a USE flag here, and keywording or unmasking a package there, until they get the “perfect” system.  What I want to do in this post is expose just what goes into designing the profiles that we publicly export.

I was inpsired to write this because of bug #492312.  There we want to re-introduce the hardened desktop profile for amd64, x86 and arm.  I say “re-introduce” because we had to remove it and its sibling profiles /server and /developer.  So what was going on there?

To start, let me give you a nice pice of python code:

import portage
for p in portage.settings.profiles:
    print("%s" % p)

What this little snippet does is print out the profile stack as the directories inherited from one another via the parent file.  Its a useful tool because profile stacking can get very hard to follow.  When the parent file has something simple like just “..” then the inheritance is easy and that directory just inherits all the package.mask, package.unmask etc of the parent directory, as you would expect from the shell meaning of “..”  But what happens when the parent file looks like this:

../../../base
../../../default/linux
../../../arch/amd64
..

as it does for hardened/linux/amd64?  Well then we get some interesting behavior. The first line says, inherit from base. Easy enough since base inherits from nothing else you get all of base’s settings. The second line says inherit from default/linux, which aslo doesn’t inherit from anything.  These setting just add and override those from base.  Easy enough. Ah! But now we come to arch/amd64, where the parent file says

../base
../../features/multilib/lib32

and the inheritance continues to those directories in order. Finally “..” in hardened/linux/amd64 means inherit hardened/linux which sets most of hardened’s needs via make.defaults, package.mask, use.mask and friends. But alas, hardened/linux has its own parent file which reads

../../releases/13.0

and the trip down the rabbit hole continues!  If you are starting to get a little lost, don’t feel bad. It is hard to wrap your brain around stacking, which is why that little script above is so useful.  But the difficulty in following profiles stacking is not the real problem. If you’re like me, you’re too proud to admit you can’t get your head around any complexity ;)   No, the real problem is that you can’t control the stacking order.

To demonstrate, let me refer again to bug #492312.  There we’d like to have a profile which reads

hardened/linux/amd64/desktop

Okay, but what should we put for its parent file?  We’ll need “..” in there to inherit all of hardened/amd64 settings, but we also would like targets/desktop.  So let’s try a parent file that looks like this

..
../../../../targets/desktop

In that case, our little script tells us that our profile stack as follows:

/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/targets/desktop
/usr/portage/profiles/hardened/linux/amd64/destkop

And if you switch the order of .. and targets/desktop, you get

/usr/portage/profiles/targets/desktop
/usr/portage/profiles/base
/usr/portage/profiles/default/linux
/usr/portage/profiles/arch/base
/usr/portage/profiles/features/multilib
/usr/portage/profiles/features/multilib/lib32
/usr/portage/profiles/arch/amd64
/usr/portage/profiles/releases
/usr/portage/profiles/eapi-5-files
/usr/portage/profiles/releases/13.0
/usr/portage/profiles/hardened/linux
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/hardened/linux/amd64/destkop

The problem with the first ordering is that targets/desktop overrides hardened/linux/amd64 and so any USE flags that we may turn off or on in hardened can get reverse in desktop.  The example here is the jit flag — Just-In-Time compilers write executable code on the fly in areas of memory which must be both writeable and executable.  But a PaX hardened kernel will not allow WX mmap-ings because this is an obvious exploit vector.  Rather, in hardened, we prefer slower and safer methods for compiling/interpreting code on the fly than JIT.

Okay, so what about the second ordering.  It may look strange to have target/desktop before base, but that in itself is not an issue.  Here we have the same problem as above but in an even more subtle way!  (See my comment #9 of bug #492312.)  Consider a fairly important package like dev-libs/libxml2.  In the current state of the tree, `emerge -vp dev-libs/libxml2` would give

 [ebuild   R    ] dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 python* ...

for both stacking choices. But if at some point in the future, someone added the following to profiles/default/linux/package.use

#Python support causes problems on xyz
#Don't pull it in if we don't neeed it
dev-libs/libxml2  -python

The vanilla profile default/linux/amd64/13.0/desktop and our hardened profile with targets/desktop last would not change since they have “dev-libs/libxml2 python” in package.use near the bottom of the stack, but our proposed hardened profile with targets/desktop on top would give

 dev-libs/libxml2-2.9.1-r1:2  USE="ipv6 readline ... -python ...

So, both choices for orderings of “..” and “targets/desktop” in our parent file for hardened/linux/amd64/desktop lead to situations where we can’t control what packages get what use flags. What we would like is a stacking that looks something like this

...
/usr/portage/profiles/targets/desktop
/usr/portage/profiles/hardened/linux/amd64
/usr/portage/profiles/hardened/linux/amd64/destkop

but how do we get that with our current inheritance mechanism? One idea that Magnus (Zorry) had was to gutt out this portion of portage and replace the parsing of the parent file with something along the lines of openrc’s depend() { … } clause. Then we just locally say what has to come before/after what and we let the algorithm figure it out. It sounds like an interesting problem if there were two of me and if there were a good chance that it would actually get implemented. In the mean time, we limp along with what we have and do ad hoc fixes as changes in one part of the profiles means we have to adjust other things. Since we are all responsible for different areas of the tree’s profiles, inevitably we cause one another breakage even with the best of intentions. For example, a few days ago, Mike (vapier) removed a masking on the uclibc USE flag in the base profile.  Doing so makes perfect sense. He didn’t tell me, and why should he have to?, but this lead to a small breakage in hardened/linux/uclibc/amd64 and friends where I had to relax that masking.  I only discovered this upon a catalyst run which is a bit annoying.

Lilblue: a security-enhanced, fully featured XFCE4 desktop for amd64, built on uClibc

Hi everyone,

I’d like to announce a new (fun?) initiative of the hardened uClibc subproject: a security enhanced, fully featured XFCE4 desktop for amd64, built on uClibc, codenamed “Lilblue”, after the little blue penguin of New Zealand [1], a smaller cousin of the Gentoo.

The hardened uClibc subproject aims at producing hardened stage3s for amd64, mips (isa=mips32r2/mipsel3, abi=o32), armv7a (softfloat) and i686 [2].  Recent improvements in uClibc and bugfixes in various Gentoo packages, both downstream and upstream, now make it possible to build an entire desktop system replacing glibc with uClibc.  So, in addition to the stage3s, we are now releasing a fully featured XFCE4 desktop for arch=amd64.  It does *not* depend on busybox to provide its core utilities like most uClibc systems, but coreutils, util-linux and all the usual system packages you find on a generic Gentoo system.  The tarball bundles about 800 packages including ephiphany, claws, hexchat, abiword, gqview, transmission, vinagre, etc.  We have plans to provide binpkgs for up to 7000 packages in all.  The hardening includes all of the usual toolchain and kernel hardening you get in regular hardened glibc-based Gentoo.

The project has been in development for a year but should be considered experimental.  A user base of … uhm … one … does not really qualify it to be labeled as “safe for production” [3]. However, I have had no issues with it (minor bugs of course) and I use it on a daily basis.  For the average user, the main advantage is speed and the system does feel “snappy”.  For developers, its fun to dig into bugs which revolve around what functions are provided by your standard C lib: is this POSIX or a GNU-ism?  should I fix the package or add a new function to uClibc?  what is the best way to implement this fix so it ports across different *libcs?  what do I do about this package whose build system is braindead and doesn’t understand libdir?  If you have too much time on your hands and you’re into that kind of “fun” we have a project for you!  On a serious note, the main reason for this initiative is to explore and expand the usefulness of an alternative standard C library.

The home page is at [4] and a freecode.com announcement at [5].  It can be downloaded from any gentoo mirror [6] at [mirror]/gentoo/experimental/amd64/uclibc/desktop-amd64-uclibc-hardened-[date].tar.bz2. The date of the first release is 20130531.

Ref.
[1] https://en.wikipedia.org/wiki/Little_Penguin
[2] http://www.gentoo.org/proj/en/hardened/uclibc/index.xml
[3] This is not entirely true.  I would like to thank my students for testing, especially Devan Franchini <twitch153@hotmail.com>.
[4] http://www.gentoo.org/proj/en/hardened/uclibc/lilblue.xml
[5] https://freecode.com/projects/lilblue-linux
[6] http://www.gentoo.org/main/en/mirrors2.xml

Some love for mips64el: updates for an XFCE4 Gentoo Desktop on the Lemote Yeeloong

Hi everyone!

Back in September of last year, I pushed out two images for xfce4-based desktop systems for the Yeeloong netbook.  These mips64el machines are manufactured by Lemote in China, and distributed in the US by “Freedom Included“.  Over the summer, I spent time fixing the bugs I hit as I ported over goodies for the desktop: Abiword for word prcessing, GQview for images, Audacity for audio, Claws for email and Dillo for browsing.  Most of these bugs were in build systems that were not multilib aware.  I was building for three ABI’s, o32, n32 and n64 with libraries living in /lib, /lib32 and /lib64, respectively, and similarly under /usr.  Since some build systems would blindly install into /lib and since the default ABI is n32, this caused some issues!

As mentioned, there are two images, one for binaries built with a hardened toolchain (SSP, PIE, FORTIFY_SOURCES=2, bind_now and relro) and the other for binaries built with a vanilla toolchain.  Remarkably, hardening led to no appreciable bugs over the vanilla, but there is about a 5% performance hit when running.  This is most noticeable when compiling which is already slow on these 800-900 MHz machines.  In fact, this is why I decided to distribute entire desktops and not just stage3′s.  It would take a user about two days of no stop building to get to the desktop from a stage3.  Given the occasional failure along the way, this is a recipe for frustration for anyone who wants Gentoo on their Yeeloong.  Hopefully the end user won’t be too unhappy with my choice of software.  In the future, I hope to have a better brower than Dillo and try go get video working.  I’ve had some success with the latter but not enough to push something out.

Anyhow, four months after my initial images and I thought its time to update.  Except for updating the packages, I didn’t change the selection.  My update to the kernel, however, was important: we can now do the usual partitioning suggested in the Gentoo Handbook: boot on sda1 with ext2, swap on sda2 and root on sda3 with ext4.  My first images had to combine boot and root into one ext3 partition because of certain limitations.

I hope if you have the hardware you’ll give the images a test drive and let me know!  They’re available on any Gentoo mirror under <mirror>/experimental/mips/desktop-loongson2f.  The latest version is 20130124 and the instructions for installation are found here.

 

A Gentoo Desktop for the Lemote Yeeloong, a little endian mips64 netbook

Hi everyone,

I’d like to announce a new initiative within the mips arch team. We are now supporting an xfce4-based desktop system for the Lemote Yeeloong netbook.  The images can be found on any gentoo mirrors, under gentoo/experimental/mips/desktop-loongson2f.  The installation instructions can be found here.  The yeeloong netbook is particularly interesting because it only uses “free” hardware, ie. hardware which doesn’t require any proprietary code.  It is manufactured by Lemote in China, and distributed and promoted in the US by “Freedom Included“.  It is how Richard Stallman does his computing.

I’m blogging because I thought it was important for Planet Gentoo to know that mips devices are currently being manufactured and used in netbooks as well as embedded systems.  The gentoo mips team has risen to the challenge of targetting these systems and maintaining natively compiled stage4′s for them.  Why stage4′s?  And why a full desktop for the yeeloong?  These processors are slow, so the time from a stage3 to a desktop is about three days for the yeeloong.  Also, the yeeloong sports a little endian mips64 processor, the loongson2f, and we support three ABIs: o32, n32 and n64, with n32 being the preferred.  This significantly increases the time to build glibc and other core packages.  I provide two images, a vanilla one and a hardened one.  The latter adds full hardening (pie, ssp, _FORTIFY_SOURCES=2, bind now, relro) to the toolchain and userland binaries as we do for amd64 and i686 in hardened gentoo.  I have not ported over the hardened kernel, however.

I allude above to “other” targetted devices.  I am also maintaining some mips uclibc systems (both hardened and vanilla) which are on the gentoo mirrors under experimental/mips/uclibc.  But I will speak more of these later as part of an initiative to maintain hardened uclibc systems on “alternative” architectures such as arm, mips, ppc as well as amd64 and i686.

You can read the full installation instructions, but here’s a quick summary, since it doesn’t follow the usual Gentoo method of starting from a stage3:

  • Prepare either a pen drive or a tftp server with a rescue image: netboot-yeeloong.img
  • Turn on the yeeloong and hit the Del key multiple times until you get the firmware promt: PMON>
  • If netbooting, add an IP address and point to the netboot-yeeloong.img.  If using a pen drive then point to thei image on the drive and boot into the rescue environment.
  • Partition and format the drive.
  • Download the desktop image from a mirror via http or ftp.  Its about 350 MB in size.
  • Unpack the image.  It contains not only the userland, but also a kernel.
  • Reboot to the PMON> prompt.  Aim to the kernel on the drive.  PMON will remember your choice and you will not have to repeat this step.

Once installed, you will log in as an ordinary user with sudo with username and password = “gentoo”.  The root password is also set to “root”.  It is an ordinary Gentoo system, so edit your make.conf, emerge –sync and add whatever packages you like!  File bugs to: blueness@gentoo.org with a CC to mips@gentoo.org.

If you have a Yeeloong or go out and buy one, consider trying out this image.