test: run dbus-broker under ASan and UBsan

[mrc0mmand]

Let's introduce a test that runs dbus-broker under Address Sanitizer and Undefined Behavior Sanitizer, while running other tests against it.

The setup to achieve this is slightly convoluted, since we need to run (and restart) sanitized dbus-broker without nuking the host machine. For that we setup an nspawn-container that re-uses host's rootfs (to some degree) and overlays our additions on top of that. This way we can test (not-only) the full user-space boot with sanitized dbus-broker without risking "damage" to the host machine.

[mrc0mmand]

@evverx as promised here's a PoC of a test that runs dbus-broker under ASan and UBSan while we hammer it with other tests on the side. It got slightly more involved to protect the host machine, and LSan needed some extra care as well (see the comments in the test code).

It's different from the original idea of running existing tests on a sanitized build, since I currently have no clue how to incorporate this into the whole Packit/TestingFarm infra (and I'm also not quite sure how well it would handle dying dbus and collecting artifacts from such machines).

If I run the test in one of my Arch VMs against the latest upstream, it reports a leak after I run dfuzzer just on the D-Bus control interface, so it looks like it's doing something :)

# TMT_TEST_DATA=~/logs DBUS_BROKER_TREE=$PWD test/integration/fuzz/sanitizers/test.sh
...
[688762.734598] dbus-broker[66]: A security policy denied :1.16 to send method call /org/freedesktop/DBus:org.freedesktop.DBus.Peer.GetMachineId to org.freedesktop.DBus.
[688762.735575] dbus-broker[66]: A security policy denied :1.16 to send method call /org/freedesktop/DBus:org.freedesktop.DBus.Peer.Ping to org.freedesktop.DBus.
[688763.062724] dbus-broker[66]: Dispatched 1954 messages @ 198(±297)μs / message.
[688763.063133] systemd[1]: Stopping D-Bus System Message Bus...
[688763.105139] dbus-broker-launch[65]: =================================================================
[688763.105437] dbus-broker-launch[65]: ==65==ERROR: LeakSanitizer: detected memory leaks
[688763.105437] dbus-broker-launch[65]: Direct leak of 880 byte(s) in 10 object(s) allocated from:
[688763.105564] dbus-broker-launch[65]:     #0 0x75fe014e2cc1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
[688763.105564] dbus-broker-launch[65]:     #1 0x5b9d8d5fe8f7 in policy_record_new_xmit ../src/launch/policy.c:56
[688763.105564] dbus-broker-launch[65]:     #2 0x5b9d8d609364 in policy_import_send ../src/launch/policy.c:460
[688763.105564] dbus-broker-launch[65]:     #3 0x5b9d8d60f44f in policy_import ../src/launch/policy.c:696
[688763.105564] dbus-broker-launch[65]:     #4 0x5b9d8d5c018b in launcher_load_policy ../src/launch/launcher.c:1096
[688763.105564] dbus-broker-launch[65]:     #5 0x5b9d8d5c1943 in launcher_reload_config ../src/launch/launcher.c:1195
[688763.105564] dbus-broker-launch[65]:     #6 0x5b9d8d5c240c in bus_method_reload_config ../src/launch/launcher.c:1296
[688763.105564] dbus-broker-launch[65]:     #7 0x75fe0131b45c  (/usr/lib/libsystemd.so.0+0x2f45c) (BuildId: 540b0b05a1f8668a797c3ff583cd0b19ff6962f4)
[688763.105564] dbus-broker-launch[65]:     #8 0x75fe01334b1a  (/usr/lib/libsystemd.so.0+0x48b1a) (BuildId: 540b0b05a1f8668a797c3ff583cd0b19ff6962f4)
[688763.105734] dbus-broker-launch[65]: Direct leak of 88 byte(s) in 1 object(s) allocated from:
[688763.105877] dbus-broker-launch[65]:     #0 0x75fe014e2cc1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
[688763.105877] dbus-broker-launch[65]:     #1 0x5b9d8d5fe8f7 in policy_record_new_xmit ../src/launch/policy.c:56
[688763.105877] dbus-broker-launch[65]:     #2 0x5b9d8d609364 in policy_import_send ../src/launch/policy.c:460
[688763.105877] dbus-broker-launch[65]:     #3 0x5b9d8d60f44f in policy_import ../src/launch/policy.c:696
[688763.105877] dbus-broker-launch[65]:     #4 0x5b9d8d5c018b in launcher_load_policy ../src/launch/launcher.c:1096
[688763.105877] dbus-broker-launch[65]:     #5 0x5b9d8d5c313f in launcher_run ../src/launch/launcher.c:1347
[688763.105877] dbus-broker-launch[65]:     #6 0x5b9d8d5b270c in run ../src/launch/main.c:151
[688763.105877] dbus-broker-launch[65]:     #7 0x5b9d8d5b2949 in main ../src/launch/main.c:174
[688763.105877] dbus-broker-launch[65]:     #8 0x75fe00b1cccf  (/usr/lib/libc.so.6+0x25ccf) (BuildId: c0caa0b7709d3369ee575fcd7d7d0b0fc48733af)
[688763.106017] dbus-broker-launch[65]: SUMMARY: AddressSanitizer: 968 byte(s) leaked in 11 allocation(s).
[688763.115803] systemd[1]: dbus-broker.service: Main process exited, code=exited, status=1/FAILURE
[688763.115956] systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
[688763.116408] systemd[1]: Stopped D-Bus System Message Bus.
[688763.116595] systemd[1]: dbus-broker.service: Consumed 2.112s CPU time, 142.2M memory peak, 0B memory swap peak

But it doesn't appear to ... appear in CI, interesting.

[evverx]

If I run the test in one of my Arch VMs against the latest upstream, it reports a leak after I run dfuzzer just on the D-Bus control interface, so it looks like it's doing something. But it doesn't appear to ... appear in CI, interesting

I'm guessing the policy triggering it isn't included in the Fedora base image used by the CI. It should probably be possible to track that policy down by removing the policies on the Arch VM one by one.

[mrc0mmand]

@evverx I factored out the common parts into a separate utility script, prepped another test that runs dbus-broker under Valgrind, and it seems to work (or at least Valgrind seem to complain a lot). However, it will need a bit more polish I'll move the last two commits into a separate branch with the next push (which might take a bit, as I'll like to gather some coverage reports for the sanitized dbus-broker to see how we could improve the ASan+UBSan test), so it doesn't block the sanitizer test.

[evverx]

@mrc0mmand I agree that Valgrind shouldn't block this PR. As far as I can remember the launcher should be tweaked too to run dbus-broker under Valgrind and some syscalls should be instrumented. The backtraces came with PID fds as far as I can remember.