Add sanitizer support via score_cpp_policies

[VukPavicRTRK]

Description

Integrates ASan, UBSan, LSan, and TSan using the centralized score_cpp_policies infrastructure rather than a self-contained implementation, avoiding fragmentation across S-CORE modules.

Changes

MODULE.bazel

• Adds score_cpp_policies as a dev_dependency via git_override (not yet in the bazel_registry).

.bazelrc

• Adds --build_tests_only to both sanitizer configs — without this, --test_tag_filters only gates test execution; Bazel's wildcard expansion would still attempt to build excluded targets (e.g. Rust binaries that cannot link under sanitizers), failing the build before any tests run.
• Adds sanitizer configs backed by score_cpp_policies' runtime infrastructure (wrapper script, suppression files, env templates):
  • --config=asan_ubsan_lsan — AddressSanitizer + UBSan + LeakSanitizer
  • --config=tsan — ThreadSanitizer (separate run, incompatible with ASan)
  • --config=asan / --config=ubsan / --config=lsan — convenience aliases
  • Tag filters (-no-asan, -no-tsan, etc.) are baked into each config

Note: flags are applied via --copt/--linkopt directly rather than --features=score_asan_ubsan_lsan, because score_bazel_cpp_toolchains does not yet expose the cc_feature targets from score_cpp_policies. The wrapper, suppression files, and flag infrastructure from score_cpp_policies are fully used.

.github/workflows/sanitizers.yml

• CI job running both configs against //src/... //tests/... on every PR, merge group, and push to main. The TSan job sets kernel.randomize_va_space=0 to satisfy TSan's shadow memory layout requirements in the GitHub Actions runner.

src/health_monitoring_lib/BUILD

• Tagged tests and loom_tests no-asan/no-tsan — Rust binaries incompatible with sanitizer linking.
• Tagged cpp_tests no-asan/no-tsan — links uninstrumented Rust code, producing false positives under both ASan and TSan.

src/.../common/concurrency/BUILD

• Removes mpmc_concurrent_queue_tsan_test, which had hardcoded -fsanitize=thread copts/linkopts that would double-instrument the binary under --config=tsan. The regular mpmc_concurrent_queue_test now covers TSan via the global config.
• Tagged mpmc_concurrent_queue_test no-asan — benign UBSan alignment false-positive on ASan's fake stack. Test remains active under TSan.

src/.../process_state_client_lib/BUILD

• Tagged processstateclient_UT no-tsan — the IPC overflow path returns an incorrect error code under TSan's forced -O1 build. Test remains active under ASan/UBSan/LSan.

tests/utils/bazel/integration.bzl

• Excluded all Docker integration tests at the macro level — the daemon cannot start in containers that lack the sanitizer runtime.

Notes

Each tag exclusion is scoped as narrowly as possible: tests are only skipped for the sanitizer(s) where the failure is a known false positive or environmental limitation. Re-enabling any of them is a matter of removing the relevant tag once the underlying issue is resolved upstream.

Running locally

ASan + UBSan + LSan

bazel test --config=asan_ubsan_lsan --config=x86_64-linux //src/... //tests/...

ThreadSanitizer

Requires ASLR to be in conservative mode.

sudo sysctl -w kernel.randomize_va_space=0
bazel test --config=tsan --config=x86_64-linux //src/... //tests/...

Closes #50

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 53491268-4d45-4912-b231-9afbdcc3f912
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (40 packages loaded, 10 targets configured)

Analyzing: target //:license-check (100 packages loaded, 61 targets configured)

Analyzing: target //:license-check (144 packages loaded, 4957 targets configured)

Analyzing: target //:license-check (154 packages loaded, 5429 targets configured)

Analyzing: target //:license-check (154 packages loaded, 5429 targets configured)

Analyzing: target //:license-check (158 packages loaded, 8212 targets configured)

Analyzing: target //:license-check (161 packages loaded, 10106 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 10232 targets configured).
[12 / 16] [Prepa] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes
[13 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox
[15 / 16] [Sched] Building license.check.license_check.jar ()
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 20.996s, Critical Path: 2.54s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[FScholPer]

be aware there is also going work in that direction in score_cpp_policies repo

[VukPavicRTRK]

be aware there is also going work in that direction in score_cpp_policies repo

Should lifecycle continue with the self-contained sanitizer implementation in this PR as a short-term unblocker, planning a later migration to the shared score_cpp_policies module once its sanitizer structure stabilizes or do we want to pivot now and integrate directly with the centralized sanitizer infrastructure despite the potential dependency and release-readiness risks?

[FScholPer]

My opinion: I would say we should bring in our thoughts into score_cpp_policies and not create silos. @NicolasFussberger @S-MOHAMD @pawelrutkaq any thoughts on this?

[NicolasFussberger]

My opinion: I would say we should bring in our thoughts into score_cpp_policies and not create silos. @NicolasFussberger @S-MOHAMD @pawelrutkaq any thoughts on this?

If we can bring in these changes into score_cpp_policies, I agree that this should be the preferred solution. I cannot judge how realistic this is.

[NicolasFussberger]

What is the problem that shows up with ASLR?
Locally I am not encountering a problem with ASLR enabled.

There is also this ticket llvm/llvm-project#164989 which suggests

build and link our sanitizer tests with -no-pie

I am asking because I wonder if there is a security concern with disabling ASLR here.