Singularity: Rethinking the Software Stack
Linked by Thom Holwerda on Wed 27th Jun 2007 18:59 UTC, submitted by John Nilsson
Microsoft The Singularity team at Microsoft has recently published a new article concerning their research OS. It is a concise introduction to the Singularity project. It summarizes research in Singularity 1.0 and highlights ongoing research for Singularity 2.0.
E-mail Print r 0   61 Comment(s) http://osne.ws/e08
Thread beginning with comment 251257
To read all comments associated with this story, please click here.
Software based memory protection?
by ecko on Thu 28th Jun 2007 12:23 UTC
ecko
Member since:
2005-07-08

Maybe I'm missing something but I am not understanding the design reason to use flat memory and software based isolation between processes aside from a performance standpoint. I assume system calls would be faster in a flat memory configuration due to the fact that the cpu no longer needs to switch into ring 0 in system calls. There may also be some CPU time saved by eliminating the need to convert from virtual to physical addresses.

The problem I see, and it's a major problem, is that there is nothing but the MSIL Runtime preventing me from grabbing memory anywhere I want it. The PDF even states that this is possible given a bug in the Sing# runtime. From what it looks like to me, this includes inside the kernel.

If I can write anywhere in the system without triggering hardware exceptions that is IMHO a very bad thing. At least with hardware level protection, user level programs trying to write into system level memory or going to at worst trigger exceptions and get themselves killed. Here, in theory it's possible for a user level program to patch a running kernel.

I know it's just a research project but I find it funny that Microsoft researchers put so much faith in software based protection of the ENTIRE system when they can't even write secure software to begin with. The rest of the industry is moving to MORE hardware based protections (Trusted computing chips anyone) and here we're stepping backwards.

Reply Score: 1

segedunum Member since:
2005-07-06

The rest of the industry is moving to MORE hardware based protections (Trusted computing chips anyone) and here we're stepping backwards.

That's probably what they're counting on in the future - preferably on a system that will only run the IL runtime and Microsoft's new OS.

Reply Parent Score: 2

viton Member since:
2005-08-09

I find it funny that Microsoft researchers put so much faith in software based protection of the ENTIRE system
You can run several isolated OSes under hypervisor.
The OS itself don't need to be hardware protected.
So, the protection offered by verifiable/safe languages is enough.

Edited 2007-06-28 14:21

Reply Parent Score: 1

John Nilsson Member since:
2005-07-06

They rely on static verification. In other words security constraints are a compile time thing (compile time being install time in this case).

Reply Parent Score: 3

Morin Member since:
2005-12-31

> The problem I see, and it's a major problem, is that
> there is nothing but the MSIL Runtime preventing me
> from grabbing memory anywhere I want it. The PDF
> even states that this is possible given a bug in the
> Sing# runtime. From what it looks like to me, this
> includes inside the kernel.

With traditional OSes, the problem, and it's a major problem, is that there is nothing but the hardware protection preventing me from grabbing memory anywhere I want it. Bugs in the hardware protection are going to make the OS vulnerable just as bugs in the MSIL do.

> If I can write anywhere in the system without
> triggering hardware exceptions that is IMHO a very
> bad thing.

Which is why this situation cannot occur, bugs in the MSIL or hardware protection aside. With "managed code" as it is called, there is no sequence of instructions that could write to arbitrary memory locations (due to the unforgeability of arbitrary pointers).

Reply Parent Score: 2