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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:20 EST