If a ProbeFunction subtype interacts with the hardware, you probably need to run the function in a separated minijail sandbox. For example, the generic_battery
function has the following files:
Files sandbox/generic_battery.args
and sandbox/${ARCH}/generic_battery-secomp.policy
will be installed under /etc/runtime_probe/sandbox/
in the rootfs.
When evaluating a probe config, the probe config might want to probe battery by using generic_battery
probe function. In this case, GenericBattery::Eval()
will be called. The GenericBattery::Eval()
function calls GenericBattery::InvokeHelper()
(which is inherited from ProbeFunction
base class). The helper function invokes a DBus call, calling method EvaluateProbeFunction
of debugd
. The function will start a sandboxed process (using minijail), which should be equivalent to:
# Check platform2/debugd/src/probe_tool.cc for the up-to-date version. # sandbox/generic_battery.args is a JSON serialized list. ARGS="$(jq -r .[] <"/etc/runtime_probe/sandbox/generic_battery.args")" POLICY="/etc/runtime_probe/sandbox/generic_battery-seccomp.policy" minijail0 \ -v \ -u runtime_probe -g runtime_probe \ -S "${POLICY}" \ -n \ -G \ -P /mnt/empty \ -b / \ -b /proc \ -b /dev/log \ -t \ -r \ -d \ ${ARGS} \ -- \ /usr/bin/runtime_probe \ --helper \ -- \ '{"generic_battery": {}}'
You can use the commands above to test it on your device. If there are permission / policy errors, you can add -L
to get more details about the violation (the blocked system call will be printed to syslog).
Checkout Sandboxing Chrome OS system services to learn more about minijail options.
The helper process starts in the created sandbox, and the GenericBattery::EvalInHelper()
will be called, which should be the real implementation of the probe function.