On Wednesday 26 April 2006 19:55, Jonathan S. Shapiro wrote: > > It's actually a fairly limited set of devices. It doesn't include, for > > example, USB or IEEE-1394 devices (even if they happen to be accessed > > through a PCI controller), or (probably) ATA devices (it depends on the > > ATA protocol). > > Jesse: > > If you believe that, you need to go read the respective specifications > more carefully. USB and IEEE-1394 *definitely* allow remote devices to > be masters. ATA is more SCSI-like every day. I haven't checked, but I > bet that ATA allows it too. In fact, I'm pretty sure I remember > disconnected operations in ATA-6, which amounts to the same thing. > > shap
Back when I read the USB spec (USB 1.0, just for reference) there didn't appear to be any support for direct device-to-device transfers. All transfers were performed between the device and the host, and were typically initiated by the host as well. There were USB "master" and "slave" devices, but these terms refered to the USB host and USB device ports, not DMA/bus mastering, which is the issue with PCI devices, and the USB "master" was always the PC, not the removable device (except for USB hubs). In no case was the PC the USB "slave". Of course, they may have changed that with USB 1.1 or 2.0. There could be an issue with ATA, which is why I said it depends on the specifics of the protocol. Still, ATA at least *has* a protocol, and thus there is no particular reason why the trusted driver couldn't specify which commands untrusted drivers could send. I've never read the IEEE-1394 spec, so I'll leave that one alone. Regardless of all this, if (as you say) USB and ATA devices can become bus masters (according to the specs[1]), then no amount of software constraints will protect your systems from anyone with a hostile removable device. In such a system it would be relatively trivial to design a USB/FireWire/ATA device which could compromise a system without even requiring a device driver to be loaded. Just plug it in and your system RAM or HDD boot sector is instantly overwritten with malicious code through a device-initiated DMA transfer. To summarize: A user-installed device capable of bus mastering is *equivalent* to fully-trusted user-supplied software, in that both the device and the trusted software are capable of gaining complete control over the system. The only case where it would actually matter whether the device driver was loaded by the user or an administrator would be where the user did not install the device, or where the bus protocols are secure. The former does not appear particularly useful; that latter is something that we may or may not have at present, but which we will probably have at some point in the future as software security improves and more people find out just how insecure the hardware architecture really is. Whatever system we design should be capable of taking advantage of those improvements in hardware security (which could, for the most part, be implemented without breaking existing device interfaces). [1] Technically, there is no guarantee that external devices will conform to the specs for the bus they connect to, and thus *no* device can be assumed to be safe, regardless of the software in use. The only way to eliminate /that/ problem would be to completely eliminate physical access to the systems, including wrapping the system in a Faraday cage and providing isolated I/O and power lines. We're apparently assuming that the risk does justify that kind of expense in this case.
pgp7o8EUmi0E9.pgp
Description: PGP signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
