OSDev.org

nullplan wrote:

nexos wrote:A malicious app could overwrite all of memory with zeroes, no matter what you do. No MMU almost means no security .

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?

thewrongchristian wrote: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.

Then you have the situation I already mentioned with OS-9 on the e300 (but on the x86 it would work the same): If the MMU is used at all, then for each virtual address, it must look up protection attributes and physical address. Since we store those together, it does not matter if you can calculate the physical address from the virtual one, even if the page table walk is in software; you still have to look up the protection attributes anyway. Thereby negating all the supposed speed advantages of running without MMU. So you might as well do it properly.

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

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.

bzt wrote: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.

A buffer mapped copy-on-write on a system with an MMU will still have to be copied before it is written to on a system without an MMU, it will just be incumbent upon the application to make sure that it performs the copy. And an IPC buffer can be mapped writable to all programs using it, so once it has been mapped in each process, access to it is just as fast as to any other area of a program's address space.

nullplan wrote:

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

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.

Or just use Relocs like the old Amiga Hunk format used.

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.

eekee wrote: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.

bloodline wrote: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.

I was going to ignore ELF, but now I might need it because I'm thinking of a C-based Forth so I can get started more easily with these ARM devices. I've also been avoiding even thinking about filesystems much, but I may want a journalling block store for the onboard flash of some devices.