On Mon Aug 24, 2026 at 12:40 AM CEST, Kumar Kartikeya Dwivedi wrote: > On Sat Aug 22, 2026 at 12:39 AM CEST, Alexis Lothoré (eBPF Foundation) wrote: >> Add a basic KASAN test runner that loads and test-run programs that can >> trigger memory management bugs. The test captures kernel logs and ensure >> that the expected KASAN splat is emitted by searching for the >> corresponding first lines in the report, hence validated that the needed >> instrumentation has been inserted by the JIT compiler before the >> relevant memory accesses. To allow each test to trigger the expected >> report, the kernel must run with the kasan_multi_shot configuration. >> >> The runner covers different cases and settings: in the nominal case, it >> validates kasan reports on basic instructions (on all supported accesses >> sizes) but also when report _should not_ be emitted (eg: for accesses on >> program stack). The runner also comes with a few specialized tests that >> are then not executed for all sizes/locations: >> - specific atomic ops >> - test for instructions involving different verifier states, with some >> states flagging memory as stack, and other states as non-stack memory >> - tests that validate the stack marking shifting when a patch is emitted >> by the verifier (zext/rnd_hi32, constant blindind). >> Most of those tests are able to trigger kasan reports by altering the >> shadow memory (triggering faulty accesses is otherwise complex, because >> of the verifier). A few tests trigger actual faulty accesses (eg >> out-of-bound accesses) >> >> A few of those tests depends on cpuv4 (load_acquire and store_release). >> >> # ./test_progs -a kasan >> #171/1 kasan/st_1_not_on_stack:OK >> #171/2 kasan/st_1_on_stack:OK >> #171/3 kasan/st_2_not_on_stack:OK >> #171/4 kasan/st_2_on_stack:OK >> #171/5 kasan/st_4_not_on_stack:OK >> #171/6 kasan/st_4_on_stack:OK >> #171/7 kasan/st_8_not_on_stack:OK >> #171/8 kasan/st_8_on_stack:OK >> #171/9 kasan/stx_1_not_on_stack:OK >> #171/10 kasan/stx_1_on_stack:OK >> #171/11 kasan/stx_2_not_on_stack:OK >> #171/12 kasan/stx_2_on_stack:OK >> #171/13 kasan/stx_4_not_on_stack:OK >> #171/14 kasan/stx_4_on_stack:OK >> #171/15 kasan/stx_8_not_on_stack:OK >> #171/16 kasan/stx_8_on_stack:OK >> #171/17 kasan/ldx_1_not_on_stack:OK >> #171/18 kasan/ldx_1_on_stack:OK >> #171/19 kasan/ldx_2_not_on_stack:OK >> #171/20 kasan/ldx_2_on_stack:OK >> #171/21 kasan/ldx_4_not_on_stack:OK >> #171/22 kasan/ldx_4_on_stack:OK >> #171/23 kasan/ldx_8_not_on_stack:OK >> #171/24 kasan/ldx_8_on_stack:OK >> #171/25 kasan/simple_atomic_4_not_on_stack:OK >> #171/26 kasan/simple_atomic_4_on_stack:OK >> #171/27 kasan/simple_atomic_8_not_on_stack:OK >> #171/28 kasan/simple_atomic_8_on_stack:OK >> #171/29 kasan/simple_atomic_fetch:OK >> #171/30 kasan/simple_atomic_fetch:OK >> #171/31 kasan/load_acquire_1_not_on_stack:SKIP >> #171/32 kasan/load_acquire_1_on_stack:SKIP >> #171/33 kasan/load_acquire_2_not_on_stack:SKIP >> #171/34 kasan/load_acquire_2_on_stack:SKIP >> #171/35 kasan/load_acquire_4_not_on_stack:SKIP >> #171/36 kasan/load_acquire_4_on_stack:SKIP >> #171/37 kasan/load_acquire_8_not_on_stack:SKIP >> #171/38 kasan/load_acquire_8_on_stack:SKIP >> #171/39 kasan/store_release_1_not_on_stack:SKIP >> #171/40 kasan/store_release_1_on_stack:SKIP >> #171/41 kasan/store_release_2_not_on_stack:SKIP >> #171/42 kasan/store_release_2_on_stack:SKIP >> #171/43 kasan/store_release_4_not_on_stack:SKIP >> #171/44 kasan/store_release_4_on_stack:SKIP >> #171/45 kasan/store_release_8_not_on_stack:SKIP >> #171/46 kasan/store_release_8_on_stack:SKIP >> #171/47 kasan/ldx_patched:OK >> #171/48 kasan/ldx_patched:OK >> #171/49 kasan/verifier_paths_stack_and_non_stack:OK >> #171/50 kasan/ldx_oob_1_not_on_stack:OK >> #171/51 kasan/ldx_oob_2_not_on_stack:OK >> #171/52 kasan/ldx_oob_4_not_on_stack:OK >> #171/53 kasan/ldx_oob_8_not_on_stack:OK >> #171/54 kasan/st_blinded:OK >> #171 kasan:OK (SKIP: 16/54) >> Summary: 1/38 PASSED, 16 SKIPPED, 0 FAILED >> >> Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]> >> --- > > 1. Should this test be made serial to make sure bpf_jit_harden sysctl change > doesn't affect other tests? > 2. Clang currently collapses the intended ST/STX distinction for *_on_stack > tests: default/v3 emits STX for both pairs, cpuv4 emits ST for both, and the > default st_blinded object is already STX and therefore is not blinded. Please > check and assert that xlated insns are correct in the test itself if possible. > It might be necessary to use asm volatile assembly blocks in case you cannot > work around the compiler in C.
For 2, I guess as a whole you still get coverage, since we run with both cpu versions in CI. So it should be fine I guess, for the blinded case too, but perhaps it would still make sense and be clearer to verify and only enable st case for v4, and force stx to remain stx on v4.
