Cage the bugs -- can be implemented something similar in JNode architecture ?????

read this :

In monolithic operating systems, device drivers reside in the kernel. This means that when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. A single bad line of code in a driver can bring down the system. This design is fundamentally flawed. In MINIX 3, each device driver is a separate user-mode process. As a consequence, bugs in a driver cannot spread easily to other parts of the system because each driver process is encapsulated by the MMU hardware.

url ----> http://www.minix3.org/reliability.html

Cage the bugs -- CAN BE IMPLEMENTED SOMETHING SIMILAR IN JNODE ARCHITECTURE ?????

SORRY BY MY ENGLISH :-|

most protections are part of the java platform and JNode

Most of the protection are part of the java platform and of JNode :

- the AccessController can control each call to a method (if that method is doing the control itself). So, if that method is dangerous (formating a harddrive for example), it can check that the call hierarchy (by inspecting the stacktrace) has the right to do that.

- the drivers are fully implemented in java, so they inherits from the java security

- the buffer underrun/overflow can't happen in java since the VM will throw the appropriate exception instead

- the access to native code is not allowed (that's a choice we made) : so, it's probably impossible to run assembler code from JNode.

The only interesting point in the article is the one about infinite loops. For now, that can happen in JNode. But, we can also implement the algorithm explained there to avoid such things.

Another interesting point is the restart of drivers (but we may also apply that to applications) when they are blocked (maybe some deadlocks). We should probably think about that for JNode.

Fabien

my blog (in english and french)

thanks Fabien

thats true
i only post this , with the best intention to contribute al less with sugerences