Skip to content

ipc4: fuzz: enable BaseFW testing - #11324

Open
tmleman wants to merge 2 commits into
thesofproject:mainfrom
tmleman:topic/upstream/pr/ipc4/fuzzer/enable_base_fw
Open

tmleman wants to merge 2 commits into
thesofproject:mainfrom
tmleman:topic/upstream/pr/ipc4/fuzzer/enable_base_fw

Conversation

@tmleman

@tmleman tmleman commented Oct 20, 2026

Copy link
Copy Markdown
Contributor

This pull request unblocks the IPC path to BaseFW (module 0) during fuzz testing.

Copilot AI balanced review requested due to automatic review settings October 20, 2026 12:09

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The scoped changes enable BaseFW dispatch, preserve other module mappings, and guard both initialization paths.

No open issues 🎉

What changed in this PR

Enables IPC4 fuzz testing of BaseFW (module 0) while preventing its instantiation as a pipeline component.

Changes:

  • Maps fuzzed module ID 0 to the registered BaseFW driver.
  • Rejects component initialization when the driver lacks a creation callback.
File Description
src/​ipc/​ipc4/​helper.c Adds BaseFW lookup and guards component creation.
src/​ipc/​ipc4/​handler-user.c Rejects initialization of non-instantiable drivers.

Review effort: Balanced

INIT_MODULE_INSTANCE carries a host-controlled module_id. module_id 0 is
BaseFW: on hardware ipc4_get_comp_drv(0) resolves the manifest entry to
the registered comp_basefw driver, which only implements
get/set_large_config and has no create op. comp_new_ipc4() then calls
drv->ops.create() through a NULL function pointer.

Reject any resolved driver without a create op before the call and
return NULL so the handler reports IPC4_MOD_NOT_INITIALIZED. Apply the
same check on the kernel-side lookup that precedes forwarding INIT to
the user-space LL thread, so a query-only driver is never handed to
comp_new_ipc4_user().

Reproduced on native_sim with a framed INIT for module 0 / instance 0,
ppl_instance_id = IPC4_INVALID_PIPELINE_ID: comp_new_ipc4() now returns
NULL and ipc4_init_module_instance() returns 104 (gdb-confirmed that the
resolved driver is comp_basefw with ops.create == NULL).

Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
native_sim fuzz builds have no rimage manifest, so ipc4_get_comp_drv()
falls back to ipc4_get_fuzzer_drv(), which returned NULL for module_id
0. Every LARGE_CONFIG_GET/SET addressed to BaseFW therefore failed with
IPC4_INVALID_RESOURCE_ID and src/audio/base_fw.c, one of the largest
host-facing IPC4 parsers, received zero fuzzing (0.7 % line coverage
over a 19-night campaign). The comment claiming BaseFW messages are
"dispatched directly by base_fw.c" was wrong: the handlers resolve the
driver and call drv->ops.get/set_large_config() with dev == NULL.

Resolve module_id 0 the way the manifest does on hardware: by the BaseFW
registry UUID through ipc4_search_for_drv(), never by list position. The
1-based module-adapter mapping for module_id > 0 and the exclusion of
internal host/DAI drivers are unchanged. BaseFW remains non-instantiable
because comp_new_ipc4() rejects drivers without a create op.

Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
@intel-sofci

Copy link
Copy Markdown

PR 11324: test results

Run date: 2026-10-20 17:14 UTC

Tested commit: ead21f7f6e450c5057e2f703426f72bbfe72eab7

mtl pass rate lnl pass rate ptl pass rate wcl pass rate nvl pass rate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants