Ultimate Monolith

[icebit]

I was thinking of an interesting and highly unconventional concept for an OS. There are no executable binaries, only the kernel. The "programs" are only configuration scripts parsed by the kernel. They include different callback functions for the kernel to jump to on specific events, e.g. IRQs, loops, etc. Every time there is a context switch, the kernel loads the configuration again and retains it until the next switch. This would be the "ultimate monolith", where everything is done by the kernel.

[Techel]

That'd just an interpreter, like the jvm is, but with textfiles and with less abilities. How are such isr procedures and event handlers written? Right, in a scripting language, and this is the same thing as with android.
Android's designer chose the java vm as their program processor over the native one to enable app programmers to 'compile once, debug everywhere'. Do you want to achieve this? If yes, you have to port a scripting language or a bytecode interpreter (or create your own) into the operating system's executive. If not, what are the advantages your design concept offers?

[alexfru]

Someone expressed similar ideas years ago on alt.os.development. Unfortunately, I don't remember who or when exactly (anywhere from 1998 to 2006, when I was very active in news groups). If I'm not mistaken, the ideas also included application fault tolerance (e.g. if the error can be fixed (I/O error, missing file, etc), the app can make further progress when that happens) because the kernel would know about errors and be able to save/restore state and resume execution at the right point in app's code. I don't think that can be done with any/all kinds of errors because there are parts of application state that can't survive long periods of inactivity (think of network/protocol states/connections/sessions/etc with their unique IDs, e.g. your dynamic IP address may change and you may never get it back), but it sure was nice alternative thinking. I don't think those ideas have ever materialized, though.

[alexfru]

As for monoliths and general lolz insufficiency, check out The Page-Fault Weird Machine: Lessons in Instruction-less Computation, code & slides.

[Techel]

We show that powerful computation on x86 processors is possible without executing any CPU instructions

Hype intensifies.
Edit: Too bad the pdf is damaged and cannot be read by my mobile.

[azblue]

We show that powerful computation on x86 processors is possible without executing any CPU instructions

Hype intensifies.
Edit: Too bad the pdf is damaged and cannot be read by my mobile.

I'm having trouble understanding how PaX PAGEEXEC works; I'm hoping someone here can explain it.

By setting the Supervisor/User (S/U) bit in the PTE of a designated non-executable page, we can cause the processor to trap any access to that page...

The page fault handler then resets the S/U bit for a single data byte access to succeed,
and performs that access – causing the PTE for the page to be recorded in the dTLB. Right after this access, the handler resets the PTE entry’s S/U bit back to unconditionally causing the fault.

The bolded part is where I'm lost -- how does the page handler regain control? My understanding is it resets the S/U bit, then returns control to the program that caused the page fault. The program then retries the instruction, and this time it succeeds, so the page handler never regains control and can never reset the S/U bit. So how does this work?

[alexfru]

By setting the Supervisor/User (S/U) bit in the PTE of a designated non-executable page, we can cause the processor to trap any access to that page...

The page fault handler then resets the S/U bit for a single data byte access to succeed,
and performs that access – causing the PTE for the page to be recorded in the dTLB. Right after this access, the handler resets the PTE entry’s S/U bit back to unconditionally causing the fault.

The bolded part is where I'm lost -- how does the page handler regain control? My understanding is it resets the S/U bit, then returns control to the program that caused the page fault. The program then retries the instruction, and this time it succeeds, so the page handler never regains control and can never reset the S/U bit. So how does this work?

Disclosure: I have not read the doc/code closely. This is my simplified understanding of it.

It looks like they set up the system tables (GDT, IDT, TSS, page tables) in such a way that an attempt to execute an instruction always causes an exception (page fault or double fault or maybe something else) and so a return from an exception handler is immediately followed by another exception and all work is therefore happening in exception handlers.
The tricky part that you may be missing is that invoking an exception handler causes the CPU to store a part of its current state somewhere (on the stack and/or in the TSS). The locations of the "somewheres" can be chosen such that those stores overwrite the system tables and alter the behavior of exception handlers and also perform I/O as shown in the Game of life demo.