Messages in this thread | | | Date | Tue, 25 Jul 2000 12:12:13 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: 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/
| |