How ZGC allocates memory for the Java heap(joelsiks.com) |
How ZGC allocates memory for the Java heap(joelsiks.com) |
Putting the actual data layouts in 44 bits out of 64 is a neat trick which relies on the allocator being aware of the mappings between physical and virtual addresses.
Not too long after someone asked what sort of interesting changes 64 bit will bring. And I’ve been keeping that question in the back of my mind ever since.
Aliasing memory multiple times in order to do read or write barriers and make GC much cheaper is a pretty good one. But another one I know of is that one of the secrets of the L4 microkernel is that its IPC speed comes substantially from reducing the amount of TLB work that needs to be done to switch to another process running in a different address space. They use the same address space and only swap out the access rights which cuts the call overhead in half. It’s pretty easy to put a bunch of processes into a 64 bit address space and just throw each one a randomly located 4GB slice of RAM.
Something like: “From now on, code on these pages can only access data on these pages, and only return to/call into other code through these gates…”
https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
Or some sort of special write barrier store op-code, idk.
Imagine a server process that wants to run some elaborate third-party content parser. It’d be great to be sure that no matter how buggy or malicious that code, it can’t leak the TLS keys.
Today, high-security architectures must use process isolation to achieve this kind of architectural guarantee, but even finely tuned IPC like L4’s is an order of magnitude slower than a predictable jump.
You can also play tricks with the virtualization hardware, bit it need kernel support.
Eventually we will get segments back again.
Is that something MPK makes possible? The doc I’ve read suggests either your process can flip permission bits or it can’t. Great for avoiding out-of-sandbox reads. But if there’s arbitrary execution happening, why can’t that code flip the access to secrets back on?
https://youtu.be/T05FI93MBI8?si=EieFgujaGiW2gbO8&t=958
The trick is to do a cascading disassembly of all untrusted code you'll execute to prove it can't change the MPK register.
Thanks!
EDIT: Looks like this is the relevant paper from the Graal team: https://www.graalvm.org/resources/articles/binsweep.pdf