Linked by Thom Holwerda on Fri 22nd Feb 2008 09:16 UTC, submitted by obsethryl

Thread beginning with comment 302000
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Using a Managed Language, you can verify your assemblies and essentially guarantee it will never spill over into another process.
Additionally, if that's not enough (At least in Singularity) you can selectively isolate the processes in Hardware as well.
Additionally, if that's not enough (At least in Singularity) you can selectively isolate the processes in Hardware as well.
That is one thing I dislike about singularity. A great part of the attraction of an OS using software isolated processes is its simplicity. The only security-critical part of such an OS is the MSIL->native JIT/AOT compiler.
If you provide an additional mode of process isolation, a large part of that simplicity goes out of the window. But microsoft never got the whole KISS approach anyway. Just look at the bloat in the C# language specification.
Well, it's to take into account that humans make mistakes and therefore the Software Isolation could be compromised in theory.
Not that it's at all likely, but even for things that don't conform to the philosophies of managed code (Sandboxing Native code using a VM for example), this is a very good compromise.
That way you can run "Trusted" applications using only a SIP, and untrusted or native applications using a SIP with additional hardware protection.
I think it would work if used sparingly, but that remains to be seen.
Member since:
2005-11-29
Using a Managed Language, you can verify your assemblies and essentially guarantee it will never spill over into another process.
Additionally, if that's not enough (At least in Singularity) you can selectively isolate the processes in Hardware as well.
But really, it's all about zero-copy process communication and ease of development.