Messages in this thread | | | From | "Khimenko Victor" <> | Date | Fri, 21 Jul 2000 22:55:00 +0400 (MSD) | Subject | Re: The big IDE fight in a different light |
| |
In <Pine.LNX.4.10.10007211125530.13659-100000@master.linux-ide.org> Andre Hedrick (andre@linux-ide.org) wrote: > On Fri, 21 Jul 2000, Stephen Frost wrote:
>> On Fri, 21 Jul 2000, Scott Long wrote: >> >> > I think the kernel people need to remember one very important thing: you >> > are no longer working for yourselves, as a hobby. Your ideals about what >> >> Wrong. >> >> > So don't try to convince me that *I* am wrong by giving me technical >> > spew. It won't work. And it won't work for the many other users out >> >> The point is to be technically correct.
> Then why is everyone fighting me from preventing "technically incorrect" > commands that can/will hurt/damage/destroy hardware from being rejected?
If you can prevent such "technically incorrect" commands in RELIABLE way then such patch should be accepted IMVHO. Sometihing like capabilities check (so you can forbid access to /dev/kmem, HDIO_DRIVE_CMD and some other dangerous things and thus GUARANTEE that even root can not break the jail), but such check already there (or I'm wrong?). Filtering is just stupid thing to do: it's rejected by same reason as non-executable stack: works as short-term solution, does not work as long term solution and adds kludges in mainstream kernel (you can track lkml archives if you forgot non-executable stack discussions). Your fix is MUCH less intrusive and thus more acceptable still it's in the same league.
> Explain.
See above.
> Mind you that I have voting membership in the body that writes the > standards, please do not tell me I am wrong with the standards.
If you can damage your drive via HDIO_DRIVE_CMD then IDE standard is just stupid - we knew it for long time anyway so it's not something new and/or exciting. It can not be fixed with fitering in kernel, though.
> ftp://fission.dt.wdc.com/pub/standards/x3t13/meetings/e00130r0.pdf
> 3.2 Attendance > Rob Schram Absolute Software O > Ron Roberts Adaptec Corp. P > Larry Barras Apple Computer Inc. P > Andre Hedrick Atipa Linux Solutions P <<<< > Raymond Liu CMD Technology P > Amy Barton Circuit Assembly Corp. P > Jeff Wolford Compaq G > Hale Landis Consultant P > Tom Colligan Dell Computer P > Matt Rooke Fujitsu Comp Prod of America P > Hitoshi Ogawa Hitachi Ltd. O > Paul Anderson IBM P > Michael Eschmann Intel G > .............
> *Operating under the procedures of The American National Standards Institute. page 3 > NCITS Secretariat: Information Technology Industries Council (ITI) > 1250 Eye Street, N.W., Suite 200, Washington, DC 20005-3922; Fax: (202) > 638-4922 Tel: (202) 737-8888
> 12.9 Withdrawing ATA-2 [McLean] > Pete McLean reported that the ATA-2 standard was coming up for 5-year > review, and, because it was so out of date and since 8-bit transfers in > ATA/ATAPI-5, he proposed that it be withdrawn.
> ......... > Paul Anderson IBM P Y > Larry Barras Apple Computer Inc. P Y > Aaron Wilson ST Microelectronics P Y > Andre Hedrick Atipa Linux Solutions P Y <<<< > Robert Griswold Microsoft Inc. P X
> Now...
> Andre Hedrick > The Linux ATA/IDE guy
> - > 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/
- 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/
| |