Even better: A malicious app could overwrite the IDT to register one of its own functions as interrupt handler, then call that interrupt. Thereby usurping kernel privileges and taking over the whole machine.

But, of course, you can still use the protection mechanisms of the MMU within a single address space to protect the kernel from the user applications.

Is position independent code something you'll be looking at in your OS?

In general, yes. However we surely could anticipate serious speed up because separate address spaces means memory buffers must be copied (or at least mapped in CoW manner) from one address space into another.

All the PIC solutions I know of are built with memory mapping in mind, and don't really lend themselves to a single-address-space world. I know of OS-9, as stated, but I know of no toolchain (except the one from Radisys themselves) that can produce OS-9 modules. And ELF and ELF FDPIC require the distance between code and data to be known at link time, and kept at load time.

See, in a multitasking single-address-space OS, what you would want, ideally, is a design that allows you to load code and data section independently of each other. That allows you to have multiple processes running the same program, and each process would have a different data section, and would all share code. OS-9 can do that, at least.

ELF and ELF FDPIC don't allow that. If a dynamic library (and position independent executables are often claiming to be dynamic libraries) wants a 2MB break between code and data, you must allocate those 2MB for the process. If another process were to use the same program, you would have to load the entire program again. No code sharing possible. The whole thing will end up as a massive waste of space, just because the OS designer didn't want to implement paging properly. Don't get me wrong: This stuff is position independent. You can load the program anywhere in address space, but it must allocate the whole area.

I don't know PE enough to make a determination about it, though. It is possible it might allow such usage. Not likely, though.

I imagine true PIC can be done, but it carries a small performance penalty of its own. Indirection is never quite free. I'm not sure how small the penalty is on modern CPUs. I've also got a hunch it might need a register allocated just for the indirection.

Relocation does seem to be the way to go. If I'm not mistaken, it's basically the same code as you need for dynamic linking anyway. It increases program start time a little, but I'm sure this would only be noticeable if your shell-script webserver got slashdotted. I'm going on my experience with shell scripts under various OSs, all but one with dynamic linking. I have found really big shell scripts a little slow on some OSs (never Linux), but more cores seemed to make a bigger difference than dynamic linking. The only combination which was unacceptably slow in moderate use was a 700-line CMS + 150-line web server on a single-core 466MHz PPC running OS X.

I'm currently planning to use an ARM device with a simple MPU (memory protection unit) which, if I understand right, protects but doesn't remap. I'm thinking IPC will include passing a pointer (or rather a reference) via the kernel so it can allow the recipient access.

I am planning to start a thread regarding the relocation of ELF executables, as I’ve struggled with the ELF format in the past and I will need a bit of hand holding to properly understand it. I wanted to get started on this back in December, but I’ve found reimplementing the filesystem (properly this time, last time I just hacked it into my shell) so dull, I really lost motivation... so focused on GUI code instead.