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    [W:0.022 / U:0.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site