Messages in this thread | | | Date | Mon, 24 Jul 2000 04:04:40 -0700 (PDT) | From | Brion Vibber <> | Subject | Re: Direct access to hardware |
| |
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/
| |