lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.114 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site