>If manufacturers of IDE disks ship a product that can be made to break
>itself by issuing commands to it, then they cannot blame OS developers
>and vendors for that fault. Quite simply they are deliberately shipping
>broken hardware, and trying to blame other people when it breaks.
>You're buying into that whole farce, Andre. It's not your fault or
>Linus's fault that those drives can be made to break. You might try to
>put code in the IDE driver to prevent it from issuing these commands,
>but anyone with root access to the system can arrange to issue those
>commands through a number of other methods (access to /dev/port,
>inserting a module with an old version of the IDE driver, etc.). So
If someone's broken into the system, compromised root access, and is
really intent on killing the hardware (and knowledgeable about how to do
it), the EASY way would probably be to have a program that sends the
appropriate commands under DOS (no OS between you and hardware), make a
bootable DOS disk image, copy it to /dev/hda1 (or whatever you boot to,
run lilo if necessary to twiddle booting to the image), and reboot the
system with the sucker autoexecing itself.
At that point, Linux is out of the loop, and there's NOTHING you can do
in the kernel to make that unworkable without totally crippling your
system anyway. You can't even get fancy about intercepting and parsing
port commands. The OS isn't running anymore.
I reality, what does this mean? Simply formattting your drive could
easily cost thousands of dollars in lost time and productivity if you DO
have good backups. Killing a $200 IDE drive is basically adding insult
to injury. Any corner computer store can have you back in business in
an hour, hardware-wise. It's commodity stuff. Paying your employees to
reinstall and reconfigure the system just might cost more than the new
hardware...
Software destroyable hardware isn't something more software can
protect. It's like the old Microsoft strategy of "piling on more code
until the system becomes stable and efficient". It just doesn't work
that way.
Rob
-
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