On Sun, 23 Jul 2000, Linus Torvalds wrote:
>
> What validation?
>
> The OS doesn't even know what the commands do. They are undocumented. And
> they vary from drive to drive.
No, they are documented as "here lie penguin-eating monsters - DO NOT GO
HERE".
> How do you expect the OS to validate the drive firmware update commands
> for every drive manufacturer?
No need - block the "DO NOT USE THESE BITS" calls.
> In short, should we
>
> - know every single drive, know every command it can take, and do all of
> this inside the OS
All in the spec.
> OR should we
>
> - move this policy into user space, and potentially have programs that
> know what different drives can do, and upgrade them the proper way
IOW, pass the buck to every app that runs? Let's go one better, shall we,
and put file access controls in userspace too? And network protocol
handling, scheduling, etc. In fact, let's just remove the whole OS and go
with an MS DOS clone, and leave EVERYTHING up to userspace! :-)
One of the functions of an OS is to act as the interface between hardware
and applications. The approach being advocated here by some is "just leave
the unmarked minefield sitting in the penguin enclosure - we'll squeegee
Tux off the walls later". I'd rather keep the munitions somewhere else.
> I think the thing is fairly clear. If you want "the OS" to validate the
> parameters, then you should create a user-mode program that validates the
> thing.
And how does it do that - strace every app running as root, so it can
filter ioctl calls?!
> Basically, Linux already validates everything it _can_ validate. Sure, it
> could also verify that only "approved" commands are sent, but what about
> the undocumented yet potentially useful ones?
They aren't "undocumented" per se; they are low-level vendor-specific
commands for diagnostic purposes.
> Let's take a hypothetial example (you judge on just _how_ hypothetical it
> actually is): imagine that you have a drive that can be made to refuse to
> read certain removable media based on where the drive was purchased.
> Imagine that this was actually done in firmware, and that there was a way
> of overriding it. Imagine further that you moved, and you wanted to make
> the drive read certain removable media in the new location, using
> undocumented commands..
What you are trying to do in this case is send one very specific command
(or set of commands), as a one-off (much like a genuine firmware upgrade,
in fact). There should be a specific interface for doing this.
> Should the kernel block those commands because it doesn't know what they
> do?
Under normal circumstances, yes. Then you use a bootdisk with a suitable
kernel on for performing firmware upgrades etc.
Right now, I can't update my motherboard's BIOS from Linux either - I have
to drop out into FreeDOS for that. I'd view that as a strength of Linux,
not a flaw.
> Or should the kernel assume that "Oh, he has the permission to do this,
> then sure, I'll let him do it..".
>
> Note that everybody has gotten very lathered up about the fact that you
> can kill certain hardware. Guess what? This is neither new nor very
> exciting. Look at your XFree86 configuration file some time, and read the
> warnings in the documentation. And ruminate on it. A monitor can be quite
> a bit more expensive than your harddisk.
Hmmm - maybe that's why XFree86 filters your mode selection based on what
monitor you have?? And why monitors filter the signal, to reject anything
which is inappropriate?
If I try running my monitor at 16000x12000 @ 1kHz, XFree86 will barf. If I
reduce that to something plausible enough to get past XFree86, but not
suitable for ye olde CRT, ye olde CRT just rejects it and starts flashing
a little LED on the front. Only valid signals get through.
Now, the drive CANNOT tell which commands are "valid" and which are not -
so the OS must do it for the drive.
> Firthermore, destroying your harddisk may be the most _polite_ thing that
> can be done to you. Quite frankly, I'd personally rather have a dead
> harddisk than have all my data on that harddisk be siphoned back to an
> intruder.
I'd rather prevent the intruder being able to kill the disk in the first
place. Obviously, we also try to prevent him being able to get in, but
that's another issue.
> A dead harddisk you might get a refund for under the warranty.
Not if it was killed this way.
> Your credit card information (or your browsing habits or copies of
> your personal emails) made available all over the place might be more
> of a bother.
If one of my CC numbers gets stolen, I can just tell the bank about it and
get it replaced. No big deal - just a bit of a nuisance.
> "There are worse things than death". Even with harddisks.
This is not a "give me your data or die" decision. It's more of an "I've
got your data, now I'm going to kill you" situation. Personally, having
been robbed, I'd rather remain alive afterwards.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:16 EST