James Sutherland <jas88@cam.ac.uk> 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).
Michael
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:20 EST