NyanOS and XNC
Posted: Fri Oct 03, 2014 6:17 pm
Hi, everybody. I want to announce my operating system project. It is called NyanOS. Nyan stands for Not Yet Another *Nix. The main goals are security, stability, full protection and separation.
Note: this OS is mostly just a concept for now.
Filesystems.
-Boot filesystem - stores the bootloader, the virtual machine and the kernel.
-Data filesystem - other software.
XNC virtual machine.
The kernel is executed under a virtual machine. It's purpose is to manage memory access. The architecture will be CISC-like.
Kernel.
I preferred the microkernel architecture for my kernel. The kernel starts userspace servers, which control hardware.
Root program.
The root program is the only program having full access to the real hardware (via VM calls) and virtual machine. It's memory region can only be accessed (executed, written or read) by itself, so no runtime kernel patching.
Memory region.
Every program has it. A memory region is a contiguous part of physical memory, access permissions can be controlled only by the root program. By default, only the owner has access to it.
Boot sequence.
Bootloader -> virtual machine -> kernel (aka root program or ROM) -> hardware search and driver probing -> system software -> other apps.
Context.
Every program has a context. It describes its memory region borders, holds register state, etc. Contexts are manipulated by the virtual machine.
How do programs interact with libraries?
When a library's code is loaded into memory, everything has RX access to it. If library requires writing, the kernel allocates memory in program's private address space.
Direct hardware access API (DHA).
Every operating system needs a way to extend hardware support, but how can a managed OS access real hardware? You can say, it's possible to use native code, but it is a huge security hole. DHA allows the root program to access real hardware (registers, physical memory).
Why DHA API is not a big security hole?
The reader probably wants to ask this question. The answer is, that the kernel controls, what servers (drivers) want to access. Servers cannot control same ports, memory, etc. For example, we have two servers: the first is good, when the second wants to do bad things. The kernel reads their manifests, it discovers, what hardware they want to control, if there's a match between two different servers, it loads the one, which was installed earlier. I think, this scheme partly eliminates the problem, but the main vulnerability is still in the user's brain. Software can't control it, prevent it from wanting to load a malicious driver or even typing "rm -rf /*". Also, DHA doesn't allow programs to access memory regions, they don't own (only ownerless), i. e. they can't use it for defeating memory protection.
Binary format support.
It will be easily extensible, just like hardware support.
PS. I know, that these concepts are not new to the world. I just wanted to tell you about, what I'm working on and hear your thoughts and opinions on this.
About the XNC (XNC's Not C) programming language.
The application root.
The application root is the descriptor of all parts of the program: GUI, TUI, back-ends.
Future code will look something like this:
ProgramGUI pseudo-example:
ProgramTUI pseudo-example:
BackEnd pseudo-example:
It is similar to Objective-C (and Java?), isn't it? 
App manifests.
This is similar to OS X and iOS. In an application manifest you'll be able to select status bar style you want (or even hide it), specify an icon and a lot of other things. Even variables for the application, no struggling with parsing config files at all, everything is loaded just for you.
Localization bundles.
This is also reminds about OS X and iOS. This subsystem will be like in iOS.
I will post all my new thoughts here.
Note: this OS is mostly just a concept for now.
Filesystems.
-Boot filesystem - stores the bootloader, the virtual machine and the kernel.
-Data filesystem - other software.
XNC virtual machine.
The kernel is executed under a virtual machine. It's purpose is to manage memory access. The architecture will be CISC-like.
Kernel.
I preferred the microkernel architecture for my kernel. The kernel starts userspace servers, which control hardware.
Root program.
The root program is the only program having full access to the real hardware (via VM calls) and virtual machine. It's memory region can only be accessed (executed, written or read) by itself, so no runtime kernel patching.
Memory region.
Every program has it. A memory region is a contiguous part of physical memory, access permissions can be controlled only by the root program. By default, only the owner has access to it.
Boot sequence.
Bootloader -> virtual machine -> kernel (aka root program or ROM) -> hardware search and driver probing -> system software -> other apps.
Context.
Every program has a context. It describes its memory region borders, holds register state, etc. Contexts are manipulated by the virtual machine.
How do programs interact with libraries?
When a library's code is loaded into memory, everything has RX access to it. If library requires writing, the kernel allocates memory in program's private address space.
Direct hardware access API (DHA).
Every operating system needs a way to extend hardware support, but how can a managed OS access real hardware? You can say, it's possible to use native code, but it is a huge security hole. DHA allows the root program to access real hardware (registers, physical memory).
Why DHA API is not a big security hole?
The reader probably wants to ask this question. The answer is, that the kernel controls, what servers (drivers) want to access. Servers cannot control same ports, memory, etc. For example, we have two servers: the first is good, when the second wants to do bad things. The kernel reads their manifests, it discovers, what hardware they want to control, if there's a match between two different servers, it loads the one, which was installed earlier. I think, this scheme partly eliminates the problem, but the main vulnerability is still in the user's brain. Software can't control it, prevent it from wanting to load a malicious driver or even typing "rm -rf /*". Also, DHA doesn't allow programs to access memory regions, they don't own (only ownerless), i. e. they can't use it for defeating memory protection.
Binary format support.
It will be easily extensible, just like hardware support.
PS. I know, that these concepts are not new to the world. I just wanted to tell you about, what I'm working on and hear your thoughts and opinions on this.
About the XNC (XNC's Not C) programming language.
The application root.
The application root is the descriptor of all parts of the program: GUI, TUI, back-ends.
Future code will look something like this:
Code: Select all
class ApplicationRoot: argv {
func LoadGUI: {
loadUI: ProgramGUI; //ProgramGUI should be in a separate file. It does all GUI-related: handles UI events, draws UI elements, etc...
activateUI: ProgramGUI;
return UI_LOAD_SUCCESS; //Or UI_LOAD_FAILURE. UI_LOAD_FAILURE doesn't cause the app to crash. Failure can mean, that program just doesn't have any GUI.
}
func LoadTUI: {
loadUI: ProgramTUI; //ProgramTUI should be in a separate file.
activateUI: ProgramTUI;
return UI_LOAD_SUCCESS; //Or UI_LOAD_FAILURE. UI_LOAD_FAILURE doesn't cause the app to crash. Failure can mean, that program just doesn't have any TUI.
}
//CLUI (command line user interface) is not interactive, so it is not a view, but it still can load ProgramTUI's.
func LoadCLUI: {
CLUIMain: argv;
return UI_LOAD_SUCCESS;
}
class {
loadBE: ProgramBackEnd;
startUI: ;
}
}
Code: Select all
class ProgramGUI {
UILabel helloWorld = [alloc UILabel];
helloWorld.title = @8"Hello, World!"; //@8"" - UTF-8 string.
UIEvent onKeyDown: keyCode {
//Check keyCode, do stuff.
...
}
helloWorld.onClick = [alloc code]: {
UIAlert helloAlert = [alloc UIAlert];
helloAlert.title = @8"Hello, World!";
[push helloAlert.buttons]: [alloc UIAlertButton];
helloAlert.buttons#1.title = @8"OK";
[display helloAlert];
[wait helloAlert];
if (helloAlert.buttons#1.pressed)
{
//Do something.
[exit ProgramBackEnd];
}
}
}
Code: Select all
//Similiar to ProgramGUI.
...
Code: Select all
class ProgramBackEnd {
func Exit:
{
//Exit the application. Resource deallocation is done by kernel.
...
}
}
App manifests.
This is similar to OS X and iOS. In an application manifest you'll be able to select status bar style you want (or even hide it), specify an icon and a lot of other things. Even variables for the application, no struggling with parsing config files at all, everything is loaded just for you.
Localization bundles.
This is also reminds about OS X and iOS. This subsystem will be like in iOS.
I will post all my new thoughts here.
