Kurt Garloff (
Fri, 4 Dec 1998 01:00:06 +0100

On Thu, Dec 03, 1998 at 10:25:39PM +0000, Riley Williams wrote:
> > It's not that easy. You can have ext2 filesystems on ROM devices...
> Only if the ROMfs is selected, whether "M" or "Y" is irrelevant...

No. ROMfs is just a FS optimized for read-only and for requiring few space.
You can put ext2fs on a ROM device, of course.

> > ...or a network block device.
> You sure of that? I understood that NFS didnae use any of the other
> file systems as it's a file system in its own right...

No! You can put ANY filesystem on ANY block device.
Why would somebody create nbd, otherwise? Read Documentation/nbd.txt, if you
don't believe me. (It also says, that you need some program to set it up, so
you can't use it as root device. But hey, use NFS as root and a nbd for your
ext2 fs.)

> > And it should be possible to compile a kernel w/o IDE and SCSI, but
> > with ext2fs and nbd.
> Possible, yes - but then, it's possible to compile a kernel without
> support for a.out or ELF - whether such is sensible is another
> question...

I guess, you're right here. But have a close look at the other possible
binfmts. binfmt_script is out of question as the interpreter has to be
loaded ...
Maybe you can use a kernel for routing and forwarding network packets and
things like that without needing userspace tools. But, yes, this is very

> > If you want to put a warning for this case, OK, go ahead.
> That's all I was referring to anyway...
> > ... and the needed modules can still be added and inserted.
> Even if the relevant options were selected "N" when configuring the
> kernel? That's not my understanding.

I have to admit, that I don't know how this is handled exactly. I know, it's
possible to compile drivers for SCSI adapters as modules and inserting them
after having compiled a kernel with "N" configuration for this adapter.
Some modules might change the rest of the kernel by being selected with "M",
but I think, Linus would not like such dependencies, and so there most
probably only a few or none misbehaving like that.

> > The modules add significant complexity to your sanity checks.
> Why?
> IMHO all the sanity check needs to deal with is whether or not options
> are set as "n" which in each case is a Yes/No decision. As an example,
> have a look at the following, which generates an error if the a.out
> and ELF executable formats are both set "n" since the resulting kernel
> is rather less than useless...
> ===8<=== CUT ===>8===
> --- linux/arch/i386/ Mon May 13 05:17:23 1996
> +++ linux/arch/i386/ Thu Dec 3 22:14:45 1998
> @@ -36,6 +36,12 @@
> if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
> tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
> fi
> +if [ "$CONFIG_BINFMT_AOUT $CONFIG_BINFMT_ELF" = "n n" ]; then
> + echo '*** ERROR: Either a.out or ELF format is' \
> + 'ESSENTIAL for Linux to work.' >&2
> + echo ' Aborting configuration.' >&2
> + exit 1
> +fi
> bool 'Compile kernel as ELF - if your GCC is ELF-GCC' CONFIG_KERNEL_ELF
> choice 'Processor type' \
> ===8<=== CUT ===>8===
> Perhaps you could advise what's complicated about that...

If you are sure, it's never useful to have a kernel without both ELF and
A.OUT support, then it's the correct thing to do.
But in most cases, I would not like to have an ERROR. You can display a
WARNING, if you think the kernel configurator does something very stupid.

Consider the NFS/network example. Imagine root to have compiled modules for
the network support. For some reason (s)he wants to have NFS in the kernel,
but not recompile the network modules (maybe because (s)he has a 386). You
should not forbid to do that.

Un*x is used by a lot of people who know very well what they are doing. You
can easily annoy these, by not allowing them to do what they like.

> > There are so many ways to screw your system if you are root and
> > don't think enough before you are doing something. Un*x is about
> > saving the user from doing stupid things but not root.
> Why not root? We already include some checks to prevent root from
> doing stupid things - for example, the kernel refuses to compile if
> the compiler used is too early a version - and I can see nothing wrong
> with putting in checks for other insane choices for precicely the same
> reason - to reduce the bug reports caused by setting such insane
> choices in the first place.

The security concept of any Un*x-like system is based on the assumption that
we can trust root. The system needs to be set up, maintained, etc. and for
this you need to be able to do things which can hurt you. I see no easy way
out of this unless the computer becomes really intelligent. Then the
computer will use humans to accomplish what it thinks is good ...

You can screw or crash your system by deleting /lib/*, catting
random stuff to /dev/mem, overwriting swap partitions etc. You don't want
the kernel to check all this!

If you read linux-kernel, you probably noticed, that a lot of times users
post a "Linux bug" or "security hole", which can just be exploited by root.
Nothing which can only be exploited by root is a bug. At most bad policy.
(I don't want to say that the kernel should do no checks at all, if you are
root ...)

BTW, there are some discussions how to better assign capabilities to users
and root. The easy approach "root is allowed to do anything, the user almost
nothing" is sometimes too stupid. Cause sometimes users need to do things
which they can not be allowed in a general way, there's a large number of
suid/sgid binaries and every single one is a potential security hole.
Reducing the number of suid binaries needed is a good approach.

I'm getting offtopic ...

If it's obvious and easy, add the checks. There's nothing wrong with it,
then. If it's compilcated and non-obvious: Don't even try to get it right.
You only complicate things then and the probability you missed something is
really high.

> > If there are easy and obviously correct sanity checks (when you do
> > something which never makes sense), then add a warning or error
> > message.
> Precicely what I said in the email you appear to take such exception
> to, so what's the problem with doing that?

You really have to think twice before you forbid anything to anybody.

Another example:
I happen to maintain a SCSI driver (tmscsim) for the DC390/AM53C974
controller. In the it used to check whether the AM53C974 driver
is enabled and didn't allow the DC390 driver to be compiled in, then.
Nonsense! There might be perfectly valid cases to compile both, even if they
support the same chip. Just imagine machines with, say, 2 DC390s and another
onboard AM53C974 adapter.
* Old versions only supported the Tekram DC390s.
* Recent versions of tmscsim can be told to only support DC390s.
So you can drive different adapters with different drivers, even with the
same chip...

The example mentioned was also wrong, IMHO. It does make sense to compile
ext2fs w/o IDE nor SCSI (nor floppy) support!

> > In the kernel configuration process, there aren't many such cases,
> > which aren't already prevented, IMHO.
> {Shrug} The above case thereof was discovered with less than five
> minutes study of the options presented by "make menuconfig", so is
> hardly hidden. If such an obvious case is so readily apparent, then
> there must be MANY more subtle ones...

There are some config options you are not allowed to select, if you don't
select the one they are dependent on. Eg. PCI devices w/o PCI support.
I think most obvious cases are covered by such a logic.

> > I don't think, Linus will accept anything apart from cases, where
> > it's obvious, that this configuration won't be any good.
> I wouldnae think as much of him as I do if he accepted anything more
> than that anyway, so I can't say that worries me...


I think we had enough discussion about this. I think you are wanting to find
cases where the configurator is obviously doing stupid things. Think twice
and add warnings (or errors, if it would result in a non-functional kernel)
and post them. I think these will be discussed ...


Kurt Garloff <>  (Dortmund, FRG)
PGP key on

The second clause "open source code of derivative works" has been the most controversial (and, potentially the most successful) aspect of CopyLeft licensing. -- Halloween Document

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at