Re: Reliability of RPC services

[Bas Wijnen]

On Wed, Apr 26, 2006 at 12:40:53PM -0600, Christopher Nelson wrote:
> > 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.

The sound and video cards you mean are PCI (or AGP) devices.  It is clear that
user-provided drivers are not possible for PCI devices.

The point is you only give access to devices that the user should be able to
access.  In case of PCI (and appearantly cardbus), giving access to one device
on the bus is not possible (because the device may be able to do uncontrolled
(because the bus doesn't recognise the commands) DMA, effectively compromising
the whole computer).  So for those busses, user-provided drivers are not
possible.  However, AFAIUI, ATA and SCSI don't use random codes to initiate
DMA, therefore the bus driver will know when a command is starting a DMA
operation (and it can refuse to perform it for that reason).  This property
means that devices on such a bus _can_ be driven with a user-provided,
untrusted, driver.

For busses where the device itself cannot do much at all, such as usb (the
device only talks to the controller, the controller talks to the CPU and
possibly does DMA(?)), it is no problem at all to use an untrusted
device-driver.  However, if the usb controller does indeed do DMA, then the
bus driver must be trusted.  If it doesn't, then that too can be provided by
the user.

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

Hold it right there.  I already agreed that PCI things are different, and they
do need trusted drivers.  This is about devices which cannot (because of a
proper bus driver) do any damage to the system.  PCI devices are not in that
category.

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

This is quite irrelevant, I think, because it is still about the PCI bus.
The ATA bus and the VGA controller are both PCI devices, and therefore cannot
be driven with untrusted drivers.  However, an ATA device could, for example,
because (if I understood it correctly) the ATA protocol simply doesn't allow
such "cheating" as you describe above.  It's very clear when a DMA is
performed, for example.

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

Security is arranged through capabilities.  If some interfaces are fragile,
and abuse cannot be prevented, then care must be taken that no capability to
it ends up in untrusted hands.  However, if interfaces can handle abuse (that
is, no problems remain after revoking the capability and perhaps some cleanup
such as resetting the bus), then it is fine to give capabilities to it to the
untrusted parties.  Of course the capabilities should still not be given to
the wrong program, but it makes sense to give them to the session of the user
who logs in.

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

Of course it is.  How else can I use my brand-new
totally-unknown-to-my-system-administrator device?  If it doesn't plug into a
"dangerous" bus (such as cardbus, unfortunately), but into something which can
be kept in control, such as usb, then there's no reason to deny me the ability
to provide my own driver.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature