Rob Thorpe (robert.thorpe@antenova.com) on 5/17/06 wrote:
---------------------------
>>But seriously, that seems like overkill. Any trustworthy compiler for a type-safe
>>language will do the trick. They just have to accept (well typed) pointers to the
>>objects they reference. And I/O ports are mostly ignorable - since essentially
>>nothing that's performance critical uses them, you can provide access though an
>>(checked) API (at least on platforms that actually support I/O port instructions
>>- implementations that fake PCI ports with memory mappings are obviously in the original scenario).
>
>I don't think that could quite work.
>Lets say a device has a region of memory it uses to communicate with the it's driver.
>The data in the region is to the language using it untyped, it must be cast into
>the correct types. e.g. The driver knows that at memory address 56a3fb21 is a struct
>something_t. This is why I was proposing some method for loosening checking, for a restricted range of memory.
>
>There are two different thing to think about here though:-
>* The correctness of types
>* Whether the driver can steamroller other code
>
>Even with perfectly checked and verified types it's still possible to address completely
>the wrong things, write to the wrong places etc.


You just need a polymorphic type with limit checking. Or just the ability to pass in a safe array of chars, and force the driver writer to access that only byte-wise (nah, we can be more generous than that). Obviously if the size is fixed at compile time (for example, something pointing into I/O space), then the compiler will probably have a good shot at optimizing the limit checks. A variable length area (for example a data area passed from an application) will always require run time checks.

So long as the language provide no escapes for the programmer to directly manipulate pointers, or to address outside the bounds of the defined types, then assuming the compiler is at least moderately trustworthy, then you've pretty much established the protection domain everyone wants from microkernels.

None of this requires anything new in terms of languages. Of the languages suitable for writing low-level code, Ada and some of the languages in the Modula family fit the bill (others too). Note that most of those provide a mechanism to defeat the type system (somewhere in the OS that's going to have to happen), but it's usually a very explicit sort of thing that wouldn't be hard to disable. In several implementations the unsafe stuff has to be enabled explicitly (eg. a command line switch on the compile, or the library that implements the type-system-defeat function has to be linked).

On the flip side the disk driver that turns "write to sector 37" into "write to sector 123" will screw up everyone.