Messages in this thread |  | | | Date | Sun, 23 Jul 2000 18:22:48 +0200 | | Subject | Re: TO HELL WITH IT THEN......(re: disk-destroyer.c) | | From | Andreas Bombe <> |
| |
On Fri, Jul 21, 2000 at 11:43:15AM -0700, Andre Hedrick wrote: > > If you try to pass raw taskfile command to the drive and you have no clue. > The hardware will BUCK 99% of the time. > > Using the kernel IOCTL, it BUCKS 5% of the time and the damage is done. > Baically, you want me to continue helping you destroy your hardware. > I will not be a part of that! > > Do you allow USB to send unrestricted commands that will damage the > hardware?
Let's have a different example: IEEE 1394, aka FireWire. The subsystem provides the raw1394 module, which does allow to send raw (mostly, see below) packets to any node on the bus. This may include disks, which may have dangerous commands.
A short overview of 1394. This standard is an implementation of IEEE 1212 (CSR architecture), and as such it implements only (ignoring isochronous transmissions, which do only data and no commands anyway) three basic commands: read, write, lock (lock does some indivisable operations). The whole architecture is memory based, commands are not implemented by special transaction codes but by memory registers with specified side effects on read/lock/write.
raw1394 does not actually allow to create real raw packets, it creates the packets itself from requests like "write address x on node y with data z" (necessary, since the kernel has to handle the responses).
Every node has an address space of 256 TB (48 Bit address).
We can't filter by command here, since we only see addresses. How would you filter *that*? Addresses may be specified by standards or be vendor extensions. Which addresses do we allow, which do we reject? Should we download and parse the configuration ROM of the target node to find out what kind of device it is in the first place (i.e. this address is only to be allowed on digital video devices)? Since address ranges exist that serve as reception space for complete commands, should we examine the data to be sent if the target address matches this?
How can the kernel know what is right and what is wrong? How is this situation different from IDE or SCSI? Should the raw1394 driver be wiped entirely and complete kernel drivers required for every little digital camera device?
This reminds me that I should put a CAP_SYS_RAWIO check into raw1394.
-- Andreas E. Bombe <andreas.bombe@munich.netsurf.de> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/
- 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/
|  |