lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectButting in.. (Was: scsi-destroyer.c to come...)
    Hi all!

    With this mail I'm going to try to accomplish a good thing(tm) - hopefully
    I'll succeed. :)

    In this mainly-IDE-thread there have been at least two facts stated (or
    discussed) and I've got some comments on them. (Woohoo!)

    1. It is possible to write software that will damage hardware.
    ---
    Why is this? Simple; it adds functionality for the end-user.
    The manufacturer of my modem has made it possible for me to upgrade the
    firmware of the modem by running software from their website.
    I, as an end-user, think this is really neat. I bought a top-of-the-line
    28k8 modem in '95 which is still top-of-the-line five years later, thanks to
    a couple of firmware upgrades. However, this functionality also means shit
    can happen that will cause my modem to be useless. (..turned into a brick.)
    This could be because of a power-fail situation right when I'm sending out
    the new firmware to my modem, or by my kid brother throwing a ball into
    the computer room, hitting the serial cable causing it to glitch for a
    millisecond or two. I can protect my modem from both of these things,
    but at what cost? I'd have to get an UPS for my computer/modem because I
    want to upgrade my firmware in MS-DOS and I'd have to lock the door to the
    room where I keep the computer. I'm not going to buy an UPS just because I
    want to upgrade my modem. Instead I'm going to risk the FlashROM being
    destroyed or only half-updated. I feel comfortable with this because I know
    how to take apart the modem and replace the ROM, but if I hadn't known that I
    would instead have wanted the manufacturer to add some sort of mechanism to
    the upgrading process that would withstand even a power outage. This can of
    course be done. (By downloading the new firmware to a temporary memory in
    the modem and then programming the FlashROM from that temporary memory, the
    entire modem being backed by neccessary batteries (or whatever) to make sure
    that the programming process will finish before the modem shuts down in lack
    of power.) However, I also realize that this would be pretty costly for the
    manufacturer to do and therefore it's (unfortunately) not all too likely to
    happen. Likewise I would like the manufacturer of my IDE drive to do their
    utmost to make sure that my IDE drive IS forward-compatible AND at the same
    time not a reason for headache.
    This could eg. be accomplished by the spoken-of jumper, that when enabled
    will allow updates of the firmware. Furthermore that update should of
    course take place in a manner that cannot easily cause the IDE drive to
    become useless. (Brick, again.) If this is not possible I would want an
    IDE drive that doesn't have any firmware updating facilities, or, perhaps
    more likely, I wouldn't want an IDE drive at all.
    Bottom line:
    Since we want to be able to upgrade firmware in hardware units, we have to
    accept that this can be done. However, what we shouldn't accept is that it
    can be done by anyone. (Someone we don't want to have on the inside of our
    computer casings.)


    2. The Linux kernel can be changed into just about anything root wants.
    ---
    Why is this? root is god in the system. And if I wouldn't be god in my
    Linux system, I'd probably still be running that-other-OS developing VB
    applications. This is however not the case. This is one of the things I
    like very much about Linux. Linux is sitting there in front of me, and I'm
    free to grab the chainsaw and start taking away features/bugs/stuff I do not
    need or do not want. And I know how to do this as well, because I'm a good
    god; I know C and hacking.
    This is what I feel about the IDE driver imposing restrictions on what will
    be sent further down the chain to the IDE harddrive:
    If I issue commands to the IDE driver that are either
    * not documented by the standard, or
    * prohibited by the standard
    I of course expect the IDE driver in the kernel to not accept them, just as I
    expect my modem above to not accept undocumented/prohibited AT-commands.
    (Maybe their real name is 'Hayes-compatible commands', I'm not sure.)


    I've realized I'm not clear about whether that command sequence causing the
    IDE-harddrive to fry was allowed by ATAPI or not, but I don't think it
    matters too much. If they aren't, the thoughts above applies and the patch
    SHOULD be included. If they are valid (protocol-wise) it's really not a
    smart/good protocol. A harddrive shouldn't come with a self-destruct button
    imho. :)

    The patch CAN be very good if I make a typo whilst hacking and accidentally
    send out the dangerous commands to the IDE-harddrive. If this is a good
    enough reason for Mr. Torvalds to include it into the kernel is not up to
    me, but it's definately a good enough reason for appreciating the patch.


    And when it comes to /dev/kmem and all the fun stuff you could do with that,
    I think that it should be considered another story all together. It's a
    different way of hardware<->application communication than through a
    hardware driver in the kernel. The hardware driver is cooked and should be
    to any extent useful in all contexts of usage. The "raw IO driver" that
    /dev/kmem is really shouldn't be too neccessary in everyday use. If you
    need it you could load it as a signed module or something like that. If
    there isn't any vital use for it I'd even go as far as to disable it
    completely in the kernel if I want to raise the safety level.
    It could eg. be used to update the IDE harddrive firmware, by some
    update-application I got from the harddrive manufacturer.
    During the updating process, my harddrive is of course as fragile as my modem
    was in the updating process described above.


    Closing words:
    Please, Mr. Hedrick, don't let almost-everyone's bitching at you put you down
    in your work. Code is better than no code. Especially if it does good
    things(tm). And since we are in the land of Open Source, we can choose not
    to use it and risk our hardware.

    Bye!

    (Ouch, it's 9:15am and I'm still up. Please excuse any insanity in this mail
    caused by insomnia.)

    //Peter

    --
    irc: CareBear\ tel: +46-40-914420
    irl: Peter Stuge gsm: +46-705-783805

    -
    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:4.786 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site