>> How is a non-writable,non-remountable static /dev different from a
>> non-writable, system immutable devfs configuration file?
> I can think of a number of ways.  Here are some examples:

> 1) A whole lot of new and potentially buggy (certainly, highly
>    complex) code is in the trusted path.

This is true of any of the devfs proposals.  (Not that that weakens the
point, really; just pointing it out.)

> 2) [...] devfs must refuse to mount if its configuration file were on
>    a nodev filesystem.

I don't see that that necessarily follows - it really depends on what
you think of nodev as meaning.  "This branch of the filesystem tree is
to contain no functional device nodes"?  No problem - the mount point
shouldn't be under there, but the config file may be.  "This branch of
the filesystem tree is not to be trusted to specify anything about
devices"?  Then you're right.

> 3) Enforcing the restriction necessary due to #2 means that the file
>    parser *must* be in the kernel

Yes.

>    (think about it: you *cannot* allow a userland program to feed you
>    a devfs config structure from RAM, or there is no point to ever
>    trying to mount anything nodev;

It depends on what you think of nodev as meaning - see above.

>    [...]).  That means quite a bit of complicated code in the kernel
>    (including a parser, and code to read files from the filesystem,
>    which AFAIK only LFS does right now,

Umm...the exec code paths read from files routinely.

>    [...]) and all of this code seems likely prone to bugs which could
>    have significant security implications.  That's particularly scary
>    to me.

That's a good reason to keep devfs optional for now, yes.  Once it's
been hammered on for a few years (making it the default in new installs
should have that effect) then maybe it will be trusted enough for use
in hardened systems.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B