Notes on Singularity

I have just noticed a paper on Microsoft’s Singularity. These are some notes as I read. Their ‘Software-Isolated Process’ is the first construct to be examined. It is some virtual memory together with several ‘threads’ with a ‘security identity’ and ‘associated OS security attributes’. SIPs relate to SIPs via messages thru ‘channels’.

I sense a design impulse to proscribe dangerous patterns such as insecure languages. This can help make programs less ‘vulnerable to themselves’. This is good perhaps but Keykos concentrated on avoiding patterns that made programs vulnerable to other programs; less of a ‘nanny state’ and more of a ‘protection state’. Error prone patterns are to be avoided at some cost but this issue should be separated out, I think.

Quote: SIPs are isolated by software verification. This is a difficult plan but perhaps possible. It seems non-orthogonal to issues of protection of machine level code.

I see at this point three good ideas:

Hardware enforced separation
Denial of error prone patterns
- SIPs do share writable memory
- No ioctl
- Type safe languages
- As a sealed process, a SIP cannot dynamically load or generate code into itself.
Software verification

They may all contribute to the goals of Singularity but they are distinct disciplines with out much synergy, I think. I think that Keykos looses nothing by concentrating on Hardware enforced separation at the bottom. Software verification and avoiding error prone patterns can help even more when applied used in a Keykos environment.

Singularity imposes limitations on SIPs which preclude dangerous patterns, but only to the end of making the functions provided in those SIPs more reliable. Keykos applications are perfectly free to adopt similar stratagems when that is the cost effective tradeoff.

The two following quotes seem to contradict each other:

Associated with a SIP is a set of memory pages containing code and data.
- SIPs are isolated by software verification, not hardware protection
- They (SIPs) cannot share writable memory with other SIPs
- SIPs rely on programming language type and memory safety for isolation, instead of memory management hardware.

“A linear type system and a special area of memory known as the exchange heap allows lightweight exchange of even very large amounts of data, but no sharing.” I presume they are referring to the type notions of linear Janus in which exclusive access to memory is passed about.

“Context switches between SIPs also have very low overhead as TLBs and virtually addressed caches need not be flushed.” This is about the x68 privileged architecture. The several machines that Keykos ran on did not require flushing the TLB upon address space switch.