odrefresh is the process responsible for checking and creating ART
compilation artifacts that live in the ART APEX data
directory (/data/misc/apexdata/com.android.art).
There are two types of change here:
1) enabling odrefresh to run dex2oat and write updated boot class path
and system server AOT artifacts into the ART APEX data directory.
2) enabling the zygote and assorted diagnostic tools to use the
updated AOT artifacts.
odrefresh uses two file contexts: apex_art_data_file and
apex_art_staging_data_file. When odrefresh invokes dex2oat, the
generated files have the apex_art_staging_data_file label (which allows
writing). odrefresh then moves these files from the staging area to
their installation area and gives them the apex_art_data_file label.
Bug: 160683548
Test: adb root && adb shell /apex/com.android.art/bin/odrefresh
Change-Id: I9fa290e0c9c1b7b82be4dacb9f2f8cb8c11e4895
This simplifies operation by removing a special case for user builds.
Test: atest CtsPerfettoTestCases on user
Test: atest CtsPerfettoTestCases on userdebug
Test: atest perfetto_integrationtests on userdebug
Bug: 153139002
Change-Id: Ibbf3dd5e4f75c2a02d931f73b96fabb8157e0ebf
This allows to profile binaries pushed by the user.
Test: run profile of out of tree perfetto on flame userdebug.
Bug: 170208766
Change-Id: I152d6d244cc5065ee2de24f839e4ad467bc22cdc
This is needed to get Java heap graphs.
Test: flash aosp; profile system_server with setenforce 1
Bug: 136210868
Change-Id: I87dffdf28d09e6ce5f706782422510c615521ab3
This is needed to test the unwinding of test binaries.
03-26 19:55:44.311 939 939 W heapprofd: type=1400 audit(0.0:13): avc: denied { search } for name="nativetest" dev="sda45" ino=6815745 scontext=u:r:heapprofd:s0 tcontext=u:object_r:nativetest_data_file:s0 tclass=dir permissive=0
Change-Id: Icfbc6060a8755934f1c3935aac55ce7792dc7d85
This is needed because some oat dex files are generated without world
readable permissions. See the bug for details.
We are still constrained by the SELinux rules above.
Bug: 129048073
Change-Id: I84e34f83ceb299ff16b29a78f16c620fc0aa5d68
This patch extends the current debug-specific rules to cover user
builds. As a reminder, on user, the target process fork-execs a private
heapprofd process, which then performs stack unwinding & talking to the
central tracing daemon while staying in the target's domain. The central
heapprofd daemon is only responsible for identifying targets & sending
the activation signal. On the other hand, on debug, the central
heapprofd can handle all processes directly, so the necessary SELinux
capabilities depend on the build type.
These rules are necessary but not sufficient for profiling. For zygote
children, the libc triggering logic will also check for the app to
either be debuggable, or go/profileable.
For more context, see go/heapprofd-security & go/heapprofd-design.
Note that I've had to split this into two separate macros, as
exec_no_trans - which is necessary on user, but nice-to-have on debug -
conflicts with a lot of neverallows (e.g. HALs and system_server) for
the wider whitelisting that we do on debug builds.
Test: built & flashed on {blueline-userdebug, blueline-user}, activated profiling of whitelisted/not domains & checked for lack of denials in logcat.
Bug: 120409382
Change-Id: Id0defc3105b99f777bcee2046d9894a2b39c6a29
Arbitrary apps need to connect to heapprofd in order to send samples.
Relevant denial trying to profile com.google.android.inputmethod.latin
on userdebug:
12-20 14:50:20.420 25219 25219 I heapprofd: type=1400 audit(0.0:1006): avc: denied { read } for path="/proc/24819/mem" dev="proc" ino=244219 scontext=u:r:heapprofd:s0 tcontext=u:r:untrusted_app_27:s0:c133,c256,c512,c768 tclass=file permissive=1
Bug: 121370989
Test: m
Test: flash walleye
Test: profile com.google.android.inputmethod.latin
Change-Id: Iee82c8c49951e5a5726cd5ab0b9e8fa71226c802
Heapprofd needs to read binary files and library in order to support
unwinding the stack. sytem_file does not include all thes files, e.g.
zygote_exec is only labeled as system_file_type.
Denials:
12-03 10:50:37.485 9263 9263 I heapprofd: type=1400 audit(0.0:177): avc: denied { read } for name="app_process64" dev="dm-0" ino=2286 scontext=u:r:heapprofd:s0 tcontext=u:object_r:zygote_exec:s0 tclass=file permissive=1
12-03 10:50:37.485 9263 9263 I heapprofd: type=1400 audit(0.0:178): avc: denied { open } for path="/system/bin/app_process64" dev="dm-0" ino=2286 scontext=u:r:heapprofd:s0 tcontext=u:object_r:zygote_exec:s0 tclass=file permissive=1
12-03 10:50:37.485 9263 9263 I heapprofd: type=1400 audit(0.0:179): avc: denied { getattr } for path="/system/bin/app_process64" dev="dm-0" ino=2286 scontext=u:r:heapprofd:s0 tcontext=u:object_r:zygote_exec:s0 tclass=file permissive=1
Change-Id: Ie04b722a78ff6367729930ee0ef96f48ccf6aa55
Bug: 117762471
This is world-readable so it can be checked in libc's process init.
Test: m
Test: flash sailfish
Bug: 117821125
Change-Id: Iac7317ceb75b5ad9cfb9adabdf16929263fa8a9d
This does not actually grant any permissions but just adds the
necessary boilerplate for a new service.
Bug: 117762471
Bug: 117761873
Change-Id: I7cdd2ae368616cfd54fc685c15f775604bfc80d4
