Thank you everyone for the replies! I wasn't sure what the response would be as sometimes newbie questions get a bit of flack but I think that's usually only when someone copy/pastes the tutorials then comes here and asks you how to code in C
thewrongchristian wrote:
The problem with any OS that implements a VM for "user space" is that you're limited to applications that use that VM, which limits a whole boat load of available applications.
That is what I have noticed as well, I'll explain further to show you that this shouldn't be a problem. Firstly, I've done further research and decided that even WASM wouldn't be viable as they can change it at any time, it wasn't designed for this purpose. I think the safest way to go about this would be to create a low-level instruction set that can be targeted/emitted by LLVM. Think of it as a virtual architecture; instead of x86, it's your VM's assembly language. This would allow you to port everything over without any weird hacks, everything that is usually binary is bitcode instead. This is different from the JVM/Microsoft's CLR as the software doesn't need to be tied to this VM or any specific programming language. You shouldn't have to modify the source any more than you would porting it to any other OS(e.g changing inline asm blocks). Part of my design philosophy is to make sure that the VM aspect is not noticeable to the user/developer.
Take for example the C standard library ABI. Instead of native binary, the .so/.dll file contains bitcode. When the VM is launched by the kernel, this bitcode library is brought into memory as well. The application we are running can then call on the functions contained in the bitcode just the same as it could if it were calling functions natively on the processor. So, if we call printf, it jumps over to the printf subroutine in the bitcode. As a (very) loose example, it would ask the VM to fire a (native) interrupt to the kernel, which would then verify that the VM requesting this has sufficient permissions and carry out the print to stdout by way of message passing to the VM containing our display driver. Every library would be implemented in this same way. You can then link the software you port with these libraries.
I found a really good blog that walks you through writing your own VM/bitcode:
https://blog.subnetzero.io/post/building-language-vm-part-01/You should be able to target this bitcode by writing a backend to LLVM, which actually doesn't appear to be overly difficult after reading the docs on how to do so.
TL;DR: Anything that can be compiled by LLVM should be able to run in this VM.
thewrongchristian wrote:
And I don't see a case for forgoing the memory protection afforded by the kernel/user privilege split. Sandboxes are all well and good, until they're broken. A broken sandbox is much less risky when the VM is a regular user space process.
This is very true, but nothing is truly safe. The meltdown and spectre exploits can break through the hardware protection.
thewrongchristian wrote:
I think JX was heavily inspired by JavaOS.
I think so too. I didn't mention it because I couldn't find much documentation on it. I scoured the internet but couldn't find a free pdf of that book you linked. Thank you for that!
moonchild wrote:
The closest we've gotten to a good sasos in recent times is probably
hydros. My OS has similar aspirations, and I am aware of at least a couple of other people who are also working on things; but all are nascent.
That looks similar to singularity and jx. I don't want it to be tied to a specific language or runtime.
iansjack wrote:
I'd say that the closest to a good SASOS is IBM i (AKA OS/400) where the single address space extends to secondary storage. Although, to be fair, it doesn't really have an address space in the sense that we normally understand it.
I hadn't seen that one in my research so far. I'll look into it. Thanks
eekee wrote:
Forth is a bit of a beast, especially as an OS. No memory protection, interactive, variables are normally accessed via pointers, and arrays are just memory regions. It freely lets you do pointer math interactively if you're crazy enough. I am, but I've learned to do it in stages, watching the stack carefully before issuing the final memory-accessing command. I wonder how people coped with multi-user Forth systems! The language is so flexible, they could have restricted fetch, store, move etc. or even overloaded them to bounds-check for particularly troublesome newbies, but I have no idea if they actually did.
That sounds a little rough compared to what I am looking to do. I want each VM to give the running process a virtual address space, similar to what is done by the hardware in a traditional system. I hadn't thought of the performance implications of bounds checking. I figure if a traditional system is using ~400 cycles to implement a system call, we have a little wiggle room.
eekee wrote:
Anyway, I'm interested in SASOS and transparent persistence, but I still have a lot to learn, even about Forth itself. (That's my chosen language, just in case it wasn't completely obvious.)
I have a lot to learn tool! I am going to be using Rust. I still have to finish reading the intel manuals, the design and implementation of FreeBSD, and a few others that aren't directly related to SAS computing but are interesting to me. I've been considering following the Minix book but in Rust just to give me some practice writing freestanding code in rust. Not sure if that would help you to learn Forth, I know nothing about it.