Hi, (Please, no direct answer, I'm on the list.)
On Tue, Nov 14, 2006 at 12:10:07PM +0100, [EMAIL PROTECTED] wrote: > hi, > > On Tue, Nov 14, 2006 at 10:44:41AM +0100, Christian Helmuth wrote: > > > IMO the required capabalities for a driver to work can be derived from > > the I/O resource and device structure. So devices attached to buses > > are dominated by the bus drivers (which may be dominated by host > > drivers or bus drivers again, e.g. PCI - USB - USB device). This > > requires more trust into bus drivers than into drivers for the > > attached devices, but could help to design a trusted driver tree. > > Opinions? > > This works for some busses, but not all. Which busses are you talking about? Could you be a bit more specific here? > Also, it solves only part of the problem -- the driver is limited to the > registers belonging to the actual device, but the device itself can > often be programmed to acces system resources in an uncontrolled manner > (e.g. through DMA). Solutions to the DMA problem are in the pipe, e.g. intel VT-d. Regarding other issues with device capabilities circumventing security mechanisms IMO make these device obsolete. BTW: I answered to Tom's statement: > How would you expect that to work? The problem, as you stated above, is > _not_ that we cannot limit what the driver is allowed to do, but that we > have to believe it that it really needs the capabilities it asked for. Ciao -- Christian Helmuth TU Dresden, Dept. of CS Operating Systems Group http://os.inf.tu-dresden.de/~ch12 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
