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]

Message-ID: <ac3eb2510905041113x58bdb807od7dd4a6ce258e317@mail.gmail.com>
Date:	Mon, 4 May 2009 20:13:00 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Michael Riepe <michael.riepe@...glemail.com>
Cc:	Lars Marowsky-Bree <lmb@...e.de>,
	Alan Jenkins <sourcejedi.lkml@...glemail.com>,
	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 Mon, May 4, 2009 at 19:54, Michael Riepe
<michael.riepe@...glemail.com> wrote:
>> The problem is not the missing events, they could be pretty easily
>> recovered from sysfs with just another special hack to run at bootup -
>> it's the time it takes to bring up the engine to bootstrap /dev, to
>> allow us to start any other process which looks for devices. Today,
>> udev mounts /dev as a tmpfs, and at that point it is obviously empty,
>> and needs to be filled, and nothing else can reliably run at that
>> time.
>
> And what about mounting /dev from an already populated image? Or, even
> faster, using the /dev directory of the root fs? That way, the device
> nodes would be present as soon as / is mounted, without any additional
> overhead, except the very first time the system boots (in case you
> choose not to populate /dev with a default set of device nodes in advance).

Dynamic device numbers! A static /dev does not work at all for many
subsystems, not to mention the risk you take by talking to the wrong
device pointed to, by your incorrect static device nodes. It's not an
option at all today, and it will get much worse in the future.

> I know, not using tmpfs is a security risk and whatever. But does that
> really matter in an embedded system where you have no user accounts?

If you have a very limited environment, and no hotplug setups, sure
you can do that. But some of us have not even sd* as stable numbers
anymore.

>>   The plan is to start udevd, but run the coldplug in the background
>> and start other stuff in parallel, because you can be sure that all
>> currently known devices are already there, and the missing meaningful
>> symlinks created by udev will show up soon, along with a new event to
>> hook into. There will be no hard checkpoint anymore to wait for the
>> basic environment..
>
> You can do that with a persistent /dev as well. It will even keep the
> symlinks udev created before the system rebooted. The only drawback is
> that you have to wait for device nodes that belong to new devices which
> were connected to the system while it was down. But that rarely happens,
> and will eventually be fixed by udev.

What? Keeping the links is insane, many things can go wrong with that.
Udev does not work reliable on non-tmpfs - you can do that, but don't
be surprised if stuff goes wrong and talks to the wrong devices.

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/