summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorPeter Collingbourne <pcc@google.com>2021-03-25 11:46:44 -0700
committerVinay Verma <vvinay@codeaurora.org>2021-04-13 11:29:57 +0530
commite64cd5c8c72d71616223999f9b21933f9c2c3c3f (patch)
treec8190641dc7e2315ddf4c8fb538899621dade627 /tools/aapt2/java/JavaClassGenerator_test.cpp
parentfc93e03899449d6f02f9c766e2f6c9359dd2453b (diff)
Reset PAC keys on thread creation instead of on zygote fork.
Resetting PAC keys on fork appears to lead to a number of problems. One problem is that we are constrained in where we can run C++ code after forking, and with ART those places are implementation-defined. For example, in app zygotes, ART turns out to insert "interpreter frames" in the stack trace. Returning into these interpreter frames may lead to crashes due to failing the ROP protection check on return. It seems better to reset keys on thread creation instead. We only need to reset IA because only this key needs to be reset for reverse-edge PAC, and resetting the other keys may be incompatible with future ABIs. Chrome (and potentially other applications) has a sandbox that prevents the use of the prctl, so we restrict its use to applications targeting S and above. Bug: 183024045 CRs-Fixed: 2918473 (cherry picked from commit de2906af9c7b48cc27d94824342c7a96048d3e1c) Change-Id: I1e6502a7d7df319d424e2b0f653aad9a343ae71b
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions