coreboot projects for Google Summer of Code 2008

The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:

  • All Virtual All The Time (AVATT):

    This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.

  • SCSI booting in coreboot:

    Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.

This should make for an interesting summer with nice improvements for coreboot.

Resizing a dm-crypt / LVM / ext3 partition

I've bought a new hard drive for my laptop recently, because I finally got fed up with my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk.

As I didn't want to re-install from scratch I started with dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise.

The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course).

0. Perform backups, boot from a live CD

Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!

First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance.

1. Resize partition

This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space.

Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted!

2. Resize dm-crypt volume

Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using cryptsetup now:

  $ cryptsetup luksOpen /dev/hda3 foo

3. Resize LVM physical volume

Next step is to tell LVM about the new space. We first resize the LVM physical volume on the foo "partition" to use up all newly-available space.

  $ pvresize /dev/mapper/foo

4. Resize LVM logical volume

Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:

  $ lvresize -L +74 GB /dev/vg-whole/lv-home

5. Resize ext3 filesystem

The final step is to resize the ext3 filesystem on the lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:

  $ fsck -n /dev/vg-whole/lv-home
  $ ext2resize /dev/vg-whole/lv-home
  error: Invalid argument: seeking to 3258921205760

This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:

  $ fsck -n /dev/vg-whole/lv-home
  $ resize2fs /dev/vg-whole/lv-home

That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!

Lest We Remember: Cold Boot Attacks on Encryption Keys

Just in case you haven't already read about this... Some researchers from Princeton have published a paper about methods which can be used to attack full-disk-encryption (FDE) schemes.

They have demonstrated that at least BitLocker (Windows Vista), FileVault (MacOS X) and dm-crypt (Linux) are vulnerable to this type of (partly hardware-based) attack scenarios. Quite likely lots of similar other solutions are vulnerable as well.

