Skip to content

We have to be ready to do anything. Do you hear me?

Good people steal ideas, right? On that basis I setup a static domain to host the javascript and icons I use upon a few different sites & projects. This was preempted by the release of a new version of the excellent jQuery library.

I also managed to put together a tremendous hack to solve a pretty annoying problem running multiple distributions from a single external kernel under KVM.

Ubuntu users, in particular, will be well aware of dmesg SPAM coming from the use of CONFIG_SYSFS_DEPRECATED.

In short the way that the kernel presents information beneath the /sys tree has changed over the life of the kernel - and this has a knock-on effect to the userspace supplied by different distributions and releases of GNU/Linux.

Some distributions need an "old" kernel and an "old" udev with "old" udev rules in order to create the appropriate device nodes such that the kernel will boot & mount its filesystems. (i.e. These need CONFIG_SYSFS_DEPRECATED to be set.)

Conversely some distributions mandate a "new" minimum kernel version, and supply a "new" version of udev with "new" udev rules and they absolutely will not function when presented with an "old" kernel. (i.e. They must have kernels without CONFIG_SYSFS_DEPRECATED set.)

I've solved this problem via a kernel patch which is both evil and genius. The details are a little me-specific, but in short:

  • devtmpfs is used to setup and mount an initial /dev tree before /sbin/init is launched..
  • udev launches later and mounts a tmpfs over /dev such that it can start creating its own nodes.
  • At this point evil begins: I've patched the kernel such that any attempt to mount a tmpfs filesystem at /dev is silently changed to mount a devtmpfss filesystem instead.
    • The alternative is that udev creates many nodes, but manages to fail to create the root & swap nodes such that the KVM guests fail to boot.

Ultimately udev doesn't get an empty /dev tree to play with, instead it finds one already pre-populated, such that any devices it cannot create are there regardless - because the devtmpfs implementation has already created them.

Genius. And evil. So very evil.


Steal that idea. I dare you .. (I'm impressed at how well devtmpfs works, and how easy I was able to make my "patch of evil"tm. Just a few lines in fs/namespace.c.)

ObSubject: The Last House On The Left

Comments On This Entry

  1. [gravitar] Anonymous

    Clever, and evil. :)

    One minor security implication: in theory you can use containers or SELinux to let users (or root) only mount certain filesystems but not others. That together with restrictions on mknod can prevent access to device files. Your hack makes tmpfs suddenly a dangerous filesystem to permit, if the user in a chroot/container can mount something over the /dev in the chroot/container.

  2. [author] Steve Kemp


    In theory you're correct, this has the potential to weaken security in a surprising way.

    In practice I think that this is less serious for the simple reason that the user has to be root to mount a filesystem.

    (I have to say that I never use SELinux, I just don't like the complexity.)