4 ms·

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 addre

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…”

hinkley 2y ago
Thread based seems like it at least should be possible.
ahartmetz 2y ago
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.
- twoodfin 2y ago
  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.
  - gpderetta 2y ago
    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.
MarkSweep 2y ago
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/memoryapi/nf-memoryapi-getwritewatch https://learn.microsoft.com/en-us/windows/win32/api/memoryap... Or some sort of special write barrier store op-code, idk.
mike_hearn 2y ago
It exists, that's called MPKs.
- twoodfin 2y ago
  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?
  - mike_hearn 2y ago
    Oracle Labs has tech that does that: https://youtu.be/T05FI93MBI8?si=EieFgujaGiW2gbO8&t=958 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.
    - twoodfin 2y ago
      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 https://www.graalvm.org/resources/articles/binsweep.pdf

hinkley 2y ago

Thread based seems like it at least should be possible.

ahartmetz 2y ago

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.

twoodfin 2y ago
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.
- gpderetta 2y ago
  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.

MarkSweep 2y ago

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/memoryapi/nf-memoryapi-getwritewatch https://learn.microsoft.com/en-us/windows/win32/api/memoryap... Or some sort of special write barrier store op-code, idk.

mike_hearn 2y ago

It exists, that's called MPKs.

twoodfin 2y ago
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?
- mike_hearn 2y ago
  Oracle Labs has tech that does that: https://youtu.be/T05FI93MBI8?si=EieFgujaGiW2gbO8&t=958 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.
  - twoodfin 2y ago
    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 https://www.graalvm.org/resources/articles/binsweep.pdf