RE: Reliability of RPC services

[Christopher Nelson]

> 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.