Profile Conformance Check Stages¶
The MOSA compiler framework supports a technique called 'Profile Conformance Check Stages'. Using these, one can restrict a program's access to the instruction set.
General idea¶
Is a bootloader able to allocate dynamic objects? Should a user-process be allowed to execute unsafe code? Has a driver the same permissions as a kernel? These are frequent questions in the life of an OS developer and so he has to define a model for decisions like that and check every starting process if it meets these conditions.
To make life easier, the MOSA compiler framework brings profile conformance checking into play. Just define a new stage model and care less about a program having the correct rights.
Basic structure¶
Currently there are 4 basic stages planned to be built into MOSA:
- Bootloader-Stage
- Usermode-Stage
- Drivermode-Stage
- Kernel-Stage
If one would want to express it mathematically one could say informally:
Bootloader < Usermode < Drivermode < Kernelstage
measured by the amount of available instructions.
Bootloader-Stage restrictions¶
A bootloader should be restricted to static arrays. So we'd have to restrict it from using certain instructions, e.g.
newobj, newarr, stfld
Usermode-Stage restrictions¶
Contrary to C#.Net, the default MOSA Usermode-Stage does not allow the use of unsafe code, e.g. the usage of pointers.
Drivermode-Stage restrictions¶
Drivers should be restricted from the ability of killing or starting processes.
Kernel-Stage restrictions¶
There should be no restrictions to the kernel.
Implementation¶
Every stage contains tables of allowed instructions and allowed parameters.
1private static readonly CodeDef[] s_and = new CodeDef[] {
2 new CodeDef(typeof(Operand), typeof(ConstantOperand), new byte[] { 0x81 }, 4),
3 new CodeDef(typeof(Operand), typeof(RegisterOperand), new byte[] { 0x21 }, 0),
4 new CodeDef(typeof(RegisterOperand), typeof(MemoryOperand), new byte[] { 0x23 }, 0),
5};
6void ICodeEmitter.And(Operand dest, Operand src)
7{
8 Emit(dest, src, s_and);
9}