Andre, I hate to add to this thread but I'm hoping to make it more clear
to myself and hopefully others so we can all make the Right Decision and
finally stop yakking about it... :)
On Mon, 24 Jul 2000, Andre Hedrick wrote:
> Willfully and now knowingly issuing commands that are otherwise not listed
> will be defined in ATA-ATAPI Specification can be deemed as violation of
> the Standard. Regardless if there are vendor-unique commands present or
> not, this would defined as accessing commands that are not considered the
> standard and deemed a violation.
I haven't read the whole ATA standard so like most of us out here I'm
working without all the foreknowledge that you have about the issue. So
please excuse me if my reasoning and questions seem lost - IANAVT13CM!
If I understand you correctly, you are saying:
* Some non-standard commands are accepted by drives as vendor-specific
extensions (some of them dangerous).
* Sending any non-standard command is in violation of the standard.
* Violation of the standard may void a drive's warranty.
* No non-standard commands will be sent by the Linux kernel's IDE driver
unless a program with root priveleges tells the kernel to send them via
the currently unprotected ioctl.
>From which I, the clueless user, infer that:
* Using a legitimate vendor-specific command may void my warranty.
* If no non-standard commands are sent, there is no violation.
So...
* If a drive admin program sends non-standard commands, IT IS A VIOLATION.
* If a rootkit sends non-standard commands, IT IS A VIOLATION.
* If no non-standard commands are sent, NO VIOLATION TAKES PLACE.
Am I right so far, or am I really misunderstanding what you've said?
Now, does it make any difference to the above whether the sending of
commands occurs through the regular kernel interface ioctls, through a
hacked kernel driver, or straight to the ports bypassing the driver? (In
any case the command is ALWAYS initiated by a user-level program, not by
the kernel.)
If it makes no difference, then can the kernel be held responsible for
violations performed by a program bypassing the kernel's IDE driver?
If yes, then there's *nothing we can do* either technically or
liability-wise besides remove CAP_SYS_RAWIO immediately after boot (with
Vojtech's patch). Equivalent goes for Microsoft and Apple and Sun... If
a priveleged program can access raw hardware, then the system can
potentially violate the standard.
If no, then a filter would keep *the driver* in compliance with the
standard even if told to violate it, and might *conceivably* cover
people's asses by dumping liability firmly where it belongs with the
instigator of the (legitimate or rogue) program and the kernel's hands
clean.
But it DOES NOT make it impossible for violations to occur. If my kernel
is hacked or simply bypassed by a malicious worm or a legitimate firmware
upgrade util (oops, wrong model - drive's dead!) then my warranty can
still be violated, and my drive company can still blow me off when I ask
to have it fixed because *their* firmware upgrade or lowlevel disk format
command didn't have safeguards. (I can't imagine real safeguards against
lowlevel format eating your data, but several people have mentioned ways
to make firmware safe or user-recoverable.)
It DOES MEAN that the lawsuit-happy people won't be quite as likely to
go for Linus or the distributions when they have to replace a drive and/or
lose their unbacked-up data. IANAL of course... Besides, who's really at
fault never stops people from suing anyone with pockets here in the US. :P
Again, if any of my understanding or reasoning is faulty here, Andre
please correct me! I've been following this thread since the beginning,
trying to make sense of it all, and by now it really seems to be less of a
security or safety or technical correctness issue and more of a liability
issue so that if a disk2brick-type virus does go around someday we can all
point at someone else when the insecure systems die, saying "well, it's
not OUR driver's fault, we did our best"?
-- brion vibber (brion@pobox.com)
-
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:16 EST