search

intel / ccc-linux-guest-hardening

Linux Security Hardening for Confidential Compute
https://intel.github.io/ccc-linux-guest-hardening-docs
MIT License
63 stars 13 forks source link

Default configs for fuzzing harnesses do not follow kafl reccomendations #109

Open ereshetova opened 1 year ago

ereshetova commented 1 year ago

The default recommended setup for kafl tdx fuzzing is:

config TDX_FUZZ_KAFL_USE_RECOMMENDED bool "Use recommended options" depends on TDX_FUZZ_KAFL && !JUMP_LABEL && !DYNAMIC_FTRACE && !KPROBES select UNWINDER_FRAME_POINTER select TDX_FUZZ_KAFL_DETERMINISTIC select TDX_FUZZ_KAFL_SKIP_PARAVIRT_REWRITE select TDX_FUZZ_KAFL_SKIP_CPUID default y help Select recommended options for kAFL fuzzing.

  - Framepointer stack unwinder (ORC can cause libxdc decode errors)
  - Skip CPUID fuzzing (false positives, does not model real platform)

  Self-modifying will often conflict wiht the libxdc page cache,
  so try to avoid these for final/production harnesses:
  jump labels, paravirt, ftrace, kprobe, ...

However, the guest kernel config that we generate doesn't fully obey this. Namely KPROBES are on.

il-steffen commented 1 year ago

Note that init_harness.py also generates kernel config snippets in the template folder. fuzz.sh build picks them up to override the default config from bkc/. If you start copying kernel or qemu configs around, this is not the same harness anymore.

ereshetova commented 1 year ago

I meant that we need to ensure that the configuration templates for each harness are proper. But I guess to your point, KPROBES are actually needed in cases when CONFIG_TDX_FUZZ_HARNESS_NONE is used, so just need to carefully double check all the harness templates.

ereshetova commented 1 year ago

In addtion we have discussed yesterday with Sebastian that some harness options in init_harness.py might be enabling devices that are not needed (like virtio-rng) or duplicated, so at the same time need to slightly clean up options in init_harness.py.