On Fri, 21 Jul 2000, Steve VanDevender wrote:
>It's not a matter of whether the kernel should allow such a thing; even
>if the kernel itself doesn't allow such commands to be sent to the disk,
>that isn't enough to prevent it from happening via other relatively
>simple means.
>
>The kernel simply can't be expected to protect hardware from itself. If
>a piece of hardware can be made to destroy itself, it's bad hardware,
>not bad kernel programming.
But the problem then becomes the fact that there are 1000000000
pieces of this bad hardware out there that CAN be damaged.
I agree, a purist view is that the hardware needs to be designed
better. Regardless of wether that occurs or not, there is
100000000 pieces of badly designed hardware IN USE that CAN NOT
be fixed. So, if we can fix it in the OS, or at least block it
in some way, we have a win until new hardware doesn't suck.
I wonder if it is possible for all hardware that is flawed in
this matter to have new firmware which then fixes it from the
problem? In other words, IDE drive X that allows drive commands
to fry it: could a new firmware patch be applied that FIXES
this, and now the drive will only allow firmware patches and
other serious commands by checking a signature or something?
Just an idea..
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- 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:19 EST