[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Question to throw at you guys

From: Richard Braun
Subject: Re: A Question to throw at you guys
Date: Mon, 13 Nov 2006 21:18:00 +0100
User-agent: Mutt/1.5.9i

On Sun, Nov 12, 2006 at 10:57:32PM +0000, Justin Emmanuel wrote:
> The concept goes something like this. I don't want people writing code that
> runs directly against my hardware. They can make mistakes; they can put in
> bugs, maybe they generally just a security risk and try to access things
> that have nothing to do with the device that they are meant to.

This is hard to achieve. Let's study a simple example : DMA. DMA chips
have access to memory, so any driver using those could create bugs.
Moreover, it would imply that something else than drivers must know what
can and cannot be done. But it's the job of a driver to know such things
(concerning hardware at least). Not even considering the impact on
performance, I'd say that drivers must be part of the TCB, and thus
always more or less imply security risks.

> What if a DDL (Driver Description Language) framework could be devised that
> was easy to learn and write for? Included modern mechanisms to capture
> programming errors. Was only allowed to be linked to the device that it was
> to be operating.

How do you make sure that a description only handles the one device
it must operate ? This knowledge is in the driver itself, the kernel
can't know it.

> Having never written a driver myself, I don't know if this is a complete
> load of baloney. So, I will throw it out to you guys. I am interested in
> what you guys think. Is this possible? Has anyone ever done any work on it?

There are two parts in your suggestions. First you suggest using drivers
in userspace, isolated from the kernel (that's the "don't trust drivers"
part). Next, you suggest a specialized language towards driver creation.

From my point of view, I don't see a way to reliably achieve the first
part, as hardware devices can be considered as most privileged entities,
potentially giving less privileged entities (device drivers) access to
most privileged data.

A common language for driver development could be nice, but at compile
time only. It would include many problems to solve such as hierarchies
of drivers : think of a chip that can be used on a PCI bus, or as a PCMCIA
card; your driver would need some abstractions to use these buses, which
are themselves drivers. USB is a relevant example too. Portability could
be achieved with a "root bus" from the kernel (or the system I'd say),
providing low level abstractions (I/O mapped memory, I/O address spaces,

However, as drivers interact deeply with core system elements
(e.g. interrupts, locking, resource managment, scheduling, etc...), and
because these elements have varying implementations which can greatly
affect the behaviour of a driver, I don't think portability can be
achieved. It would require all compliant systems to provide a large
interface, possibly including several implementations of the same
functionnality (e.g. locks implemented as spin locks, mutexes or
semaphores). This would simply be the same as having drivers written
in C with systems providing the same interface to them, except that you
need a new compiler. This is more or less the idea of glue code, except
that the interface would be designed to be easy to provide, i.e. it would
not force drivers to rely on the presence of some core data structures,
like Linux drivers using mem_map, a big flat array of struct page objects,
which most OSes, GNU Mach included, can't reproduce or emulate because
they already have such a table (with a different format), and it would be
nonsense to create a second, just for compatibility with the interface.

I think it would be better to think of such an interface instead. We
already have languages that are appropriate enough for driver development.
But that's only my opinion :-).

Richard Braun

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]