John Nagle nagle@animats.com writes:
Once I/O flexpages are in, RMGR will be able to issue access to device space byte by byte.
That's right.
It can connect up interrupts to drivers now.
Small correction: L4 currently has no interface for safely passing an interrupt assignment. All Rmgr can do when a driver asks for an interrupt is release its attachment so that the driver can attach. This opens a time window for a malicious process racing with the driver to steal the attachment.
The remaining big security problem is DMA.
Of course, DMA will be restricted to processes having access to the ports controlling the DMA controller.
In most systems, device drivers are given total access to DMA controllers. Could that be avoided, with a trusted process that handles the DMA controllers at the request of the device drivers?
I'm going to concentrate on PCI bus issues, since ISA is on the way out and SCSI, USB, and IEEE-1394 devices usually work through a PCI controller.
For most devices, DMA is performed by DMA controllers in the core chipset (such as the Intel 82810), not by the peripherals themselves. It's seems to be possible to disable the ability of a PCI device to become a bus master without disabling the ability of the DMA controllers to execute memory and PCI bus cycles, at least with the more modern core chipsets.
So it ought to be possible to have a trusted process that handles DMA and deals with the memory mapping issues. This process would be used by device drivers that need DMA. Drivers would not have access to the DMA controllers directly and would be untrusted.
Yes, all that is correct. A different solution would be to simply trust device drivers also.
There's the related issue of hardware discovery, or "plug and play". Something is needed at startup to discover all the hardware, build the hardware tree, and parcel out hardware resources to drivers. What's planned in that area?
We plan to do all this in a device-managing component.
As a start, Uwe Dannowski already has added some enhancements to Rmgr that discovers PCI devices and remaps their memory-mapped I/O ports so that only one device has ports in a given high-memory superpage, enabling access control to memory-mapped I/O ports for device drivers. However, I think his changes are currently not available publicly. :(
Other than that, not much has been done so far in this area. All drivers currently contain their own PCI-device-discovery code.
Is this consistent with the thinking of the L4/Fiasco/Drops groups? If not, is there something wrong here?
I think you ate pretty much inline with our thinking.
Regards, Michael