Re: Reliability of RPC services

[Marcus Brinkmann]

At Thu, 27 Apr 2006 08:51:26 -0600,
"Christopher Nelson" <address@hidden> wrote:
> >However, 
> > in limited cases, where it is well known that there is no 
> > danger (such as in the case of the USB bus) 
> 
> I have never written a USB stack.  Has anyone involved in this
> conversation ever done so?  I've read the docs and I have a reasonable
> understanding of the interface, but before someone goes around saying
> that it's well-known to be secure and totally possible, it would be a
> good idea to sit down and actually work out a design and prototype
> implementation.  As far as I'm aware, no one has ever done this, or
> tried to do this, so I certainly don't think that anyone can say it's
> "well known."  It may be commonly theorized, but that's a different
> story altogether.

Yes, it first needs to be established as a fact before such a decision
can be made.  Insofar all arguments in favor for user-drivers have
been speculative.

> I can see that there are cases where you might want to allow known okay
> devices connect without authorization.  In essences, those devices would
> be pre-authorized.  For example, USB Mass Storage interface.  That's a
> well-known, common interface.  Please present me with a practical usage
> scenario that requires your model.  

Smart card readers, for one thing.
 
> > A system where all device 
> > drivers must be considered trusted is actually *less* secure, 
> > since a flaw in any device driver can potentially be used be 
> > untrusted programs to gain control over the entire system. 
> 
> I don't see how your model increases security.  You still have to have
> "trusted" drivers.  You still can have a bug in them, and it can still
> be used.  Your model allows for user drivers in *very specific cases*.

I think if it would allow only for USB, that would already be useful.

> You are additionally complicating their code with a lot of security
> checks.

That's speculative at this point.  Either the hardware allows this in
a straightforward manner or not.  I would only go for such a model if
it is "obviously safe".

> As complexity increases, confidence in it's security decreases.
> That's one of the reasons that Shap et al. want to make Coyotos servers
> extremely simple, and to keep them single threaded where at all
> possible.
>
> How does having a separate security layer, whose only purpose is to
> provide security and filtering, make the system less secure?

It's not that clear cut.  Putting the drivers into the system code
also introduces a lot of possible fault scenarios: The system could be
wrongly configured.  There is more software now running in the system
domain, increasing the number of bugs.  Especially for individual
(exotic?) device drivers, which are probably not well tested or
reviewed.

> > The proposed model limits such potential weak points to the 
> > bus drivers themselves (including e.g. PCI drivers which can 
> > become bus controllers). 
> 
> This is simply untrue.  Any driver which has access to a piece of
> hardware that accesses physical memory cannot be limited to it's own
> address space.  Therefore, bugs in any driver that may use DMA or (for
> example, a video card that reads and writes to memory) can propagate
> outside it's process boundary.  A microkernel does not and cannot stop
> such propagation errors.

Programmable MMU on IO controllers come to the rescue (eventually).

Hermann Haertig posed an interesting question once to somebody working
on verification: Based on the kernel interfaces and the machine
specification, prove that no code except the kernel can run in ring 0.
This is a surprisingly challenging problem, user device drivers or not
:)

Thanks,
MArcus