Tuesday, November 18, 2008

ARM and MID ...

So for those of you playing along at home, we have a newly available ARM port, which has just reached the point of being able to debootstrap itself with a buildd varient (i.e., install build-essential and a few other packages). Now the fun begins with porting stuff.

First up is mono. Mono has a port to ARM and ARMel already, however, this code obviously hasn't been compiled in sometime, as it FTBFS due to glibc 2.8+svn. *grumble*. Oh well, easy fix, and one that will help clear a bunch of other dep-waits and get us that much closer to a usable port.

Monday, November 10, 2008

WiiBuntu (Part 1), Ubuntu Ports MID, and lpia

So here I am, with a wonderful Wii, complete with Twilight Hack and Homebrew Menu installed, wondering if I could do something crazy like run Ubuntu on it. After some trial and error, it appears possible to do a debootstrap of an Ubuntu PowerPC installation and have it work!.

So now that I have a Wii with Ubuntu installed, what am I going to do with it, that is the question I am now pondering. The answer seems obvious, put Ubuntu MID on the sucker, install XWii (Wiimote Pointer Driver), and the WiiX display driver, and turn it into a very pretty multitouch system. Yay :-) So it should just be a matter of 'aptitude install ubuntu-mid'

Sadly, its not quite that easy. Ubuntu-MID currently is only installable on lpia. I can hear the questions now, WTF is lpia. To answer that question, lpia is the Low-Power Intel Architecture, also known as the Intel Atom processor family. For those of you familar with Atom, you might be double-taking, saying Atom is an x86 based processor. Again, your right, lpia is x86 based (you can run it on normal PCs), its essentially i386 Ubuntu with a few optimizations.

The problem breaks down to the way some of the MID's compontents were packaged. The main problem comes in the form that the rules file, instead of properly splitting the packages out, the rules file checks for the lpia architecture, and then changes the configure options to build hildon support (hildon is the nifty library from Nokia that makes MID work). To fix MID on ports (and x86/amd64), each package with this lpia detector switch must be found, and then properly split. Sounds easily enough, right?

Wrong. Most of the packages (such as evince) are CDBS packages. For anyone who knows anything about CDBS, you know it was never meant to split packages :-/. This *will* be fun :-/.

As an added note, OpenOffice.org is broken on PowerPC, double fun, since compiling it will likely take longer than releasing Jaunty will take :-).

Wednesday, November 5, 2008

More notes from the PIE party (Ubuntu bootstrapping howto) ...

So after getting stuck and putting this work aside, I decided to take a second stab at it after meeting up with another Ubuntu developer in real life, and doing additional research. Using the experimental gcc-4.3 branch of Gentoo Hardened as a base, I'm now making extremely good progress bootstrapping amd64-pie, and the results look promising thus far.

For those of us curious, bootstrapping the archive is a straightforward if time intensive project. Essentially the process requires three individual bootstraps, an inital one that you use to build debian package, a chroot from those package, and a final chroot that is the end result.

Right now I'm working on the first part of this bootstrap, which is from a Linux host (without Debian) to generating the inital bootstrap packages. It requires compiling each build-dep from source with the proper configuration arguements, then building the packages with dpkg-buildpackage -d, and installing it, until you have build the entire base system.

From there, you take the debs, place them in a repo, and debootstrap, and then rebuild again, which produces the final result debs. It's straightforward and fasicating work (if a little tedious)
Michael

Friday, September 12, 2008

Well, I'm a (K)ubuntu member now :-)

I figure I should break in my first post, that I'm now a Kubuntu member, and through that, also an Ubuntu member, and thus can post to Ubuntu Planet now :-).

For all of those out there who helped make this possible, thank you. Next stop, MOTU.

Saturday, September 6, 2008

PIE GCC stage two bootstrapping notes ...

I figure I haven't explained what I'm doing at this point. I'm currently compiling GCC with a patch to have both it be PIC/PIE, and generate PIE binaries, a rather fun task requiring multiple compiler bootstraps, but should allow me to properly test the ability to compile the system PIE enabled. I suspect I can convince kees to see if all this bootstrapping isn't necessary and can generate comparable results to my test builds.

Roughly speaking, the sequence of events that I'm following goes something like this.

