linux-kernel - Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 2 May 2009 17:35:19 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Andy Lutomirski <luto@...ealbox.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

On Sat, May 2, 2009 at 17:18, Andy Lutomirski <luto@...ealbox.com> wrote:
> What's wrong with:
>
> mount -n -t sysfs none /sys
> mount -n -t tmpfs none /tmp

You need tmpfs on /dev, and you need initial nodes in the new tmpfs
before you can start udevd.

> udevd --daemon
> udevadm trigger

Then you need to wait for udev to finish, to be sure the nodes are
there, before you start anything else.

> once the shell comes up?

If the kernel mounts your root, and not initramfs, the shell does not
come up, when /dev is empty, like it is on some distros which always
use tmpfs on /dev.

> There could even be a standard script that all
> distributions ship that does that, plus mounts /proc and does whatever magic
> is needed to make Ctrl-C work.

There is no such thing today, as "standard that distros ship", and I
doubt there will be. We needed years to sync the device names across
distros. That happened now, but there will never be any "standard
thing that bring us a box that the kernel can "ship". Same for the
"let every new driver provide a udev rule for the names of the device
at the same time", that will never happen, people just don't care
about userspace issues at all - I've given up on trying that.

> (OK, so you depend on udev and mount working, but you already depend
> on sh working, and you'll have a heck of time rescuing anything if even
> mount doesn't work.)

You need access to your devices, and device numbers may be dynamic.
It's not about mount(8) is not working, you may have lost anyway in
such cases.

> If you want a really reliable rescue mode, then either put a whole working
> busybox system in a spare initramfs with a spare boot menu entry or just use
> a real rescue disk, neither of which require devtmpfs.

Yeah, why not have a spare box close to every one, then you can use
that instead. :) This is not about being prepared that stuff went
wrong, then you are lucky. You usually can not copy a new image to a
box that does not boot, and you do not have a working rescue disk
right next to you.

> As a separate question, what happens with devtmpfs if I plug in some device
> that uses dynamic minors, then unplug it, then plug in another device that
> gets a new minor but the same name, all before (or even after) udev starts?
>  Are there any subsystems that could do that?

The node gets removed, then a new one gets created for the new device.
Besides that there are no device with the same name at the same time
today, udev would not solve that problem either.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/