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

How ZGC allocates memory for the Java heap

joelsiks.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: How ZGC allocates memory for the Java heap

#11

Post by ahartmetz »

twoodfin wrote: post #8
hinkley wrote: post #7

Earlier quoted context omitted.

In the beginning of the 32 bit revolution, when the future was here but unevenly distributed, there was a lot of talk about how 32 bit pointers would fundamentally change how people wrote code. Among other things it got rid of a bunch of odd bookkeeping, and if you don’t have to do the bookkeeping you don’t have to write the code in a way that supports it, so you can do other things. Not too long after someone asked…

Yeah, would love to see the CPU vendors invent some primitives to let user code pull those kinds of privilege isolation tricks within a single process and address space. 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…”

I've had some ideas about avoiding format validation in IPC receivers if the data is encoded by trusted code, which is also the only code that has rights to send the IPC data / to connect to the receiver. I can't really think of an important problem that it would solve, though. DBus always validates received data, but it's not really meant or very suitable for large amounts of data anyway.

Re: How ZGC allocates memory for the Java heap

#12

Post by MarkSweep »

twoodfin wrote: post #8
hinkley wrote: post #7

Earlier quoted context omitted.

In the beginning of the 32 bit revolution, when the future was here but unevenly distributed, there was a lot of talk about how 32 bit pointers would fundamentally change how people wrote code. Among other things it got rid of a bunch of odd bookkeeping, and if you don’t have to do the bookkeeping you don’t have to write the code in a way that supports it, so you can do other things. Not too long after someone asked…

Yeah, would love to see the CPU vendors invent some primitives to let user code pull those kinds of privilege isolation tricks within a single process and address space. 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…”

That would be pretty cool. Something like the Win32 function GetWriteWatch, but implemented in hardware instead of the page fault handler (I assume).

https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

Or some sort of special write barrier store op-code, idk.

Re: How ZGC allocates memory for the Java heap

#13

Post by twoodfin »

ahartmetz wrote: post #11
twoodfin wrote: post #8

Earlier quoted context omitted.

Yeah, would love to see the CPU vendors invent some primitives to let user code pull those kinds of privilege isolation tricks within a single process and address space. 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…”

I've had some ideas about avoiding format validation in IPC receivers if the data is encoded by trusted code, which is also the only code that has rights to send the IPC data / to connect to the receiver. I can't really think of an important problem that it would solve, though. DBus always validates received data, but it's not really meant or very suitable for large amounts of data anyway.

What I’m looking for is a way for a process to de/re-escalate its privileges to access memory, without an expensive context switch being required at the transition. The CPU would simply enforce different rules based on (say) the high-order bits of the instruction pointer.

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.

Re: How ZGC allocates memory for the Java heap

#14

Post by MBCook »

acchow wrote: post #4
twoodfin wrote: post #3

Earlier quoted context omitted.

When your comment and the article refer to “physical” addresses, those are physical in the context of the JVM, right? To the OS they’re virtual addresses in the JVM process space?

Correct. ZGC has no way to escape from the virtualization by the kernel (assuming your hardware and kernel uses an MMU)

Thank you for the answer, I was wondering that as well.

Re: How ZGC allocates memory for the Java heap

#15

Post by nyanpasu64 »

hinkley wrote: post #7
gopalv wrote: post #2

The 32x virtual memory to physical memory ratio plays into relocation and colored pointers (i.e pointers where some bits serve as flag bits). 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.

In the beginning of the 32 bit revolution, when the future was here but unevenly distributed, there was a lot of talk about how 32 bit pointers would fundamentally change how people wrote code. Among other things it got rid of a bunch of odd bookkeeping, and if you don’t have to do the bookkeeping you don’t have to write the code in a way that supports it, so you can do other things. Not too long after someone asked…

Isn't not swapping page tables during a call precisely what the KPTI mitigations had to turn off for Meltdown mitigations?

Re: How ZGC allocates memory for the Java heap

#16

Post by gpderetta »

twoodfin wrote: post #13
ahartmetz wrote: post #11

Earlier quoted context omitted.

I've had some ideas about avoiding format validation in IPC receivers if the data is encoded by trusted code, which is also the only code that has rights to send the IPC data / to connect to the receiver. I can't really think of an important problem that it would solve, though. DBus always validates received data, but it's not really meant or very suitable for large amounts of data anyway.

What I’m looking for is a way for a process to de/re-escalate its privileges to access memory, without an expensive context switch being required at the transition. The CPU would simply enforce different rules based on (say) the high-order bits of the instruction pointer. 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 maliciou…

For a brief moment Intel supported MPX which did something similar.

You can also play tricks with the virtualization hardware, bit it need kernel support.

Eventually we will get segments back again.

Re: How ZGC allocates memory for the Java heap

#17

Post by mike_hearn »

twoodfin wrote: post #8
hinkley wrote: post #7

Earlier quoted context omitted.

In the beginning of the 32 bit revolution, when the future was here but unevenly distributed, there was a lot of talk about how 32 bit pointers would fundamentally change how people wrote code. Among other things it got rid of a bunch of odd bookkeeping, and if you don’t have to do the bookkeeping you don’t have to write the code in a way that supports it, so you can do other things. Not too long after someone asked…

Yeah, would love to see the CPU vendors invent some primitives to let user code pull those kinds of privilege isolation tricks within a single process and address space. 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…”

It exists, that's called MPKs.

Re: How ZGC allocates memory for the Java heap

#18

Post by twoodfin »

mike_hearn wrote: post #17
twoodfin wrote: post #8

Earlier quoted context omitted.

Yeah, would love to see the CPU vendors invent some primitives to let user code pull those kinds of privilege isolation tricks within a single process and address space. 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…”

It exists, that's called MPKs.

I don’t think MPK’s will fit the need I have. Simply: Run some arbitrary, untrusted, non-sandboxed code in the same thread with assurance it can’t read page X. When that code completes and I’m back in code I trust, X is readable 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?

Re: How ZGC allocates memory for the Java heap

#19

Post by mike_hearn »

twoodfin wrote: post #18
mike_hearn wrote: post #17

Earlier quoted context omitted.

It exists, that's called MPKs.

I don’t think MPK’s will fit the need I have. Simply: Run some arbitrary, untrusted, non-sandboxed code in the same thread with assurance it can’t read page X. When that code completes and I’m back in code I trust, X is readable 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 arbit…

Oracle Labs has tech that does that:

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.

Re: How ZGC allocates memory for the Java heap

#20

Post by twoodfin »

mike_hearn wrote: post #19
twoodfin wrote: post #18

Earlier quoted context omitted.

I don’t think MPK’s will fit the need I have. Simply: Run some arbitrary, untrusted, non-sandboxed code in the same thread with assurance it can’t read page X. When that code completes and I’m back in code I trust, X is readable 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 arbit…

Oracle Labs has tech that does that: 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.

Wow. Neat trick and exactly the kind of thing I was looking for.

Thanks!

EDIT: Looks like this is the relevant paper from the Graal team: https://www.graalvm.org/resources/articles/binsweep.pdf

Post reply on HN