Avoid repeated ASLR re-exec attempts

[kiwigitops]

Summary

• add an environment sentinel before re-execing after ADDR_NO_RANDOMIZE is set
• skip the re-exec if the process already attempted the ASLR-disable path once
• avoid re-execing if the sentinel cannot be recorded

Context

This addresses the AppArmor case from #2184 where personality() reports ADDR_NO_RANDOMIZE as set before execv(), but the new process image loses that flag and re-enters the same code path forever.

Testing

• git diff --check

I did not add a direct unit test because the behavior depends on Linux exec/personality interaction under an AppArmor-constrained process tree.

[LebedevRI]

Why is this an array of strings if we only need a single string?

[kiwigitops]

Updated to use a constexpr const char* for the env var name.

[kiwigitops]

Quick follow-up on this. I addressed the env-var naming feedback, but it looks non-mergeable now. Happy to refresh it against main if the approach looks okay.

[LebedevRI]

Still no real reply from devs on https://bugs.launchpad.net/bugs/2153650 :(
I wonder if it's worth filing an issue upstream at https://gitlab.com/apparmor/apparmor-kernel, they would for sure know if this is a bug or not...

[kiwigitops]

Yeah, upstream sounds like the right next place to ask. If someone opens an issue there and links it back here, I can follow along from this PR.

[LebedevRI]

Yeah, upstream sounds like the right next place to ask. If someone opens an issue there and links it back here, I can follow along from this PR.

https://gitlab.com/apparmor/apparmor/-/work_items/647

[LebedevRI]

Yeah, upstream sounds like the right next place to ask. If someone opens an issue there and links it back here, I can follow along from this PR.

https://gitlab.com/apparmor/apparmor/-/work_items/647

@kiwigitops and there's a response: https://gitlab.com/apparmor/apparmor/-/work_items/647#note_3475169287
Would it be possible for you to reply there?
Thank you!

[kiwigitops]

Thanks for following up. I don't have access to comment on GitLab directly. If the relevant question or conclusion can be mirrored here, I can respond from this PR.

[LebedevRI]

John Johansen @jjohansen 15 hours ago Owner
Thanks for the report. Can you turn on debug mode

sudo bash -c "echo 1" > /sys/module/apparmor/parameters/debug

run the command again, and then check dmesg. I am expecting you will see a message starting with
apparmor: clearing unsafe personality bits. label=
If this is the case what is the label, we will have to look at the exec rule and switch it to unsafe mode.

[kiwigitops]

I did a fresh local verification pass on this branch: CMake/Ninja build succeeds and ctest passes 85/85.

For the AppArmor follow-up, the useful data point is the apparmor: clearing unsafe personality bits. label=... line from the affected Linux profile. That label determines which exec rule is clearing ADDR_NO_RANDOMIZE; running the debug step on an unrelated host would not identify the profile behind the reported loop. If that line can be pasted here, I can adjust this PR if the right fix turns out to be narrower than the current benchmark-side one-shot guard.

[LebedevRI]

For the AppArmor follow-up, the useful data point is the apparmor: clearing unsafe personality bits. label=... line from the affected Linux profile. That label determines which exec rule is clearing ADDR_NO_RANDOMIZE; running the debug step on an unrelated host would not identify the profile behind the reported loop. If that line can be pasted here, I can adjust this PR if the right fix turns out to be narrower than the current benchmark-side one-shot guard.

(Um, why does this look like LLM spew?)
Is there output in dmesg or not?

[kiwigitops]

No, I do not have the requested dmesg output.

Sorry, I wrote that badly. I checked the linked Launchpad/GitLab threads; they have the reproducer/environment details, but I do not see the apparmor: clearing unsafe personality bits. label=... line there. The local ctest result only verifies the benchmark branch and does not answer the AppArmor question.

I will hold off on further AppArmor claims until I can provide that host output.

[LebedevRI]

No, I do not have the requested dmesg output.

Sorry, I wrote that badly.

Sorry.

I checked the linked Launchpad/GitLab threads; they have the reproducer/environment details, but I do not see the apparmor: clearing unsafe personality bits. label=... line there. The local ctest result only verifies the benchmark branch and does not answer the AppArmor question.

I will hold off on further AppArmor claims until I can provide that host output.

Just to be sure, you are trying to repro on a main branch, not on the fix branch,
and just to be sure, doing so right after a fresh reboot just in case it only spews into dmesg the first time?

[kiwigitops]

Good check.

I tested current google/benchmark main on a freshly provisioned Ubuntu 24.04 runner, not this branch. The main SHA was 5bfa2bd77f30e69af99bc511235741220d68fe04.

Results from a minimal BENCHMARK_MAIN() binary:

• unconfined: exited normally
• throwaway aa-exec AppArmor profile: exited normally
• throwaway attached AppArmor profile: exited normally; dmesg showed profile_transition: unconfined attached to new label / bench-attached
• no apparmor: clearing unsafe personality bits. label=... line

So I still cannot reproduce the original VS Code/AppArmor loop on that host.

[LebedevRI]

Hm, but did you try reproducing from within VSCode, where it initially happened?
I would not be surprized if it is doing some extra security hardening, causing this.
I think best bet is to report this to VSCode next.

[kiwigitops]

Fair point. I did not reproduce this from inside VS Code itself; the checks above were plain shell plus throwaway AppArmor profiles.

I do not have the original VS Code/AppArmor environment locally, and I do not want to file a VS Code report from an unconfirmed repro. I am going to leave this PR open for now, but I am not going to chase the VS Code-specific path further without a local repro.