> 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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:18 EST