Eudyptula Challenge: superfast Linux kernel booting

Vincent Bernat

The Eudyptula Challenge is a series of programming exercises for the Linux kernel, that start from a very basic “Hello world” kernel module, moving on up in complexity to getting patches accepted into the main Linux kernel source tree.

One of the first tasks of this quite interesting challenge is to compile and boot your own kernel. eudyptula-boot is a self-contained shell script to boot any kernel image to a shell. It is packed with the following features:

  • It boots almost any Linux kernel, from distribution-provided kernels to custom kernels1 built to hack on some feature.

  • It uses the host root filesystem as the guest root filesystem. No disk images are needed as they take a lot of space, need to be maintained, become cluttered and the tools you need the most are never installed. To avoid any alteration, by default, the host filesystem is mounted read-only. If available, OverlayFS or aufs are used to add a writable overlay on top of it. It is also possible to use any directory as the root filesystem.

  • Your home directory is also available. This provides hassle-free sharing of scripts and results with the host system.

  • It starts a minimal system. Only the bits needed to start a shell will be involved.2 The whole system is able to boot in less than 5 seconds.

In the following video, eudyptula-boot is used to boot the host kernel and execute a few commands:

In the next one, we use it to boot a custom kernel with an additional system call. This is the fifteenth task of the Eudyptula Challenge. A test program is used to check that the system call is working as expected. Additionally, we demonstrate how to attach a debugger to the running kernel.

While this hack could be used to run containers3 with an increased isolation, the performance of the 9p filesystem is unfortunately quite poor.

virtme-ng is a similar project.

  1. The only requirement is to have 9p virtio support enabled. This can easily be enabled with make kvmconfig↩︎

  2. Only udev is started. ↩︎

  3. A good way to start a container is to combine --root, --force and --exec parameters. Add --readwrite to the mix if you want to keep the modifications. ↩︎