Linux-kernel mailing list archive 2000-29,: Re: disk-destroyer.c

# Re: disk-destroyer.c

James Sutherland (jas88@cam.ac.uk)
Sat, 22 Jul 2000 12:14:48 +0100 (BST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: James Sutherland: "Re: disk-destroyer.c"
- Previous message: esr@thyrsus.com: "Re: CML2 0.7.1 is available"
- Next in thread: Trever Adams: "Subject: Re: disk-destroyer.c"
- Maybe reply: Trever Adams: "Subject: Re: disk-destroyer.c"

On 21 Jul 2000, Henning P. Schmiedehausen wrote:

> jas88@cam.ac.uk (James Sutherland) writes:
>
> >> So disk2brick.c will just bypass the kernel API and bit-bang on the IDE
> >> controller directly...
>
> >If a usermode app can hit the hardware directly like that, there's
> >something VERY broken...
>
> If it can not, I'll simply whip up a kernel module which I can acess
> from user space, which can.

There's a hell of a big difference between "type this code into
EDITOROFCHOICE, compile and run and your drive is a paperweight" and
"rebuilt the kernel, deleting this bit and inserting this replacement
driver, then proceed as above".

> There is simply no point in hiding anything from root.

Disagreed. You want to make directories editable directly, perhaps? How
about just running root's apps in ring 0? After all, you assume root is
perfect and infallible, right?

> What I tried to understand in between Andre's swearwords, is that you
> can enable drives to access a full set of parameters ("taskfile") or
> you can disable this. If you enable it, you can fry the drive. If you
> disable it, you can't but you can still use the regular ATA command
> set which is all that the kernel will ever need.

Yep. There's a big red self-destruct button on the drive. Either we leave
it enabled, or switch it off. I prefer the latter - leaving those things
lying around is just *begging* for the next Linux crack story to go "some
bastard got in with an old buffer overflow exploit, and toasted my $10k
server just by running a shell script". I don't want to see that one...

> The question now is: Once you disabled this, you can't enable it
> again? If this is truw, then I can understand many of the strange
> words that Andre used (though I still think that he was/is under deep
> sleep deprivation and strong drugs). If you can reenable this access,
> then there is no point.

Once blocked by the kernel, you have to do strange and nasty things
(screwing with the kernel, then rebooting with your own version, or using
Linux's biggest security flaw to bypass everything) to get this `feature'
available again. At a later date, I want to see that flaw closed too, but
it's harder.

James.

-
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: James Sutherland: "Re: disk-destroyer.c"
- Previous message: esr@thyrsus.com: "Re: CML2 0.7.1 is available"
- Next in thread: Trever Adams: "Subject: Re: disk-destroyer.c"
- Maybe reply: Trever Adams: "Subject: Re: disk-destroyer.c"