RE: disk-destroyer.c

Soeren Sonnenburg (sonnenburg@informatik.hu-berlin.de)
Sat, 22 Jul 2000 12:26:11 +0100

> Andrew McNabb <amcnabb@argus-systems.com> wrote:
> > Let me try to understand what you're saying...
> > It is established that a system's interface allows programs to
> > physically destroy a disk drive, without providing any benefit
> > whatsoever. However, since it's possible to fry other hardware,
> > too, why bother with this problem???
> >
> > The fact of the matter is, that it is wrong for a program to
> > destroy hardware. It is the kernel's job to ensure that it
> > can't.
>
> Ahh, but you've set up an impossible burden. It is _impossible_
> for the kernel to ensure that a malicious hacker who has obtained
> root on your machine does not destroy your hardware. After all,
> that hacker can always re-install an old, unsafe kernel version
> and ioctl() away, or even bit-bang directly to the raw device!

You missed the point. We all know clearly that root can do everything.
What Andre describes is more a bug: It is possible with surpass the ATA/IDE
specifications
by an awkward disk access commands (as can be found in disk-destroyer.c).

That means the kernel itself allows damaging your ATA/IDE hardware.

Lets look at another example:
Would you like an accepted call to a fbdev to burn your VGA-card
(overclocking/flash your bios/whatsoever) ?
Would you like an accepted call to a sound-device to kill your sound card ?

Surely the answer must be no.

I hope you see the difference between making a driver that has to stay
within the limits given by some specifications and a destructive attempt
that does not simply say open_ide_device( some illegal values) -> crash
(instead of open_ide_device returns error #0815 command not within
specifications) but needs to make all the illegal calls in very basic steps
from scratch.

The patch has to be applied to fix the BUG,
Soeren.
----
If an animal does something, we call it instinct; if we do the same thing
for
the same reason, we call it intelligence.

-
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/