Repository navigation
General lack of .config control exposed by fuzzer .config divergence #9386
Description
Originally posted by @marc-hb in #9343 (comment)
Even if #9356 is perfect, it does not change anything to the apparently messy Kconfig situation... @andyross could you help there? Should CONFIG_INCOHERENT really be gated by CONFIG_XTENSA? Can we align
build-fuzz/.configwithbuild/.configmore? Some differences are unavoidable but they should be as small as possible: fuzzing something different from the product is both dangerous and a bit of a waste.
Let's compare the default build-mtl/zephyr/.config with build-fuzz/zephyr/.config as of today's SOF commit 1009ba7
./scripts/xtensa-build-zephyr.py -p mtl
./scripts/fuzz.sh -p -b -- -DCONFIG_IPC_MAJOR_4=y
diff ../build-mtl/zephyr/.config build-fuzz/zephyr/.config | diffstat
unknown | 617 ++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------------------------------------------------------------------
1 file changed, 186 insertions(+), 431 deletions(-)
That's a lot. Some of these differences are unavoidable because they are "hardware"-dependent, for instance: CONFIG_DT_HAS_CDNS_TENSILICA_XTENSA_LX7_ENABLED or CONFIG_ZEPHYR_POSIX_FUZZ_IRQ. Other diffferences are wrong because they are "pure software" like CONFIG_AMS or CONFIG_SOF_TELEMETRY. Can these last two software features affect fuzzing? Maybe, maybe not: we don't want to know. Pure software differences should be as small as possible, period. That is: if we want to fuzz and find security issues in code used in production.
So where do CONFIG_AMS and CONFIG_SOF_TELEMETRY come from?
sof]$ git grep CONFIG_AMS
app/boards/intel_adsp_ace15_mtpm.conf:CONFIG_AMS=y
app/boards/intel_adsp_ace20_lnl.conf:CONFIG_AMS=y
app/boards/intel_adsp_cavs25.conf:CONFIG_AMS=yEnjoy the typical duplication.
As a quick fix, maybe we can bring the fuzzed .config closer to the real thing with this simple addition?
./scripts/fuzz.sh -p -b -- -DCONFIG_IPC_MAJOR_4=y -DEXTRA_CONF_FILE=boards/intel_adsp_ace15_mtpm.conf
Unfortunately not. First we get a gazillion of "hardware" warnings:
warning: POWER_DOMAIN_INTEL_ADSP (defined at drivers/power_domain/Kconfig:40) was assigned the value
'y' but got the value 'n'. Check these unsatisfied dependencies:
DT_HAS_INTEL_ADSP_POWER_DOMAIN_ENABLED (=n).
warning: DEBUG_COREDUMP (defined at subsys/debug/coredump/Kconfig:4) was assigned the value 'y' but
got the value 'n'. Check these unsatisfied dependencies: ...
Then:
CMake Error at /var/home/mherber2/SOF/zephyr/cmake/modules/extensions.cmake:5340 (message):
add_llext_target: only one source file is supported for ELF object file
cc:
Activity
marc-hb commentedon Aug 22, 2024
That's because
boards/intel_adsp_ace15_mtpm.confis a "grab bag" of items totally unrelated to each other, including some actually ace15-specific stuff mixed up with pure software configuration like CONFIG_AMS. The latter being naturally duplicated all over the place.The fix is to study https://docs.zephyrproject.org/latest/build/kconfig/setting.html#initial-conf and implement some proper "overlays" where (at least) hardware and software are separated.
Note how this comment is totally unrelated to fuzzing; fuzzing is just the messenger here.
fuzz.sh: add new boards/native_sim_libfuzzer.conf
fuzz.sh: add new boards/native_sim_libfuzzer.conf
lgirdwood commentedon Aug 23, 2024
@marc-hb can this be closed now with #9389 merged ?
marc-hb commentedon Aug 24, 2024
No, there are .config issues pretty much everywhere we look. Examples:
I will also submit some changes to reduce a bit the gap between build-fuzz/zephyr/.config and products.
marc-hb commentedon Aug 27, 2024
Done:
There are probably more CONFIG_ that should be added (and cleaned up). #9409 sets the stage/adds the "framework" showing how to do that.
marc-hb commentedon Sep 4, 2024
The CONFIG_ gap between fuzzing and production is still too big and there are still weird things in the production config (like b2f79a0) but I don't have any time left for this.
marc-hb commentedon Sep 18, 2024
Another problem noticed: commit 87e973d "downgrades"
mtoninstead ofy. MaybeCONFIG_LLEXT=nwould be better instead?github-actions commentedon Jun 19, 2025
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.