In <Pine.LNX.4.21.0007221745540.21586-100000@asdf.capslock.lan> Mike A. Harris (mharris@meteng.on.ca) wrote:
> 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.
Yes. And guess what ? They CAN be damaged WITH proposed patch as well.
> 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.
We can not. End of story.
> 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..
It's not always possible but yes, in some case it's possible. Still chances
are VERY slim: if manufacturer designed such flawed hardware in first place
chances are REAL high that this problem does not bother them at all so who
will create such firmware ?
-
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