Linux-kernel mailing list archive 2000-29,: Re: The Full Explaination ... (re: disk-destroyer.c)

# Re: The Full Explaination ... (re: disk-destroyer.c)

Myrddin Emrys (myrddin@iosys.net)
Fri, 21 Jul 2000 12:02:34 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Stephen Frost: "Re: The big IDE fight in a different light"
- Previous message: Naohiko Shimizu: "[PATCH]PAGE_GH patch revised(new support for 2.2.16)"

On Thu, 20 Jul 2000 22:29:20 -0700 (PDT) you sent this message:

>On Thu, 20 Jul 2000, Myrddin Emrys wrote:
>
>> On Thu, 20 Jul 2000 19:09:19 -0700 (PDT) you sent this message:
>>
>> >I try to provide a protective layer to the hardware and everybody says it
>> >is not needed.
>>
>> Perhaps you were not explaining your position clearly. I gathered that the
>> behavior, as described, was perfectly valid, just dangerous. You, on the
>> other hand, are now clarifying that the behavior of the system, when those
>> bytes were sent, is not correct. In other words, it's possible for the
>> system to 'accidentally' fry a hard drive... is this correct?
>
>Hi Myrddin,
>
>You are correct I have not explained the magnitude, so here goes.
<snip>
>All I want is to protect JOE SIX-PACK new user that is not security savy
>from losing his hardware with the kernel assisting in the destruction.
>Is this to much to ask?

Hmm. I guess that your and my definition of 'Joe Six-Pack' is different. In
my world, Joe Six-Pack won't be compiling and running disk2brick.c on a
Linux box. Joe Six-ack has difficulty even leaving X without hand holding.

But that is a moot point. I think, idealistically, your position is correct.
What I think you are incorrect about is the urgency with which you advocate
your position. The fix is not urgent, it's minor. There are ways of frying
hardware in userspace, a real where Joe Six-Pack is FAR more likely to be...
protection in the kernel against one specific hack adds little security.

As someone else pointed out, now is not the time to be adding changes like
this (just before a stable release). Offer the patch after the next stable
kernel, when less urgent changes are easier to get in. Remember that you're
not patching a gaping hole... you're blocking one of a hundred ways that
root can fry hardware. There are many other ways still to go, so having 99
ways to fry the system, instead of 100, is not that big of a fix. Eventually
we may get down to 0, but until we get close to that ideal, each cemented
hole is a minor change not urgent enough to risk destabilizing an even
release.

Myrddin

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

- Next message: Stephen Frost: "Re: The big IDE fight in a different light"
- Previous message: Naohiko Shimizu: "[PATCH]PAGE_GH patch revised(new support for 2.2.16)"