Statix allocation at load time + no MMU, no protection ring.

[sandras]

So I had this idea yesterday night. I was thinking about not having any kind of dynamic allocation system for yser space and combining that with some sort of bound checking the executables and not requiring an MMU. Basically, load executable (native machine code), relocate it to where you have space available, check if it does not touch memory outside of the little chunk allocated to it and go for it - run the program. The Idea is that you simplify bound checking because of static allocation. you gain speed because of single address space, and you don't lose process isolation. Is it feasible to check whether a machine code executable will not touch memory not of it's own? I though it is, but when I started thinking, it seemed quite complicated. Are there any tricks I may not know about, that simplify the process?

[evoex]

Is it feasible to check whether a machine code executable will not touch memory not of it's own?

There's one way to do it, namely single-stepping the entire application and for any memory access make sure the pointer is valid. However, such a solution would be extremely slow. Besides, you could only have a few applications running, until you use up all the memory.

Trust me, don't even go there.

[OSwhatever]

Pre-checking an executable that it behaves nicely is very difficult and I'm not sure you could get 100% coverage with native code. After that the system stability is up to the software/library to be stable enough so that no bugs slips through that can harm the system. HW support could be added, then the CPU could work with identifiers rather than pointers, HW bounds checking could be in place. Then the kernel must assign memory associated with these bounds structures that the CPU can load and use. The question is if HW bounds checking on object level would be faster than an MMU?

One address space works well in system where the SW is known and a crash doesn't mean the end of the world, examples are embedded systems like TV-setup boxes and such. Let's say you are a server administrator, if a program crash that means the whole system goes down and the company server downtime can cost millions, in this case you probably want to leave the MMU on even if does mean that the server is a little bit slower.

[AndrewAPrice]

This is why I'm using a bytecode approach. I ensure addresses to functions, class layouts, types, array bounds, etc are all correct at load time.

[OSwhatever]

This is why I'm using a bytecode approach. I ensure addresses to functions, class layouts, types, array bounds, etc are all correct at load time.

Is there some way it is possible that bugs can sneak in, for example bugs in the bytecode implementation or in the library?

Microsoft in the Singularity experimental OS, implemented pre-verification at load time in order to check if the program is safe. Why did they do this when bytecode is supposed to be safe to begin with?

[Nable]

> pre-verification at load time in order to check if the program is safe
> check if the program is safe
http://en.wikipedia.org/wiki/Halting_problem

[jnc100]

CIL (as defined by Microsoft) is not inherently type safe, only a certain subset is, and the subset which is verifiable is in itself a subset of that which is type safe. Therefore, the checks by Singularity are to ensure that the code is verifiable (and thus type safe) prior to being run. For example, you can generate non-type safe code with c# using the 'unsafe' keyword to allow direct access to certain memory areas, e.g.

Code: Select all

unsafe {
    byte * vmem = (byte *)0xb8000;
    *vmem = (byte)'H';
}

compiles to valid CIL, but you wouldn't want any process to be able to include it. The rules for verifiability are defined in ECMA-335.

Regards,
John.

[ACcurrent]

Google's native client does the same thing (except its not an OS), however it use llvm-IR for PNaCl and its own specialized compiler. On x86 it uses segments. It works well for chrome because Javascript would be slower in any case. However it has its performance limitations.