On Sat, Jul 22, 2000 at 08:28:26PM -0700, H. Peter Anvin wrote:
> A rogue driver can always do this by writing straight to the
> interface. I think a more serious issue is: what about a *buggy*
> drivers? However, what I am a bit unclear of is the following: will
> this patch prevent me from writing a driver which issues legitimate
> vendor-specific commands to control vendor-specific aspects of a
> particular piece of hardware? If so, that would be a very bad thing.
> However, if this patch is there to prevent buggy programs from issuing
> known-to-be-damaging commands by accient, then that is a Good
> Thing[TM].
The original Andre's patch was about 60k in size, and added code that
gone to great lengths (I still don't understand why it was *that*
complicated, I think it was changing quite a bit of unrelated stuff
Andre wasn't speaking about, too) to pass only the
absolutely-sure-to-be-completely-safe commands (only read & get info,
one set config command) to the drive from userland.
This of course doesn't prevent anyone from doing anything with the drive
from kernel, or from userland using direct access.
It also removed the possibility to use the possibly-dangerous-but-useful
sort of commands from userland in a clean way using the ioctl.
> I personally would have to agree with the people that say this isn't a
> security issue, but I *do* believe that protecting buggy programs (we
> never have any of those, right?) from causing permanent damage to the
> hardware is a very useful thing.
Actually the chances that a buggy program gone wild will by accident
open /dev/hda and trigger this exact ioctl with the command data set so
that it'd damage the drive is about the same that it'll write a poem on
the screen in quenya language in the same situation.
The chances aren't much less with the original protection patch
installed, either.
For programs actually using this ioctl interface (hdparm, smartd ...)
the possibility of doing damage by misfunctioning is of course greater,
but you can kill some drives using hdparm even with just the
considered-harmless commands.
-- Vojtech Pavlik SuSE Labs- 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 : Sun Jul 23 2000 - 21:00:20 EST