OSDev.org

A Single Address Space OS places all processes in a single address space, right?
How does it protect processes from another e.g. prevent A from writing to B's memory?
Are there some good resources on SASOS or has someone on the forum tried to write one and would like to share their experience?

Typically, single address space implies that you run bytecode instead of native code, so you can make sure in software no process accesses the other.

Then there are various other methods that actually limits access to ranges of memory in hardware, such as segmentation, that whether those methods qualify as a single address space is controversial. Instead SAS can also mean "Small Address Spaces" which do include such schemes that trade parts of hardware memory management for performance.

Combuster wrote:Instead SAS can also mean "Small Address Spaces"

By SASOS i mean an OS that doesn't use paging or segmentation, but has the address space 100% untranslated.

Combuster wrote:Typically, single address space implies that you run bytecode instead of native code

Isn't there another way than building a kernel mode byte code interpreter or using a specialized compiler as Singularity does?
I heard that Amiga OS was a SASOS Microkernel, did it use a bytecode interpreter?

Amiga had no protection between processes other than their developers' reputation.

StartOS wrote:Isn't there another way than building a kernel mode byte code interpreter or using a specialized compiler as Singularity does?

http://people.csail.mit.edu/smcc/projects/pittsfield/

IOW, no magic. Either you adjust the code to stay within bounds or you use software and/or hardware assistance to enforce those boundaries.

You could potentially implement it by having all processes and the kernel itself be relocatable, using ASLR and paging. You'd then terminate any process which page faults on the assumption its trying to access something it shouldn't. A process could get lucky however, so this isn't really that secure.

By far the vast majority of current SAS OSs require programs to be written in a language that enforces memory-safety. In theory you could include a special subset of C++ in this if you explicitly disallow pointers and only allow references, but you'd probably need to write your own compiler for that anyway.

Note also that you probably want to use paging anyway as it allows you to lay out the single address space however you like, rather than having to depend on using only those physical memory ranges that the firmware reports as available.

Regards,
John.

The main issue with single address spaces is code relocation. With a virtual address space, you don't need to worry about code relocation at all - your code can work with absolute pointers to its heart's content because it's always loaded in the same place from it's point of view. But if you place all code in the same address space, it can't always be loaded at the same address and then you either have to make your code relocatable (which may be restrictive) or you have to "fix" the addresses by keeping a table of all absolute addresses and getting the OS to add the base address to each listed address when loading the code (and any other data which takes the form of a hard-coded absolute address and is listed in the addresses-for-fixing table) (which is rather messy). Sure enough, with a flat memory model, one can probably get away with using only relative addresses for code and absolute run-time supplied addresses for allocated blocks of data, but it's still a messier and more error-prone situation and you lose many of the other benefits of virtual address spaces.

There have been some exciting software-isolation-based SASOS attempts, as others have pointed out.

However, a single address space does not necessarily mean that all apps have permissions to all memory and rely on software for isolation. SASOS can also be done in hardware.

Mungi OS was an interesting example of a SASOS using hardware memory protection (developed on SGI MIPS-based workstations back in the day). If you look at table 1 in http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf you will see very favourable IPC performance making it all worth it.

The Mungi recipe could be used on x86-64 or any other modern CPU with conventional TLB etc too. (It would be interesting to understand the extent to which L4-style IPC improves etc in such an effort on modern CPUs).

The Mill CPU is an example of hardware which is intrinsically SAS. And an OS we are porting to the Mill is ... Linux! With the Mill's hardware assistance there is nothing stopping Multiple-address-space (MAS) OS being ported to the Mill, with all apps being completely oblivious to the fact that its a SASOS (with no aliasing of virtual memory addresses).

willedwards wrote:The Mill CPU is an example of hardware which is intrinsically SAS. And an OS we are porting to the Mill is ... Linux!

But it's just obvious choice. What else should you port if there's just one widely used open source OS? Despite of any addressing troubles it's the only choice for a new processor vendor because of the large user base and big market.

However, it would be more interesting if you select a leading edge technology to use with your processor. Have you tried something of the sort? There are many technologically interesting OSes and combination of the Mill with a suitable OS can deliver better performance, better security, or something that beats the standard Linux or Windows approach. And yes, something like VM based OS can be used (I'd like Java solutions, for example). But it's up to the Mill's designers to find a niche where Mill can be far ahead of competitors.