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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:19 EST