This project is read-only.

About Singularity security

May 14, 2010 at 8:45 AM

Well, Bartok compile a program to native code, but after compiling tresspasser may change this code, isn't it?

Or Singularity have yet another security mechanisms (such as digital signing; I was try to find it, but I don't found) to protect OS from this attempts?

Sorry for (maybe) stupid question.


May 14, 2010 at 4:06 PM

AFAIK the compiled x86 code is stored by the Code Manager. It is difficult to modify the compiled code for two reasons.

First of all, the code is signed after compilation and any changes are easilly detected by the Code Manager. 

Second, how would you want to modify the code? It is stored inside the kernel's object space and you do not have any pointers in code outside of the kernel. You would have to do it from the Hardware Abstraction Layer.

Best Regards,

May 15, 2010 at 5:03 AM

Hmm what is Code Manager? Is it Singularity's part?

It's only mention about one I found in mkmsil code  in file PELoader.cs.


And for second reason, it maybe use for DoS attack because any application runs in ring0. It means that malicious program may use the privileged instructions, such as cli.

May 15, 2010 at 11:01 PM

This is what I found in the documentation.

In "Broad New OS Research: Challenges and Opportunities":

MSIL binaries may be translated into hardware instruction streams at load or install time based on metadata in the application manifest. Caching of hardware instruction streams is invisible to both applications and users. ... Code translators reside in processes outside the kernel and convert MSIL into verified hardware instruction streams. The loader caches hardware instruction streams and maps them into processes. The memory manager includes the GC and its accompanying facilities such as the GC write barrier. The metadata manager acts as a repository for traditional CLI code metadata, such as type information required for garbage collection. The metadata manager also coordinates information related to the application abstraction and application manifests.

In "Solving the Starting Problem: Device Drivers as Self-Describing Artifacts":

If all system-specified tests succeed, we compile the entire set of assemblies into a single, statically-linked, native-instruction executable using the Bartok optimizing compiler [19]. The name of this executable and a suitable path are added as code properties in the application tree of the manifest. Following this step, we generate the signature tree that enables the system to verify that the application has not been modified, according to the system’s security policy. Following this process, the manifest is placed in its distinguished location in the system namespace, and the executable is stored in the namespace according to the path attribute.

To sum up, if the application is compiled to x86 at load time, there is no problem because the code is cached by the process loader and no other process can reference it's memory. If the application is translated to x86 code at install time, then the generated code is stored in the system namespace with the application's manifest and a signature is generated, so that Singularity can detect if someone modifies the binary files.

Best regards,

May 16, 2010 at 5:22 AM

Oh, I'm sorry, I didn't think about this somehow.

By the way, haven't in Singularity possibliity for compiling MSIL in load time?


May 16, 2010 at 11:06 AM

The documentation says that the application can be configured for load-time compilation in the manifest, although usually applications are compiled at install-time. I guess load-time compilation makes sense only for small application. For larger systems the time required to load the application would be too long.