By: rwessel (robertwessel.delete@this.yahoo.com), May 17, 2006 12:33 am
Room: Moderated Discussions
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.
---------------------------
>>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.
Topic | Posted By | Date |
---|---|---|
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 03:41 PM |
Hybrid (micro)kernels | S. Rao | 2006/05/08 05:14 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/08 05:16 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 06:21 PM |
Hybrid (micro)kernels | nick | 2006/05/08 06:50 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 12:26 AM |
There aren't enough words... | Rob Thorpe | 2006/05/09 01:39 AM |
There aren't enough words... | Tzvetan Mikov | 2006/05/09 02:10 PM |
There aren't enough words... | Rob Thorpe | 2006/05/14 11:25 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/09 10:17 AM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 03:05 PM |
Hybrid (micro)kernels | rwessel | 2006/05/08 10:23 PM |
Hybrid kernel, not NT | Richard Urich | 2006/05/09 05:03 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 06:06 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 06:40 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 07:30 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 08:07 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 08:36 AM |
Linux vs MacOSX peformance, debunked | _Arthur | 2006/05/18 06:30 AM |
Linux vs MacOSX peformance, debunked | Rob Thorpe | 2006/05/18 07:19 AM |
Linux vs MacOSX peformance, debunked | Anonymous | 2006/05/18 11:31 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 07:16 AM |
Hybrid kernel, not NT | Andi Kleen | 2006/05/09 01:32 PM |
Hybrid kernel, not NT | myself | 2006/05/09 02:24 PM |
Hybrid kernel, not NT | myself | 2006/05/09 02:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/09 04:26 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 07:06 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 12:35 AM |
Hybrid kernel, not NT | nick | 2006/05/13 03:40 AM |
Hybrid kernel, not NT | Brendan | 2006/05/13 08:48 AM |
Hybrid kernel, not NT | nick | 2006/05/13 06:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 08:51 PM |
Hybrid kernel, not NT | nick | 2006/05/14 04:57 PM |
Hybrid kernel, not NT | Brendan | 2006/05/14 09:40 PM |
Hybrid kernel, not NT | nick | 2006/05/14 10:46 PM |
Hybrid kernel, not NT | Brendan | 2006/05/15 03:00 AM |
Hybrid kernel, not NT | rwessel | 2006/05/15 06:21 AM |
Hybrid kernel, not NT | Brendan | 2006/05/15 07:55 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/15 08:49 AM |
Hybrid kernel, not NT | nick | 2006/05/15 03:41 PM |
Hybrid kernel, not NT | tony roth | 2008/01/31 01:20 PM |
Hybrid kernel, not NT | nick | 2006/05/15 05:33 PM |
Hybrid kernel, not NT | Brendan | 2006/05/16 12:39 AM |
Hybrid kernel, not NT | nick | 2006/05/16 01:53 AM |
Hybrid kernel, not NT | Brendan | 2006/05/16 04:37 AM |
Hybrid kernel, not NT | Anonymous | 2008/05/01 09:31 PM |
Following the structure of the tree | Michael S | 2008/05/02 03:19 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 04:31 AM |
Following the structure of the tree | Michael S | 2008/05/02 05:02 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 05:48 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 08:14 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 09:05 AM |
LOL! | Dean Kent | 2008/05/02 09:33 AM |
Following the structure of the tree | anonymous | 2008/05/02 02:04 PM |
Following the structure of the tree | Dean Kent | 2008/05/02 06:52 PM |
Following the structure of the tree | Foo_ | 2008/05/03 01:01 AM |
Following the structure of the tree | David W. Hess | 2008/05/03 05:54 AM |
Following the structure of the tree | Dean Kent | 2008/05/03 09:06 AM |
Following the structure of the tree | Foo_ | 2008/05/04 12:06 AM |
Following the structure of the tree | Michael S | 2008/05/04 12:22 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 04:19 PM |
Microkernel Vs Monolithic Kernel | Kernel_Protector | 2006/05/09 08:41 PM |
Microkernel Vs Monolithic Kernel | David Kanter | 2006/05/09 09:30 PM |
Sigh, Stand back, its slashdotting time. (NT) | Anonymous | 2006/05/09 09:44 PM |
Microkernel Vs Monolithic Kernel | blah | 2006/05/12 07:58 PM |
Microkernel Vs Monolithic Kernel | Rob Thorpe | 2006/05/15 12:41 AM |
Hybrid kernel, not NT | AnalGuy | 2006/05/16 02:10 AM |
Theory versus practice | David Kanter | 2006/05/16 11:55 AM |
Distributed algorithms | Rob Thorpe | 2006/05/16 11:53 PM |
Theory versus practice | Howard Chu | 2006/05/17 01:54 AM |
Theory versus practice | JS | 2006/05/17 03:29 AM |
Play online poker, blackjack !!! | Gamezonex | 2007/08/16 12:49 PM |
Hybrid kernel, not NT (NT) | atle rene mossik | 2020/12/12 08:31 AM |
Hybrid (micro)kernels | philt | 2006/05/14 08:15 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 07:20 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 10:56 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 12:22 AM |
Hybrid (micro)kernels | rwessel | 2006/05/16 10:23 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 11:43 PM |
Hybrid (micro)kernels | rwessel | 2006/05/17 12:33 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/19 06:51 AM |
Hybrid (micro)kernels | rwessel | 2006/05/19 11:27 AM |
Hybrid (micro)kernels | techIperson | 2006/05/15 12:25 PM |
Hybrid (micro)kernels | mas | 2006/05/15 04:17 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 04:39 PM |
Hybrid (micro)kernels | Colonel Kernel | 2006/05/15 08:17 PM |
Hybrid (micro)kernels | Wink Saville | 2006/05/15 09:31 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 09:08 AM |
Hybrid (micro)kernels | Wink Saville | 2006/05/16 08:55 PM |
Hybrid (micro)kernels | rwessel | 2006/05/16 10:31 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 11:00 AM |
Hybrid (micro)kernels | Brendan | 2006/05/16 12:36 AM |
Hybrid (micro)kernels | Paul Elliott | 2006/09/03 07:44 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/09/04 08:25 AM |
Hybrid (micro)kernels | philt | 2006/05/15 11:55 PM |
Hybrid (micro)kernels | pgerassi | 2007/08/16 06:41 PM |
Another questionable entry on Wikipedia? | Chung Leong | 2006/05/18 09:33 AM |
Hybrid (micro)kernels | israel | 2006/05/20 03:25 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/22 07:35 AM |