Source
r/linux•
Jengu

Has anyone ever tried making a single-address-space Linux variant?

One interesting variety of OS are single-address-space OSes, where there is only one giant address space (no per-process addressing, and no separate physical vs. virtual addressing). The TLB is literally turned off. I believe the MS research OS Blowfish does this for example. In order for it not to be a security nightmare you have to combine it with some other tech (proof carrying code, or running everything on top of a trusted virtual machine, etc.) but there's no reason it can't be made secure. There's a significant performance advantage, and a lot of implementation details for the OS should become simpler.

I think it'd be cool to hack on such an OS, but the problem of needing to implement a gajillion drivers is pretty insurmountable. It seems to me that the most economical way to do it would be to try and do it as a Linux kernel patch set. Has this already been tried? I googled around a bit and found nothing but I might have been using bad terms. I don't have a lot of OS experience so I don't know how deeply embedded the assumptions are going to be in the kernel about there being multiple address spaces, and whether those are likely to require per-driver changes.

Posted Jun 15, 2010, 9:15 PM UTC

714
kimtoms•

check out http://en.wikipedia.org/wiki/%CE%9CClinux

3
JenguOP•

Any idea how they deal with implementing fork() as mattcox brought up? It's not mentioned in their FAQ.

1
vikashgoel•

uClinux doesn't provide fork(). Applications have to use either threads or vfork().

1
dsylexic•

I'm not that famiilar with uclinux, but I think it forgoes the copy-on-write semantics completely, in favor of using relocatable images that get duplicated up front, then have all references shifted in the copy. This normally implies that processes are constrained to a contiguous region, with no runtime allocation or dynamic linking.

Looks like a classic speed vs. size tradeoff, in that context switches are cheaper due to the global address space, but at the cost of having to pre-allocate all heap space and giving every process its own copy of libc, etc. You also lose memory protection with no mmu, but might gain some speed.

1
[deleted]•

The biggest issue I see with "porting" Linux to this model is that you won't be able to implement POSIX compliance, specifically, the fork() instruction.

Fork produces two identical copies of a process (aside from the return code) and so each process needs to have identical data copied to the same virtual address initially, but be able to mutate it independently. (As a practical implementation detail, this is implemented via copy-on-write mappings in the child.) If there's no virtual addressing, I don't see how this is possible.

tl;dr: You might be able to port the kernel, but it'll no longer be anything like POSIX.

2
harlows_monkeys•

Here's a POSIX compliant fork implementation that not only works fine on a single-address-space machine, it even works on Windows:

pid_t fork(void)
{
    return EAGAIN;
}

On a more serious note, fork is no problem is your processor supports, and you make use of, position independent code.

2
mpyne•

That's not anywhere close to POSIX-compliant.

fork(2) must return twice, once from the child with a return value of 0, and once from the parent with a return value of the child's PID.

There's much more that goes into processes than merely different address spaces.

3
harlows_monkeys•

There is an error, but not what you think it is (hint: fork can fail). Here's a fixed version:

pid_t fork(void)
{
    errno = EAGAIN;
    return (pid_t)(-1);
}

Now its POSIX compliant.

7
mpyne•

IEEE Std 1003.1-1988 neglected to require concurrent execution of the parent and child of fork(). A system that single-threads processes was clearly not intended and is considered an unacceptable "toy implementation" of this volume of IEEE Std 1003.1-2001.

This is from the current POSIX manual page regarding fork(2).

You make an excellent point that the function can fail though, which I don't think many programs deal with too well.

2
[deleted]•

PIC doesn't resolve this issue at all. How are you going to deal with the fact that pointers to runtime-mapped memory are going to be the same?

2
harlows_monkeys•

Yeah...brain fart. I was thinking of relative addressing modes, not PIC. You have to use a process layout where all data access is through some kind of relative addressing mode.

2
JenguOP•

Since I'm only looking to co-opt the drivers, that'd be fine. Excellent point though, upvoted.

1
[deleted]•

[deleted]

1
JenguOP•

For an OS like this, you set things up in the first place so that only software that's proven not to trample on memory is run in the first place. That's why I said it might require running everything user space on a trusted VM. There are other approaches though.

1
genpfault•

You could always lose your t-hos.

1