We're adding support for counting and/or sampling on the static kernel
tracepoints in traced_perf (via perf_event_open). This requires traslating
a human-readable tracepoint name to its id for the running kernel.
For that, we need to read the "id" files like:
/sys/kernel/tracing/events/sched/sched_switch/id
While the current implementation should only need "file r_file_perms",
as it constructs the full path to the id file, I've also added the
directory-level rule to allow for a possible change in implementation,
as we might want to enumerate all available events ahead of time, which
would require listing the tracefs events/ dir.
The changed neverallow macro was a copypaste mistake.
Example denials without the change:
avc: denied { read } for name="id" dev="tracefs" ino=5721
scontext=u:r:traced_perf:s0 tcontext=u:object_r:debugfs_tracing:s0
tclass=file permissive=1
avc: denied { open } for
path="/sys/kernel/tracing/events/sched/sched_switch/id" dev="tracefs"
ino=5721 scontext=u:r:traced_perf:s0
tcontext=u:object_r:debugfs_tracing:s0 tclass=file permissive=1
avc: denied { getattr } for
path="/sys/kernel/tracing/events/sched/sched_switch/id" dev="tracefs"
ino=5721 scontext=u:r:traced_perf:s0
tcontext=u:object_r:debugfs_tracing:s0 tclass=file permissive=1
Tested: collected a profile sampled on "sched/sched_switch" on
crosshatch-userdebug.
Bug: 170284829
Bug: 178961752
Change-Id: I75427e848ccfdc200c5f9b679ea18fc78e1669d6
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 tracing daemon interfaces with perf_events, and is used for
callstack sampling. Currently, we only handle userspace stacks. We
have the ability to collect kernel frame addresses (as unwound
by the kernel itself), but need /proc/kallsyms to symbolize them.
This patch mirrors what was done for traced_probes (ftrace event
kptr symbolization) in aosp/1455337 - the daemon can set a sysprop
that causes "init" to temporarily relax kptr_restrict, then the daemon
can open and read /proc/kallsyms. After the file is parsed, the
kptr_restrict value is restored.
To reiterate, this is confined to userdebug_or_eng due to the reasons
outlined in go/perfetto-kallsyms.
Bug: 173124818
Change-Id: I9077bbfe6fea3318f4c37947a5c455061ca43d8d
* allow shell to enable/disable the daemon via a sysprop
* don't audit signals, as some denials are expected
* exclude zygote from the profileable set of targets on debug builds.
I've not caught any crashes in practice, but believe there's a
possibility that the zygote forks while holding a non-whitelisted fd
due to the signal handler.
Change-Id: Ib237d4edfb40b200a3bd52e6341f13c4777de3f1
The steps involved in setting up profiling and stack unwinding are
described in detail at go/perfetto-perf-android.
To summarize the interesting case: the daemon uses cpu-wide
perf_event_open, with userspace stack and register sampling on. For each
sample, it identifies whether the process is profileable, and obtains
the FDs for /proc/[pid]/{maps,mem} using a dedicated RT signal (with the
bionic signal handler handing over the FDs over a dedicated socket). It
then uses libunwindstack to unwind & symbolize the stacks, sending the
results to the central tracing daemon (traced).
This patch covers the app profiling use-cases. Splitting out the
"profile most things on debug builds" into a separate patch for easier
review.
Most of the exceptions in domain.te & coredomain.te come from the
"vendor_file_type" allow-rule. We want a subset of that (effectively all
libraries/executables), but I believe that in practice it's hard to use
just the specific subtypes, and we're better off allowing access to all
vendor_file_type files.
Bug: 137092007
Change-Id: I4aa482cfb3f9fb2fabf02e1dff92e2b5ce121a47
