Fix stack tagging on AArch64 #407
Conversation
fw-immunant
force-pushed
the
fw/arm-stack-fixes
branch
from
517226c to
2b4b7fa
Compare
| @@ -26,6 +26,10 @@ char *allocate_stack(int i) { | |||
| exit(-1); | |||
| } | |||
| } | |||
| #ifdef __aarch64__ | |||
| /* Tag the allocated stack pointer so it is accessed with the right pkey */ | |||
| stack = (char *)((uint64_t)stack | (uint64_t)i << 56); | |||
There was a problem hiding this comment.
are we sure stack's upper bits are initially zero or should we explicitly clear them out first?
This is expected for some instructions using sp. I'll find a link in a sec |
|
Here's what I thought was a bug in QEMU which pointed out that some sp-relative accesses are checked. https://gitlab.com/qemu-project/qemu/-/issues/514. I think it's basically those that access "sp + runtime offset" since that can't be known to access the right thing statically. For example, see |
|
CI here is failing for a really interesting reason: passing tagged pointers into the stack as system call arguments returns |
our |
|
oh I'm guessing it probably needs the |
Ah, yep--that's why it was working when I wrote these commits but not when I pulled them out in to their own PR. |
fw-immunant
force-pushed
the
fw/arm-stack-fixes
branch
from
2b4b7fa to
61dcd7f
Compare
note that this commit does regress simple1, but I believe it does so by unmasking a hidden failure: nonzero return values from the wrapped `main` were getting lost as we clobbered `x0`
fw-immunant
force-pushed
the
fw/arm-stack-fixes
branch
from
61dcd7f to
7b59987
Compare
|
I confirmed visually that only the 4 ARM tests we expect to fail are producing MTE violations in CI:
Next we should make these failures act as test failures in CI and also actually fix them. |
We weren't tagging the entire requested region but only its first page (which also impacted protection of non-stack pages).(Fixed separately.)After allocating and tagging a fresh compartment stack, we returned an untagged pointer to it, which led to MTE violations. I was surprised by this because the violations I observed seemed to come from
sp-relative accesses, which I thought would not perform MTE checks, but they did anyway--it would be good to write a test program to characterize exactly which instructions do and don't perform MTE checks.In addition, we need to apply tags for the access to TLS when accessing
ia2_stackptr_N.