lkml.org 
[lkml]   [2000]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Direct access to hardware
On Tue, 25 Jul 2000, James Sutherland wrote:

> On Tue, 25 Jul 2000, Stephen Frost wrote:
> >
> > Not that it really matter much, both lead to the dark side and loads
> > of cruft that will never be cleaned out, even once the hardware is fixed and
> > such filtering of 'invalid' commands with 'invalid' data, or valid commands
> > with 'invalid' data is useless.
>
> Simply block all the non-ATA commands. These should never be issued by
> anything other than a vendor diagnostics program - and if you're running
> one of those, WTF are you doing in a multi-user desktop/server OS at the
> time? The commands in question are very specialised and rare. The
> manufacturer could just supply a boot image on their WWW site, containing
> a simple OS (FreeDOS, cut down Linux, whatever) plus their utility.

It's not non-ATA commands, it's using a raw interface provided by
the spec to send commands to the drive not in the spec. At least that's
what I understand from what's been bouncing back and forth and what Andre's
said.
Perhaps I'm wrong, but I don't really see that it matters. The
patch to 'fix' this was rather large and in the end has no *real* net
effect. Hitting this by accident is an *extremely* rare case (having not
ever been noted before) and if a root personage wants to do it, this isn't
going to stop them, even a little bit. So what does it get us in the end?
Just more cruft in the kernel.

Stephen


-
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:1.462 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site