Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 894fca7c authored by Ryan Savitski's avatar Ryan Savitski
Browse files

framework media seccomp: allow syscalls made by dynamic profilers within the process context

There are potential memory leaks in at least media.swcodec, which heap
profiling can help with (see linked bug). However the profiling requires
making some socket-related syscalls from within the process, which are
currently blocked by the media seccomp policy.

This patch adds the necessary extra syscalls to allow for profiling of
select media processes on arm64 devices. Note that several socket
operations have always been allowed, even when not explicitly listed in
these policy files. This is because external/minijail/util.c allowlists
logging-related syscalls by default, which on Android requires the use
of sockets (connect, fcntl, sendto, socket, writev). Even if this wasn't
the case, some of these syscalls would still be needed for crash_dump to
work.

I've edited the framework files directly for the short term, and will
look at a more maintainable solution for the future (likely moving to
@include-able files as with crash_dump and code_coverage).

Tested and verified on sc-dev userdebug device (with
MODULE_BUILD_FROM_SOURCE=true):
* arm64 media.extractor profileable and doesn't crash
* arm64 media.swcodec profileable and doesn't crash

Limitations:
* not addressing arm32 or x86 policies as I don't have the appropriate
  devices to test with, and I'm assuming that arm64 is of main interest
  for the profiling investigation in the short term anyway.
* not addressing media.codec (/vendor/bin/hw/android.hardware.media.omx@1.0-service)
  as I don't understand why its arm64 policy is a copypaste of arm32, as
  well as being unable to test the process in practice (unsure how to
  trigger allocations in it for the heap profiler).
* this doesn't cover other media processes, including some vendor
  things.

I'm happy to reduce the scope of the patch to just swcodec, or otherwise
cover more architectures if they're considered critical. Looking for
reviewer input on that, as I'm not familiar with these processes.

Bug: 197184220
Bug: 198421643
Merged-In: I7815e9e00514e20ff41d4eabeb779113b0519a87
Change-Id: I7815e9e00514e20ff41d4eabeb779113b0519a87
parent eaa689fd
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment