lkml.org 
[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: What's wrong with IDE patch and what proper solution should be (Re: disk-destroyer.c)
From
Date
James Sutherland <jas88@cam.ac.uk> writes:

> > Not exactly. We NEED sanity checking in kernel and we HAVE it. Just
> > HDIO_DRIVE_CMD is NOT kernel command.
>
> Wrong.

What's exactly wrong?

> Again no, there should be a legitimate kernel interface for "put drive to
> sleep" which userspace then uses.

Right.

> Firmware upgrades should be done via the firmware upgrade interface from
> the kernel, NOT via a "do arbitrary crap" interface.

There are different drives and different drive manufacturers, all of them
using different upgrade methods. Most of the info is not publicly
available. While I can imagine driver manufacturers make disk utils
(which use raw ioctl interface) available, I don't think it's possible
they soon start to write any necessary kernel modules.

> Agreed on both counts - so what DO we do for 2.4 in the mean time? IMO, we
> should block as much of the "arbitrary screwing with hardware" API as
> possible for now, and block the rest out later once we have a proper
> replacement.

Should we block firmware updating or not? The patch blocked it.
Without blocking it, you gain exactly nothing.

> How so? If it blocks out some of the direct arbitrary crap, it's a step in
> the right direction.

Does firmware updating count as this crap, and thus it should be
impossible? If you have interface for updating the firmware, you
have a way to destroy the HDD - just use incorrect firmware.

> Indeed - we need a kernel interface good enough for XFree86 & co to use
> instead.

Right.

> If we divide use of the direct API into two categories, legit and
> non-legit, it seems clearer.

Does flash update command fall into legit category or not?

> Yes - so take the nuke away. Andre is taking part of the nuke away with
> his patch; the rest can follow later.

As well as he's taking flash updates away.


Well, let's compare:

current (+CAP_RAW bug fixed) interface:
+ smaller kernel size
+ all IDE commands (incl. proprietary ones) are handled allowing
for simple diagnostics tools from hw makers
+ disabling raw caps you disable access at hardware level.
- otherwise rogue root can erase drive firmware


No raw ioctl + all-in-kernel interface:
- larger kernel size
- every diagnostics tool need special kernel module from hw maker
- rogue root can still damage the drive using flash update
(or any other suitable) interface.

The original patch:
- larger kernel size
- no possibility to use any diagnostics tools
- rogue root can still damage the drive using any suitable interface
probably unless raw caps are revoked.

Of course I agree there should be better way to, for example, put
a drive into sleep, and it probably shouldn't require raw caps
(could a drive be destroyed be using this?). This is a minor thing
anyway (and a patch which adds such interface would be 10 lines long).
--
Krzysztof Halasa
Network Administrator

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

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site