The main problem is that (contrary to popular belief) RAM does indeed retain its data for a non-trivial amount of time after power is cut (seconds, even minutes or hours if it's cooled down enough), so you can mount some new attacks such as:

  • Get physical access to laptop/computer, cut power to it (the hard way), reboot with a special live CD or USB thumb drive and some special software which dumps the RAM contents to an external disk (or sends it via network). As RAM contents are still there a few seconds after the power is cut, this works astonishingly well.
  • Get physical access to laptop/computer, open it, remove RAM DIMMs while the computer is running, insert them into your own prepared computer and read the RAM contents using some special software.

Yes, all attacks assume that the attacker has physical access to your PC/RAM, in which case you already have several other problems. Still, the new thing about this is that even full-disk-encryption doesn't help much in some cases. You probably shouldn't depend too much on it (but you shouldn't stop using disk encryption either, of course!).

Full paper: coldboot.pdf. There are also some demo videos and pictures.

More coverage at Boing Boing, Bruce Schneier's weblog, Freedom to Tinker, Slashdot, Heise (German), and many more...

Make sure to read the comments of the various articles for more scenarios and possible ideas for how to prevent such attacks. Some ideas include enabling the BIOS RAM checks (which might explicitly erase RAM contents on reboot; that doesn't help in all cases, though) or using coreboot (previously LinuxBIOS) to erase RAM contents at boot-up and/or shutdown.

It's a highly non-trivial issue, though, there's no easy and complete fix so far. The only sure way is to not have your laptop or PC stolen and to not give attackers physical access to your computers.

Recent LinuxBIOS progress

LinuxBIOS ROM Chip Logo

Since the "World's First Motherboard Using LinuxBIOS Released" hype at the beginning of this year (which was incorrect btw; it was not the first supported desktop board, there were many others before), LinuxBIOS hasn't been in the news very much. That doesn't mean that there was no progress, however. We've been working hard behind the scenes to improve the LinuxBIOS code, add support for new chipsets and boards, and advance the upcoming next-generation LinuxBIOSv3 version which will brings lots of great improvements in various areas.

Here's a random collection of stuff that happened in the last few months.

New chipsets:

  • AMD K8 / NVIDIA MCP55, contributed by Yinghai Lu of AMD
  • VIA VT82C686A/B southbridge, contributed by Corey Osgood
  • AMD Geode LX / CS5536, contributed by Marc Jones and Jordan Crouse of AMD
  • Intel 810 northbridge, contributed by Corey Osgood
  • AMD K8 / VIA K8T890 / VT8237R, contributed by Rudolf Marek / Corey Osgood
  • AMD K8 / SiS761GX / SiS966(L), contributed by Morgan Tsai of SiS

New mainboards:

  • Sun Ultra40, contributed by Ronald G. Minnich (LinuxBIOS project founder)
  • K9SD Master-S2R (MS-9185), contributed by Bingxun Shi of MSI
  • K9SD Master Series (MS-9282), contributed by Bingxun Shi of MSI
  • GIGABYTE GA-M57SLI-S4, contributed by Yinghai Lu of AMD
  • NVIDIA l1_2pvv, contributed by Yinghai Lu of AMD
  • Supermicro H8DMR, contributed by Yinghai Lu of AMD
  • Tyan S2912, contributed by Yinghai Lu of AMD
  • Tyan S1846, contributed by myself
  • AMD Norwich (AMD Geode LX reference platform), contributed by Marc Jones and Jordan Crouse of AMD
  • IGEL Winnet III thin client, contributed by myself
  • ASUS A8N-E, contributed by Phillip Degler
  • IEI JUKI-511P, contributed by Nikolay Petukhov
  • IEI ROCKY-512, contributed by Nikolay Petukhov
  • AMD DB800 (a.k.a. Salsa), contributed by Marc Jones and Jordan Crouse of AMD
  • ASUS MEW-VM, contributed by Corey Osgood
  • Artec Group DBE61, contributed by Marc Jones and Jordan Crouse of AMD
  • PC Engines ALIX.1C, contributed by Ronald G. Minnich
  • MSI MS-6178, contributed by myself
  • MSI MS-7260 (K9N Neo), contributed by myself
  • IGEL-316 thin client, contributed by Jürgen Beisert
  • AXUS TC320 thin client, contributed by Jürgen Beisert
  • GIGABYTE GA-2761GXDK (Churchill), contributed by Morgan Tsai of SiS
  • And a bunch of older Intel 440BX based boards, contributed by myself with some help by testers via IRC: ASUS P2B/P2B-F/P3B-F, A-Trend ATC-6220, AZZA PT-6IBD, Biostar M6TBA, Compaq Deskpro EN SFF P600, GIGABYTE GA-6BXC
  • ASUS A8V-E SE, contributed by Rudolf Marek

Note that not all of these may be 100% supported, some may still be work in progress with some TODO items left... Check the LinuxBIOS wiki or ask on the mailing list for details.

The future

Most work will probably go into LinuxBIOSv3 in the future, in order to make it suitable for productive use.
Of course, work on new chipsets and boards will continue, too. For example the VIA CN700 chipset (plus Jetway J7F2WE board using it) is being worked on right now, probably also several others I don't know about.

Call for board testers

If you're interesting in trying out LinuxBIOS, please check the list of supported motherboards. If your board is not listed there, but the chipset is already supported we can probably add support for your board relatively easy with some testing help from you.

Please contact us on IRC or preferrably on the mailing list if you want to help get your board supported!

An (incomplete) list of good candidate boards for future support is available in the wiki.


We're very grateful for the many contributors who have helped us with testing and fixing existing code, or who even contributed code for new chipsets and motherboards. Thanks a lot!

Many thanks especially to all hardware vendors who have been supporting us or even actively contributed by submitting code for their chipsets or boards (recently or in the past), including AMD, SiS, VIA, MSI, Tyan, Artec Group, and many others. Your efforts are very appreciated. Thanks!

Retiring the sparc32 Debian port... or not?

According to Jurij Smakov's announcement, the Debian port for 32bit SPARC machines is about to be retired.

This is really sad in my opinion, as we should rather support more architectures instead of less architectures. After all, Debian is "The Universal Operating System" [1].

Now, I know that my opinion doesn't matter much in this case, but many other people who own sparc32 boxes seem to feel the same, judging from the thread which was started by the announcement.

Also, I do realize that nobody wants to retire the port just for fun. To my understanding there is one major problem which needs to be sorted out in order to "save" the sparc32 support in Debian (and also in Linux!):

There is no Linux kernel maintainer for the sparc32 Linux code at the moment!

This seems to be the root of the whole problem. It makes maintaining a Debian port for sparc32 really hard, as you can surely imagine. Also, there seem to be too few people who actively work on the surrounding toolchain stuff (gcc, binutils, etc) which is also very important.

My suggestion would be to not drop the Debian support for now, but rather set the status to "needs help" or something and actively search for contributors and/or maintainers. Heck, list it on Unmaintained Free Software, or write a "call for help" Slashdot article, post the issue on all Linux-/Debian-/SPARC-related mailing lists etc. etc. (or write funny blog posts, heh).

I guess if two or three experienced SPARC developers would step up and take care of the kernel and toolchain maintenance for sparc32, there would be no reason to drop it anytime soon.


Syndicate content