1. Build a compiler that generates PIC code by default from a non-PIC system (embyro compiler)
2. Use the PIC compiler to compile glibc, gcc/binutils depends (zlib, gmp, mpfr)
3. Build a compiler with the previous compiler to build a compiler that can generate PIE binaries. This will be used to build the equivelent of a Gentoo stage1 system. <- We are here
4. Build a temporary base system.
5. Using the PIE compiler, rebuild the base system with the proper paths (butterfly compiler).
6. Build Ubuntu specific tools (dpkg, apt, etc.)
7. Build Ubuntu base system with GCC patchs, generating debs
8. Using those debs, rebuild the base system again

Thursday, September 4, 2008

A Look At the Specs ...

(warning: GCC internals ahead. For ye who wishes to stay sane, stay away, stay very far away)

Part of the major changes hardy->intrepid was the inclusion of hardening configurations in GCC. This was originally handled via a script called hardening-wrapper, which using the alternates system to replace GCC with a wrapper script, which passed a variety of options (see the wiki for the full list) and was controllable via environmental variables.

After intrepid, all of these options (aside from PIE) was moved into GCC specifically via the spec mechanism. For those unaware, GCC (and binutils) is essentially several smaller programs, such as the C preprocessor, cc1, assembler, linker, etc. The specs strings is essentially a rules system that controls the arguements to each of these mini programs. Lets take a more specific look at these strings. You can view the gcc specs can be viewed with gcc -dumpspecs

(Ubuntu GCC 4.3.1 Intrepid Alpha, for beverity sake, here's just a small section)

*cpp_unique_options:
%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}}}}}} %{remap} %{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{!D_FORTIFY_SOURCE:%{!D_FORTIFY_SOURCE=*:%{!U_FORTIFY_SOURCE:-D_FORTIFY_SOURCE=2}}} %{E|M|MM:%W{o*}}

While this appears to a load of messy strings, it defines the command line arguements GCC accepts, and what it does. The last section for instance was added in Ubuntu to add the FORTIFY_SOURCE defines, as well as include the offswitch for it. Adding the PIE switch would be done under the cc1 section which is what handles the PIE processing, in a similar mechanism. This way, we can apply PIE to every package, and then manually add -fno-PIE on any package that requires it to be disabled.

This is a quick overview of specs, and I hope you learned something by reading it, and understanding how this will be done.

More progress ...

After further research, I attempted to use Linux from Scratch as a base for my attempts to compile the base system. This lead me to High Security LFS, which is the base chroot built with PIE, which is what I want. I can't find anyone who's done HLFS on amd64, so it will be rather interesting to see how well this works.

GCC sucks.

On my quest to build the archive with PIE, I discovered the first major headache, is that there is a rather interesting circular dependency in the compiler toolchain.

Roughly speaking, libgcc is linked to to glibc, which is linked to libgmp, which the compiler is dependent on, making it not possible to directly build the compiler built with PIE (and as an additional fun fact, the three stage bootstrap makes hardened wrapper non-effective. CFLAGS can be passed to the second and third stage bootstrap so this isn't a huge limitation, but it will regular beating gcc's debain/rules2 into passing the flags correctly. I'm now at the point roughly where I can try to build perl from source, then dpkg and aptitude.

The -fPIE is a lie. Part 1

For those playing along at home, I've been working with Kees Cook (from Canonical), on investigating the possibility of generating Position Independent Executables for the AMD64 architecture which would greatly help increase security for Ubuntu.

Position independent code roughly means that there are no hard coded addresses in the binary, making a return-to-libc attack near impossible when combined with address space randomization, a technique that causes binaries and libraries to be loaded in random locations in memory. The upshot is that on 64-bit systems, even if a buffer overflow or other programming bug makes it possible to override the stack, a return-to-libc attack can't be done due to the randomized address space. Stack smashs and buffer overflows are of course properly avoided alrady in Ubuntu due to the stack protector.

Now some people may be wondering why we're not doing this for x86. The reason is that there is a price to be paid by PIE code and that is that a register must be used to handle the locations and relative jumps in the executable. x86 has very few general purpose registers that could be used for this, and thus has a rather large cost. Architectures such as ia64, amd64, powerpc, and sparc have more than enough general registers to make the change fessiable without aversily affecting performance.

Currently, I'm working on building a base chroot completely PIE enabled, and then rebootstrapping Ubuntu from scratch, a laborous, but hopefully successful attempt at rebuilding the archive with PIE.

Well, here I am. Blogging.

I was rather shocked to discover I had a blog on blogger (empty, of course). I figured with my recent work with Ubuntu and Debian, it might be worth having a blog so people can follow a long with home. Well, I guess this is it for now.