SharpOS in the Stream of C# Kernels
Linked by Thom Holwerda on Fri 22nd Feb 2008 09:16 UTC, submitted by obsethryl
.NET (dotGNU too) "Previously, we have presented one of the two opensource licensed projects related to creating a C# kernel. Now it's the time to complete the set by rightfully presenting SharpOS, an effort to build a GPL version 3 + runtime exception licensed system, around a C# kernel of their own design. It is my pleasure and priviledge to host a set of questions and answers from four active developers of SharpOS, that is William Lahti, Bruce Markham, Mircea - Cristian Racasan and Sander van Rossen in order to get some insight into what they are doing with SharpOS, their goals, their different design and inspiration."
E-mail Print r 1   29 Comment(s) http://osne.ws/ey5
Permalink for comment 302015
To read all comments associated with this story, please click here.
RE[5]: advantages
by tuttle on Fri 22nd Feb 2008 18:05 UTC in reply to "RE[4]: advantages"
tuttle
Member since:
2006-03-01

Well, it's to take into account that humans make mistakes and therefore the Software Isolation could be compromised in theory.


Correct. But hardware isolation can also be compromised in theory. Sometimes there is a bug in a CPU that lets a user level process gain access to privileged instructions. An operating system using pure software isolated processes would not be affected by such CPU bugs.

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.


I agree that for practical usability there needs to be some way to run traditional hardware isolated processes. But that should be done in some kind of compatibility layer to avoid bloating the core OS.

Maybe run the new OS and the old processes side by side using some kind of supervisor. But do not compromise the design of the new OS for backward compatibility!

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.


If it is used sparingly, there is no need to compromise the core OS. Running a legacy OS side by side to the new SIP OS under some kind of supervisor would have some overhead when communicating between new and old processes, but I would gladly accept that penalty for a clean and minimalistic design.

Reply Parent Score: 1