fix(multicore): an AMP core starts only on an image that verified

[Kartikey1306]

Closes #145

Stacked on #115; review e152d8e..97f3bc3 for this change alone — one commit, two files (+155/−1). #115 repairs master, which does not build today, so this branch sits on it rather than on master; nothing here depends on the rest of the eBoot stack. Merge order: #115, then this (it is independent of #116/#122/#123/#125/#127/#129/#131/#133/#135/#138/#139/#142 and can land in any order among them).

The defect

core/multicore.c:64-72 parsed the AMP slot's header and started the core on it:

eos_image_header_t hdr;
int rc = eos_image_parse_header(slot_addr, &hdr);
if (rc != EOS_OK) return rc;
/* ... core starts at cfg->entry_addr ... */

Parsing proves the slot is shaped like an image. It authenticates nothing, and whatever can write the slot chooses entry_addr. Every other slot consumer in the tree checks integrity and signature — slot_manager.c:62,68, stage1/jump_app.c:47,54, recovery.c:324,328, fw_update.c:259. This was the only one that did not.

Measured before the fix, with a tampered image in slot A (load_addr == 0, so image_verify.c:101 skips its entry_addr range check too):

eos_image_verify_signature() on it : -4 (EOS_ERR_SIGNATURE)
eos_slot_is_valid(SLOT_A)          : false     <- the normal path refuses it
eos_multicore_start_amp(1, SLOT_A) : 0         <- this path did not
  board start_core() called once, core 1 started at 0xdeadbe00

The change

core/multicore.c, +26/−1: after the existing parse, eos_image_verify_integrity(), then eos_image_verify_signature(), then cfg->entry_addr must equal hdr.entry_addr.

Why in eos_multicore_start() and not in the eos_multicore_start_amp() wrapper. Both are public (include/eos_multicore.h). A caller can build an eos_core_config_t by hand and reach eos_multicore_start() directly, so guarding only the wrapper would leave an unverified twin. The wrapper inherits the checks instead of carrying a second copy.

Why entry_addr is pinned to the header. Verifying an image and then branching somewhere else authenticates an image nobody runs. The wrapper already sets cfg.entry_addr = hdr.entry_addr, so this rejects only a config that disagrees with the image it points at. This is the one behaviour change a direct caller could notice, and it is deliberate — stated here rather than left to be discovered.

Untouched: SMP, lockstep, and AMP with image_slot == EOS_SLOT_NONE, which name an address with no image to authenticate and are unchanged by this.

Tests

Five cases in tests/unit/test_multicore.c (+130). The file had no slot geometry and no image mocks, so this adds a minimal eos_board_ops_t (only slot_a_addr/slot_a_size; every other accessor NULL-guards) and link-time overrides of eos_image_parse_header/verify_integrity/verify_signature — the same technique test_slot_manager.c already uses, so each stage can be failed independently without signing real images.

• test_amp_starts_a_verified_image — all three pass, core starts
• test_amp_refuses_a_failed_signature
• test_amp_refuses_a_failed_integrity_check
• test_amp_refuses_an_entry_addr_the_image_does_not_name
• test_amp_wrapper_refuses_a_failed_signature — the wrapper inherits it

Each check was removed on its own and fails exactly its own case — not the collective revert, which only proves the first one:

remove integrity  -> test_amp_refuses_a_failed_integrity_check   [FAIL]
remove signature  -> test_amp_refuses_a_failed_signature         [FAIL]
remove entry      -> test_amp_refuses_an_entry_addr...           [FAIL]

With all three removed, exactly 1 of 31 ctest tests fails (test_multicore) and no other.

Verified at 97f3bc3, gcc/Ninja/Debug, -DEBLDR_BUILD_TESTS=ON: ctest --no-tests=error 31/31 passed; pytest tests/ 82 passed; test_multicore itself 15/15.

Not run here: the ARM and release legs, and any real AMP board — there is no hardware in this loop, so the board's start_core() is the mock. What is proven is that the core is not started at all unless the image verifies.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 93.33333% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
tests/unit/test_fw_update_test_sigs.py	93.33%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!