Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Single Address Space Operating System

c2.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Single Address Space Operating System

#31

Post by stormbrew »

salem wrote: post #8
kabdib wrote: post #5

The Apple Newton did this; used a single address space and some fine-grain protection capabilities of the MMU to get proper security. It was . . . okay, but it's unclear what the performance hit would have been if we had run out of hardware-level protection IDs (there were 15 or 16 domains, IIRC). ARM later deprecated the MMU features that we used (and properly so, I think). There's a 1994 COMPCON paper on it.

Not only that, but the early ARM architecture was terrible at running unix or other non-single address space OS's. If I remember correctly, the caches were virtually tagged, even on the StrongARM, making context switching on linux very expensive.

Tagged TLBs should make multitasking faster, not slower, unless I don't catch your meaning at all. On a non-tagged cache you have to dump the entire thing whenever you change address spaces. With tags you lazily invalidate only the entries that aren't part of the active virtual id.

Re: Single Address Space Operating System

#32

Post by ArbitraryLimits »

This is basically what VxWorks (real-time OS) started doing in their 6.x series - the MMU is active and all memory addresses are virtual, but no two processes get access to the same virtual address range. That way you can debug with virtual addresses turned on and see page faults instead of whatever hilarity ensues from overwriting the operating system itself, then turn the MMU off and stop taking the execution speed hit of translating addresses. It turns out that almost everyone just leaves memory protection on all the time anyway, since duh, it's the only sane thing to do.

Fun fact, the most reliable indicator that you have this kind of setup is whether the Unix emulation layer (if present) offers fork() - if only one process can access a given address then you obviously can't create a copy of a process that uses pointers.

Re: Single Address Space Operating System

#34

Post by cokernel_hacker »

stormbrew wrote: post #31
salem wrote: post #8

Earlier quoted context omitted.

Not only that, but the early ARM architecture was terrible at running unix or other non-single address space OS's. If I remember correctly, the caches were virtually tagged, even on the StrongARM, making context switching on linux very expensive.

Tagged TLBs should make multitasking faster, not slower, unless I don't catch your meaning at all. On a non-tagged cache you have to dump the entire thing whenever you change address spaces. With tags you lazily invalidate only the entries that aren't part of the active virtual id.

Different kind of tagging.

salem is referring to how addresses are compared in the cache: http://en.wikipedia.org/wiki/CPU_cache#Virtual_tags_and_vhin...

you are referring to ASIDs which are the mechanism by which different address spaces can share space in the TLB at the same time: http://www.helenos.org/doc/design/html.chunked/mm.html#id253...

Re: Single Address Space Operating System

#35

Post by Danieru »

orthecreedence wrote: post #33

Sorry if this is a stupid question (I don't fully understand SASOS), but would an OS that does this make ROP chain exploitation easier?

It should not. The exploit cannot access any more libraries or addresses compared to traditional layout.

One bonus not mentioned in the article is context switches no longer need to flush the TLB (the MMU's cache which is indexed by virtual address). Thus you don't lose the cache entries for shared libraries or kernel space.

Re: Single Address Space Operating System

#36

Post by noselasd »

mantrax4 wrote: post #25
wtracy wrote: post #24

I was disappointed that there was no real discussion of why you would want to do this. I see some potential for interesting optimizations, but that's ... it.

In short, private virtual addressing is legacy cruft from a time when this was the only way to organize things due to a constrained memory block identifier namespace. Think about it like IPv4 vs. IPv6, i.e. hacks like NAT, vs. "everything has its own IP address in a single flat address space of IPs". It's the same, but with computer memory. And it has the same benefits.

I'm still not seeing the real benefits.

What, specifically, is bad/wrong about the traditional way of doing process isolation, and what does this approach bring to the table ?

Re: Single Address Space Operating System

#38

Post by noselasd »

ArbitraryLimits wrote: post #32

This is basically what VxWorks (real-time OS) started doing in their 6.x series - the MMU is active and all memory addresses are virtual, but no two processes get access to the same virtual address range. That way you can debug with virtual addresses turned on and see page faults instead of whatever hilarity ensues from overwriting the operating system itself, then turn the MMU off and stop taking the execution speed…

How is the process isolation implemented in such a setup ?

The traditional approach is to flush the tlb and load new a new memory map on a context switch in order implement isolation , though what you're talking about sounds like something else.

Re: Single Address Space Operating System

#39

Post by bitwize »

mjcohen wrote: post #2

Amiga was fun. I still miss Marble Madness and Hole-in-one Miniature Golf. And Tom Rokicki was a god.

In Amigaland virtual memory is still seen as a quaint but passing fad.

I mean, how are you going to write your own interrupt handlers and schedule your own DMA transfers if you can access neither the CPU's interrupt vector nor the custom chip registers from your process's address space?

Re: Single Address Space Operating System

#40

Post by ScottBurson »

Surprised no one has mentioned that the Lisp Machine operating system worked this way.

Maybe it doesn't count because there was no protection against intentional reading or writing of memory belonging to other apps or the OS. But the protections against unintentional writing were good enough to make for a remarkably robust system, in a time when nobody cared about security.

Post reply on HN