OSDev.org

MessiahAndrw wrote:I've taken a recent liking to the idea of software isolation over hardware, that is, only execute bytecode that is JITed into machine code at runtime and use the JITer to ensure 'unsafe' code (such as pointer manipulation) isn't allowed.

gravaera wrote:I personally would like to discourage you from filtering out any pointer arithmetic, or other 'unsafe practices' which are not by themselves able to place the system in an unsafe state

gravaera wrote:(If it is possible to really filter bytecode that efficiently with a decent performance throughput).

gravaera wrote:Please take into consideration the purpose of an OS: To provide a consistent software environment so that applications of any type which the hardware platform is capable of supporting would be able to run without having to concern themselves with the state of the environment.

MessiahAndrw wrote:You'd be able to pass strings as parameters which exist in another address space without having to copy, you can pass a reference to a very large array around (such as audio/video data), and with reference counting you need not worry if the sending process died because the memory will still be accessible until everything has released it. But above basic inbuilt types I'm stuck

MessiahAndrw wrote:More problems come in when I'm dealing with virtual functions. For example, if I share a type which has overloaded a function, but that function exists within another program, then that program dies. One solution is to store a list of every place referring to that function and when the process dies replace every instance with a reference to a null function that throws an exception.

• Don't use JIT if you don't plan to support dynamic loading. Disallowing dynamic loading is one of the ways you ensure that processes are "safe". Instead of JIT, compile the app to native code at install time.
• Singularity does not force processes to share the same garbage collection system. Each can have its own, and the kernel has its own.
• IPC messages in Singularity must be allocated from a special heap called the Exchange heap. Every value in the Exchange heap must be of an "exchangeable type", which is either a primitive type or a struct composed of fields of exchangeable types. It's kind of annoying because processes may need to do marshaling to and from the messages, depending on what they're trying to achieve. On the other hand, it's necessary to ensure that the garbage collectors of communicating processes don't need to co-ordinate with one another.
• Type safety of IPC is enforced through the use of strongly-typed "channel contracts" which dictate not only the types of messages that can be sent, but also the sequence in which they can be sent (a kind of simplified protocol state machine). The two processes on either end of a channel must share the same definition of the channel contract, and the kernel enforces this.
• "Overloaded" names can't really be confused in a .NET-based system... Every type visible to more than one process is identified by a "strong name" which includes the assembly-qualified type name, full version number, and public key token.

• Software isolation doesn't protect you from memory corruption caused by hardware failures. MMUs aren't perfect either, but mitigate this risk better.
• IPC without switching to the kernel is possible, if it's cross-CPU IPC. Take a look at Barrelfish. In the not-so-distant future, we'll be running on machines with dozens or even hundreds of cores. That's more than enough parallelism to keep many of those cores dedicated to running some key processes most of the time. Context switching on one core could become a lot less frequent than sending messages to other cores. In this kind of system, having fast topology-aware user-level IPC will be much more important than single-core context switching speed.

Colonel Kernel wrote:

• IPC messages in Singularity must be allocated from a special heap called the Exchange heap. Every value in the Exchange heap must be of an "exchangeable type", which is either a primitive type or a struct composed of fields of exchangeable types. It's kind of annoying because processes may need to do marshaling to and from the messages, depending on what they're trying to achieve. On the other hand, it's necessary to ensure that the garbage collectors of communicating processes don't need to co-ordinate with one another.

interface VirtualFileSystem
{
  // no need to check if 'array' is big enough, because if an out of bounds exception occurs it occurs in the thread calling this (the application)
   bool ReadFile(File file, uint offset, uint bytes, ref byte[] array);
}

Colonel Kernel wrote:In your ReadFile example, how would you prevent one process from modifying the other process' buffer? Without that guarantee, you don't have software isolation.

MessiahAndrw wrote:

Colonel Kernel wrote:In your ReadFile example, how would you prevent one process from modifying the other process' buffer? Without that guarantee, you don't have software isolation.

Just like in Singularity, pointers aren't allowed in 'safe' code, only references, which suits servers and applications programs fine. A program is only allowed to modify another process's buffer if that buffer has been passed to that program via a shared interface.