[lkml]   [2000]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Direct access to hardware
    James Sutherland <> writes:

    > On 25 Jul 2000, Michael Poole wrote:
    > > The only way to try to protect the hardware from the kernel is to
    > > filter out *all* undefined (nonstandard) commands. These are not
    > > necessarily just diagnostics or maintenance commands. They could be
    > > vendor-specific power management commands. They could be commands to
    > > make the drive kick in s00p3r-s3kr1t high performance mode. The
    > > commands could be literally anything not described by the spec.
    > >
    > > There are reasons for non-vendor software to talk to the drive, but
    > > you continue to pretend there aren't.
    > Such as? (Bearing in mind this should void the warranty...)

    Any of what I listed are possible reasons. The password protect for
    Jaz drives mentioned elsewhere in this thread is an actual, real-life
    example. You said that sounded like a bad implementation -- but there
    is no way to do that within the standard-defined commands.

    > > There are reasons to not want to reboot just to use these extensions
    > > (firmware upgrade or otherwise), but you continue to pretend there
    > > aren't.
    > Not the case. I said there are ways to avoid the need to reboot on
    > mission-critical systems.

    If you assume hot swappable hardware, yes. That's a big assumption.
    Would you require a reboot for 90+% of the market simply because they
    don't pay several times more for their hardware?

    > > There are, however, no reasons for the kernel to filter the commands
    > > it sends to the drive only sometimes, but you continue to pretend
    > > there ARE (with your compile-time option).
    > There are reasons to filter these commands out under normal circumstances,
    > as Andre has explained. There are also probably exceptional circumstances
    > where you would want/need to bypass this - for a repair/diagnostics disk,
    > for example.

    The only coherent point I've seen Andre make is that the drive should
    check the vendor-specific commands it receives to make sure they are
    sane (as in checking a signature for a firmware update). ATA
    extensions are not just about repairs or diagnostics -- they can
    easily be about day-to-day operations that must not require a reboot.

    > > Talking to the drive should be permitted under Linux or it should not;
    > > you shouldn't have to switch on some "firmware upgrade kernel" flag
    > > just to talk ATA extensions.
    > It's not a case of talking "extensions", just a matter of preventing
    > access to the vendor-specific commands which potentially void the
    > warranty.

    If your RAM vendor said that you could void the warranty by storing
    the text string "magic ju-ju beans" into it, would you believe them?
    Would you want to add microcode to your processor just in case
    somebody tried to put that string into RAM?

    Making vague claims about voiding warranties doesn't help the
    discussion. If the drive vendor wishes to forbid user firmware
    upgrades, they can simply make that available only through physical
    modification of the drive (which would void the warranty in itself).
    If they want the host CPU to update their firmware, they'd better be
    prepared for all that entails.

    > Anyway, Andre has now rendered this argument academic: the drive should
    > now enforce these limits, logging any violations in case of later warranty
    > claim. A much better solution, I must admit.

    Yes, except his proposal came across as rather confused to me. Not
    least because he persistently misspelled "vendor" as "vender" and
    implied that all vendor-specific commands can damage the hardware or
    render the drive inoperable (which, after a little thought, or given
    the Jaz write-password example, is an invalid assumption).

    Maybe the T13 standards committee will clarify the proposal before
    endorsing it. Maybe they won't endorse it at all. Either way, it
    is not the responsibility of the kernel to police what applications
    send to a raw I/O interface they requested to use (and for which
    they had permissions as the kernel knows permissions).


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.026 / U:2.968 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site