On 5/16/23 00:06, Stephen Röttger wrote:
On Mon, May 15, 2023 at 4:28 PM Dave Hansen dave.hansen@intel.com wrote:
On 5/15/23 06:05, jeffxu@chromium.org wrote:
We're using PKU for in-process isolation to enforce control-flow integrity for a JIT compiler. In our threat model, an attacker exploits a vulnerability and has arbitrary read/write access to the whole process space concurrently to other threads being executed. This attacker can manipulate some arguments to syscalls from some threads.
This all sounds like it hinges on the contents of PKRU in the attacker thread.
Could you talk a bit about how the attacker is prevented from running WRPKRU, XRSTOR or compelling the kernel to write to PKRU like at sigreturn?
(resending without html)
Since we're using the feature for control-flow integrity, we assume the control-flow is still intact at this point. I.e. the attacker thread can't run arbitrary instructions.
Can't run arbitrary instructions, but can make (pretty) arbitrary syscalls?
- For JIT code, we're going to scan it for wrpkru instructions before
writing it to executable memory
... and XRSTOR, right?
- For regular code, we only use wrpkru around short critical sections
to temporarily enable write access
Sigreturn is a separate problem that we hope to solve by adding pkey support to sigaltstack
What kind of support were you planning to add?
I was thinking that an attacker with arbitrary write access would wait until PKRU was on the userspace stack and *JUST* before the kernel sigreturn code restores it to write a malicious value. It could presumably do this with some asynchronous mechanism so that even if there was only one attacker thread, it could change its own value.
Also, the kernel side respect for PKRU is ... well ... rather weak. It's a best effort and if we *happen* to be in a kernel context where PKRU is relevant, we can try to respect PKRU. But there are a whole bunch of things like get_user_pages_remote() that just plain don't have PKRU available and can't respect it at all.
I think io_uring also greatly expanded how common "remote" access to process memory is.
So, overall, I'm thrilled to see another potential user for pkeys. It sounds like there's an actual user lined up here, which would be wonderful. But, I also want to make sure we don't go to the trouble to build something that doesn't actually present meaningful, durable obstacles to an attacker.
I also haven't more than glanced at the code.