Ask HN: Would you design a modern CPU with virtual memory support? | Hacker News Reader

Ask HN: Would you design a modern CPU with virtual memory support?

9 pointskruhft10 comments

Virtual memory[1] is useful for a number of things[2], but can takes up a large amount of die space and development time during the development of a CPU to be both efficient and correct. With the advent of 64+ bit architectures and cheap memory available today, an extended address space and paging aren't specifically needed for many tasks. Memory safe, high level languages[3] need less 'isolation' and 'protection' from a VM subsystem than traditional languages like C and C++. Page tables help the OS organize non-contiguous physical memory for applications, but is that as much an issue today, especially for symbolic and object based languages?

If one was to design a new 'high level' language CPU today, would it be seen as advantageous to include a traditional multi-level page table based virtual memory system, or could the resources be put to better use in other areas of the chip design?

[1] https://en.wikipedia.org/wiki/Virtual_memory

[2] The primary benefits of virtual memory include freeing applications from having to manage a shared memory space, increased security due to memory isolation, and being able to conceptually use more memory than might be physically available, using the technique of paging.

[3] http://dl.acm.org/citation.cfm?id=327133

The ABI for shared libraries gets a little different. IIUC, the global offset table (and all of the .data and .bss sections) for a given shared library is located at a fixed offset relative to the .text section. Position-independent code can always lookup its own data relative to the instruction pointer. For a memory protection-only model to work and still have shared read-only mappings to shared libraries, you would have to include the base address of the target library in the GOT for every redirection, and pass it to the target via a dedicated register.

Do we really need shared libraries anymore? The original reasons (disk space / ram) no longer apply outside of minimal boards like the RPi. With package managers it's no longer a hassle to have to update everything that uses a library when a vuln is discovered. I can only think of two reasons to use shared libraries anymore: vdso and plugins to applications.

Edit: thought of a 3rd reason, licensing... But that's really an artificial/political reason rather than a technical one.

Security. Instead of one CVE for libpng, you now have thousands for all of the programs that statically linked to it.

I like the idea of flat address spaces with memory protection only. There are a variety of ARM processors that are set up that way, like the ARM940T which has 16 regions that can be configured in size, position, priority, etc. Using a large background region with several smaller high-priority regions that overlap it, you can run several tasks with enforced private memory and shared memory spaces. That way you get some of the benefits of an MMU, but with fast context switches and deterministic timing.

So the idea is that you take memory and chunk it into regions that can (possibly) overlay each other, each with it's own protection level? Interesting idea.

Look into the ARMv7-A/R PMSA (protected memory system architecture) for more details. ARMv7-M does the same thing.

> Memory safe, high level languages[3] need less 'isolation' and 'protection' from a VM subsystem than traditional languages like C and C++.

I'm not buying it. Java is a memory-safe high-level language that very much needs memory protection from the rest of the system. The JVM has regularly been an attack target.

Because the JVM is written in C++, rarely because of issues with Java itself.

But all language runtimes are running machine code under the hood. Machine code has no built in memory safety.

You can build memory safety into machine code with the proper processor architecture. See the last reference in the original post.

Reply on news.ycombinator.com