Udev bootscript enhancement

[Mickaël Blanchard]

Hi everybody,

Following the build of an initramfs for my LFS system, I would like to suggest two possible enhancements concerning the bootscript "udev":

1- I think it could be useful to check if /dev is already a mountpoint prior to try to mount:

if ! mountpoint /dev >/dev/null; then ... fi

This check is already performed for /proc and /sys in the script "mountkernfs". I think it's opportune to check /dev in the same way, because an initramfs which uses udev (or mdev in busybox) may already have mounted it (and moved it to the new root with a "mount -o move" command).

2- /dev is mounted using the tmpfs FS. However, the default maximum size of allocable RAM to such a mount point is equal to 50% of the total amount of available RAM. /dev may not grow over a very small size, even in the worst cases. For security, it could be useful to limit the size, no ? Example: mount -n -t tmpfs tmpfs /dev -o size=256k,mode=755

Thank you for considering my suggestion.

[Bryan Kadzban]

I think it's opportune to check /dev in the same way, because an initramfs which uses udev (or mdev in busybox) may already have mounted it (and moved it to the new root with a "mount -o move" command).

• Frankly, with all the recent kernel changes around sysfs, I'm surprised mdev works. :-) But apart from that...

• In initramfs, you can't (reliably anyway) keep groups. They might come from files, which works, but they might also come from NIS/LDAP/whatever, which won't work. That's why my initramfs generator strips out all the GROUP= settings from the rules before copying them in. And I believe that means you have to rebuild /dev after booting anyway -- so why not just unmount it inside initramfs before running switch-root? Then it doesn't matter what the bootscript does, because it gets the same setup whether there's an initramfs or not.

Or at least, that's why I did it that way...

(I should note: I *explicitly* don't use busybox for an initramfs. There's no point: you delete everything and kill all processes anyway after it's done mounting the rootfs. And it just makes life inside the initramfs harder, and adds package dependencies.)

mount -n -t tmpfs tmpfs /dev -o size=256k

Maybe... though I'm not convinced it's required, given the directory permissions (if root screws themselves over by creating a too-large file, so what? there are hundreds of ways of doing that, and most are simpler... :-) ), and the downside of getting it too small is a huge problem halfway through "udevadm trigger".

mode=755

Isn't that the default? The current scripts don't mention mode= at all, and my /dev is 0755 already. (From mount(8): mode= for tmpfs sets the initial mode of the mountpoint directory after the mount finishes. Presumably nothing else changes that directory...)

[Mickaël Blanchard]

To be honest, I didn't even tried mdev: it's too limitative for my needs. I use udevd over µClibc.

Indeed, I agree with the fact that some problems may raise. For sure, your examples regarding groups, dependencies are right. However, I think that each potential limitation has to be considered according to what one wishes: for basic uses, it may not be a problem :)

Anyway, the "mountpoint" check is done over /proc and /sys. Performing the same check on /dev does not make any harm, no ? So, everyone may feel free to proceed as he wants. :)

Regarding the mounting options, the "mode" indication already exists in the udev script. I mentioned it because I have quoted the command from it. The only thing I have added is the "size" option. Effectively, its relevance is debatable. I have put it on my own LFS, but I agree with the fact it may not be very useful, regarding the permissions. It's just that from one point of view, I find this more "consistent": allowing theoretically 1 GB of RAM for /dev, for example, troubles me a bit :)

[Bryan Kadzban]

I use udevd over µClibc.

That one, I'm pretty sure, can break at any time. The official uclibc support was yanked from udev about 3-5 years ago, when they moved to requiring glibc's fnmatch() to match attributes, and yanked all the fnmatch()-doesn't-work workaround code.

Now it's possible that this specific function was moved into uclibc shortly afterward, but when inotify support, signalfd/eventfd usage, etc., were added, no consideration at *all* was given to whether these functions were available in uclibc or not.

(Which is why I just copy glibc in. It's not like it's *that* much bigger, and it uses *no* memory after the system is booted anyway. And it's fully supported by upstream.)

Performing the same check on /dev does not make any harm

No, it doesn't. But (I don't think) it shouldn't be needed either. There is at least one other reason you wouldn't want to preserve the initramfs's /dev already, so in light of that, I'm not sure we should make it easy. :-)

But maybe none of the other editors agree. :-)

the "mode" indication already exists in the udev script.

Hmm? Not here...

Wait, sorry, I was looking at the wrong bootscripts tree. You're right, it is there, so never mind that one.

allowing theoretically 1 GB of RAM for /dev, for example, troubles me a bit :)

But what I'm saying is that if it's ever actually a problem to allow it 1G, then you're doing it wrong. :-) (Also, can't tmpfs be swapped if needed?)

Whereas if you add a limit, and then a future udev decides to make its database (in /dev/.udev) into small files (with nonzero size) instead of symlinks, then at about 4K entries or so, you run out of room. (Assuming 64 bytes per entry. And assuming there's no block size on a tmpfs, which may or may not be true: you might be forced to use 1K per file, which would be only 256 entries.)

The chances of that might be slim, but given that the format of the database can change at any time, I wouldn't rule it out...

[Mickaël Blanchard]

In fact, I have noticed that udev is a quite sensitive package, whatever the libc you use. I can say that at least udev-141 compiles over µclibc and works great: the issues you're talking about like fnmatch(), inotify, etc... seem to have been "fixed".

Currently, udev-147 or higher can't compile because the SOCK_CLOEXEC constant is not implemented yet in µClibc. However, this problem is the same with glibc: SOCK_CLOEXEC is supported from glibc 2.9, at a minimum.

Concerning the /dev "mountpoint" check, we'll see what the others editors of LFS will tell about it. I have added it on my system anyway, I just suggest it here :)

About the size limitation, this is indeed a bit more tricky. The main question is, according to me, what maximum size to allow. However, the opportunity of doing this is also debatable :)

[Bryan Kadzban]

udev is a quite sensitive package, whatever the libc you use.

Which is more or less my point. It works fine with the book (since that's what we test), but anything else is fair game to break at any point.

However, this problem is the same with glibc: SOCK_CLOEXEC is supported from glibc 2.9, at a minimum.

And we use 2.10.1, so it still works fine. Wait, no, we use 2.11.1 now. That must have been upgraded since I built this system -- but either way, it's newer than 2.9.

The udev maintainers seem to have *no* problem adding code that requires the very latest other source packages; their rationale seems to be "if distros want to support older kernel, glibc, etc. versions, then they're free to do so, but the maintenance burden is on them: we don't do that". FWIW.

[Matthew Burgess]

Fixed in r9160. I can see the value of checking for /dev already being mounted in the initramfs case, but setting a policy on what size /dev should be limited too seems esoteric enough that it should be up to an individual sysadmin to decide if that's something they want to do.