> The reason ATA and SCSI were mentioned is that this doesn't > work for cardbus (which I also mentioned). This is because > appearantly cardbus cards can do their own DMA accesses, > which means they can take over the entire system. In fact, > it means they can do so without being asked, which is a > design bug IMO (it means that I can build a cardbus card > which takes over any computer I plug it in, irrespective of > the OS it's running. Well, unless they cut the power to the > bus, I suppose. :-) ).
Many ATA and SCSI controllers also have the ability to do DMA transfers. As do sound cards and video cards. > > If you want block-level access, then what you want is a custom > > filesystem-like API. That's all a filesystem is, really, > an interface > > to some block device. > > Filesystems are just one case which is useful for certain > devices (such as a memory stick). Others (such as a usb > sound card) need other interfaces. All this is very well > possible with a bus driver acting as a proxy. > Programming sound, video, etc all require register-level access. Let me use the example of the Intel 80810 chipset. This is a PCI controller with a disk controller, hardware accelerated video card, and some other junk attached. Now, the chipset will emulate an ATA bus, but you can also drive it straight from the PCI bus. The same is true with the video card: you may access the legacy VGA registers, or map the PCI into memory and drive it that way. The point is that the "bus driver" would have to be absolutely specific to that chipset. A generic PCI driver (which works quite well with the i80810) wouldn't know what the heck was going on, so it would allow someone to both map the PCI drive controller, and also the "legacy" ATA interface. It could not conceivably protect the devices because it does not know enough to do so. In other words, it puts a huge burden on driver developers because they then have to worry about a security framework as well as a stable hardware/software interface. IMHO, security is not the domain of drivers. It is the domain of the kernel together with software that is designed for that purpose. Other layers in the system should worry about security. While I completely agree that there should be some facility to give users access to devices, especially hotplug devices, without having to be root or have root give them access, I do not feel that the driver level is the place to do it. > > > > BTW: your MUA is broken, adding some illegal headers > about threads > > > but not the standards one, thus breaking threads, at least in my > > > MUA, which is not very comfortable in such ramified discussions... > > > > I use Outlook, sorry. > > Huh? I thought you cared about security.... *confused* You don't always get to choose your software. We run Windows, for a variety of reasons, on both desktop and server. We also use Exchange, for a variety of reasons. The only client that really performs well with Exchange is Outlook. Since we also use Office, it makes sense for us to use Outlook. I could run multiple mail clients, but that would be silly. More recent version of Outlook (ie. 2003) are more secure, and you can edit various system policies to make them even more secure. We also plug a system into the Exchange server that filters all mail before it ever gets to a user's account. So, while it's not perfect, it is as secure as it can be while still providing reasonable flexibility. In fact, we haven't had any e-mail born issues for a couple of years now. Our problem now is people installing rogue apps that wipe out their profiles or get hooked into explorer. You don't have to be an admin to shoot yourself in the foot. _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
