fix: restore the build and make the unit suite exercise real code

[Kartikey1306]

The architectural problem

master does not compile, and hasn't for a while — CI — eBoot is red on 39b0925.

The individual breakages below are symptoms of one process failure: PRs that fix the same defect, or that add new files, are squash-merged on stale bases and nothing re-verifies master afterwards. Each PR was green on its own branch. Their combination never was. The result is that three separately-merged security features — SHA-512 (#46), the anti-rollback counter (#54), and full-header signing (#40) — are on master as code that either does not build or is not linked into anything.

Status: 23/23 checks pass on this branch.

Build breakage

• core/recovery.c declared slot_size twice; Fix OOB flash write and OOB stack read in recovery firmware-update path #33 and fix(image): verify_slot() must reject image_size larger than the real slot capacity #50 both landed the same bounds check.
• include/eos_image.h declared int eos_crc32(uint32_t, size_t, uint32_t *) while core/image_verify.c defines uint32_t eos_crc32(uint32_t, size_t) (fix(image_verify): fail closed when the CRC32 integrity path cannot read flash #38 vs fix(eboot): stop a failed flash read from passing the integrity check #52). The header now matches the implementation.
• core/sha512.c and core/rollback.c were never added to CMakeLists.txt. The SHA-512 support from Add SHA-512 implementation and Ed25519 RFC 8032 verification #46 and the anti-rollback security counter from Enforce and commit the anti-rollback security counter #54 were merged as dead code — nothing compiles them.
• Two SHA-512 APIs survived the merge. eos_crypto_boot.h declares eos_sha512_*, include/eos_sha512.h declared sha512_*, and only the latter was implemented — while test_ed25519.c calls the former. Consolidated on eos_sha512_*; include/eos_sha512.h is removed.
• The body of eos_ed25519_verify() was lost. What remained was two spliced hash blocks and return diff == 0 with diff never declared. The group operation that actually checks a signature — [S]B + [k](-A) against R — was gone entirely. Restored, with a constant-time comparison.
• The EBLDR_BOARD dispatch chain was duplicated: 83 boards listed twice across 121 lines, with a stray message(FATAL_ERROR ...) spliced into the kalimba branch, so a supported board aborted configuration.

Stage-0 never verified stage-1

Once the host build compiled, the Cross-compile STM32F4 job surfaced the more serious finding. EBLDR_VERIFY_STAGE1 defaults to ON, and stage0/jump_stage1.c hashes stage-1 in flash before jumping to it. That code has never been built on any board:

1. It uses eos_sha256_ctx_t and the eos_sha256_* functions without including eos_crypto_boot.h — error: unknown type name 'eos_sha256_ctx_t'.
2. With that fixed, it fails to link: nothing anywhere defines stage1_expected_hash or stage1_expected_size. tools/embed_stage1_hash.py exists to produce them, is never invoked by the build, emitted a static array that cannot satisfy an extern in another translation unit, and never emitted the size at all.

The host build never caught either, because EBLDR_BOARD defaults to none and stage0 is only added for a real board. So the first link of the secure boot chain has been dead code since it was written.

Fixed: the tool now emits a C source defining both symbols with external linkage, and CMakeLists.txt generates it from eboot_firmware.bin and compiles it into ebldr_stage0. EBLDR_VERIFY_STAGE1 on a board with no stage-1 linker script is now a configure-time error naming the flag to turn off, rather than a link failure a hundred lines later.

Test-suite integrity

Two files in tests/unit/ were not testing anything, which is why none of the above was caught locally.

• test_slot_manager.c has not compiled since feat(slot_manager): boot attempt counter with rollback detection + fix fw_update_abort ordering #37. That commit landed two versions of the file spliced together: a main() calling ~20 functions that do not exist, a duplicated test_scan_no_valid_slots, and fixture variables used before they are declared. Rebuilt on the coherent pre-feat(slot_manager): boot attempt counter with rollback detection + fix fw_update_abort ordering #37 harness, and given real coverage for the boot-attempt counter feat(slot_manager): boot attempt counter with rollback detection + fix fw_update_abort ordering #37 was meant to add.

• test_boot_log.c defined its own eos_boot_log_* functions. The linker therefore never pulled core/boot_log.c out of libeboot_core.a: the test exercised its own stubs and reported PASS while touching zero production code. Rewritten against the real implementation, stubbing only the platform. It now covers append-before-init, head persistence across resets, ring wrap, read bounds, and that a failed erase does not reset the head.

• include/eos_boot_log.h declared an API that exists nowhere. init(void), count(), flush(), get_latest(), event_name() — every one of them lived only inside that test's stubs, while core/recovery.c and stage1/ call a completely different set of functions through local extern declarations. The header now documents what core/boot_log.c implements.

CI could not go green regardless of the code

• The ARM job pointed CMAKE_TOOLCHAIN_FILE at cmake/arm-cortex-m4.cmake, which does not exist, and passed -DBUILD_TESTS=OFF, which is not this project's option name. Now toolchains/arm-none-eabi.cmake with EBLDR_BOARD=stm32f4.

• .coveragerc sets fail_under = 100 against 23.06% measured, most of the gap being tests/production_test_suite.py (736 statements) which nothing imports. The step failed on the coverage number with all 27 Python tests passing. ebuild resolved this identically with --cov-fail-under=0; both numbers are left alone here.

• Simulation Sanity Test 404s on every job. embeddedos-org/EoSim has no v0.1.0 release and publishes no wheel — its newest asset is a promo video. All 11 simulate jobs, all 3 cross-platform jobs and the gate have failed since the workflow was written, without a single simulation ever running. ebuild hit this and disabled the steps in its own simulation-test.yml; same treatment here, commented rather than deleted so restoring is a one-line revert.

Verification

Check	Result
PR checks	23/23 pass
cmake --build (Debug and Release, EBLDR_BUILD_TESTS=ON)	clean
ctest --no-tests=error	16/16 pass
pytest tests/	13 passed, 1 skipped
cmake -DEBLDR_BOARD=kalimba	configures
generated stage1_hash.c	compiles and satisfies the externs; digest and size match hashlib

Not verified locally: the ARM link itself, for lack of an arm-none-eabi toolchain on this machine — board_stm32f4.c's assembly cannot be assembled by host clang. CI's Cross-compile ARM Cortex-M4 job is the check, and it passes on this branch.

Left alone: .github/workflows/eosim-sanity.yml has the same broken EoSim install but runs on a nightly schedule rather than on pull requests, and ebuild left its copy untouched too. Disabling a nightly diagnostic is a maintainer call, not something to fold into a build-fix PR.

Relationship to open PRs

#55 and #57 also restore the build, and either would fix most of the compile errors above. Neither touches test_slot_manager.c or test_boot_log.c, so with either one merged the test suite still does not compile under EBLDR_BUILD_TESTS=ON — which is what CI uses. Neither addresses the stage-1 hash. Happy to rebase onto whichever lands first.

🤖 Generated with Claude Code

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

ℹ️ You can also turn on project coverage checks and project coverage reporting on Pull Request comment

Thanks for integrating Codecov - We've got you covered ☂️

[srpatcha]

Verified independently against current master: merges clean, builds with no errors, ctest 16/16.

I confirmed master is red before this lands — it is not a stale CI badge:

core/image_verify.c:63:10: error: conflicting types for 'eos_crc32'; have 'uint32_t(uint32_t, size_t)'

The header declares int eos_crc32(uint32_t, size_t, uint32_t *) and the implementation defines uint32_t eos_crc32(uint32_t, size_t). Two PRs, two API shapes, neither rebased on the other.

The finding that matters most is the one about eos_ed25519_verify() losing its body — what survived was two spliced hash blocks and return diff == 0 with diff never declared, and the group operation that actually checks a signature was simply gone. A signature verifier that does not verify is the worst possible failure mode for a bootloader, and it reached master because the file did not compile so nobody ran it. Restoring it with a constant-time comparison is right.

Equally important and easier to overlook: core/sha512.c and core/rollback.c were never added to CMakeLists.txt. The SHA-512 support from #46 and the anti-rollback counter from #54 are both on master as dead code — two merged security features that were never compiled into anything. That is worth a post-mortem beyond this PR.

And stage0/jump_stage1.c never having been built on any board, with stage1_expected_hash and stage1_expected_size undefined anywhere while EBLDR_VERIFY_STAGE1 defaults ON — that is stage-0 shipping a verification step that could not have linked.

Your diagnosis of the process failure is the right one and I am taking it seriously: squash-merging green branches on stale bases without re-verifying the result. I have been re-verifying each PR against current master before merging for exactly this reason, and it has already caught two PRs in eos that GitHub reported as MERGEABLE and that did not compile once merged.

Not verified here: the STM32F4 cross-compile half. No ARM toolchain on this machine, so that rests on CI.

[Aswin-V]

Rebased onto current master to clear the conflict (this branch had drifted significantly behind -- #69/#67/#64/#61/#60/#71 all landed since it opened).

Diffed every file this PR touches against current master before resolving: everything except tests/unit/test_slot_manager.c was already byte-for-byte identical on master (the eos_crc32 fix, the restored eos_ed25519_verify() body, SHA-512 consolidation, core/sha512.c and core/rollback.c added to the build, the EBLDR_BOARD dedup, the stage-1 hash generation/verification wiring, test_boot_log.c, and the CI fixes -- #69 and #67 had converged on the same fixes independently, as you noted in your review on #69).

For test_slot_manager.c, took this PR's version -- the direct eos_hal_slot_addr/size/flash_erase mocks over a simulated flash backend, since this test only links eboot_core and you'd already reviewed it.

One thing worth flagging: core/recovery.c's one-line hunk in this PR (removing a slot_size declaration) no longer applies cleanly -- git's own 3-way merge applied it without conflict, but silently reintroduced an undeclared-identifier build break, because that line is now part of a different, already-merged fix (#69) for the same original defect. Dropped that hunk from the merge to avoid reintroducing the break.

Follow-up: the first push here still failed CI -- test_cmake_test_registration.py::test_every_c_suite_is_built caught that tests/unit/test_image_abi.c (added by #67) was never registered in tests/CMakeLists.txt, so it silently never built or ran. That's a master-level gap independent of this PR, so fixed it on master directly (038f624) and merged master into this branch again (5e7bd07).

Verified on the current branch tip: cmake configure + build, 0 errors. ctest 34/34 including valgrind. pytest tests/ 30/30 pass (matches CI's own invocation).

Pushing dismissed your approval, so this needs a fresh look from you (or another reviewer) before it can merge -- I'm the one who pushed, so I can't be the one to approve it.

[Kartikey1306]

@Aswin-V thank you for the rebase and for the write-up — especially catching that the core/recovery.c hunk merged cleanly and still broke the build, because the line it removes is now part of #69's fix for the same original defect. A three-way merge succeeding is not the same as the result being correct, and that is exactly the failure mode this PR was about in the first place.

Closing this: there is nothing left in it.

I merged current master into the branch and diffed. Everything is now on master — the eos_crc32 signature, the restored eos_ed25519_verify() body, the SHA-512 consolidation, core/sha512.c and core/rollback.c in the build, the EBLDR_BOARD dedup, the stage-1 hash wiring, test_boot_log.c, and the CI fixes. The single remaining difference is tests/unit/test_slot_manager.c, and master's copy is my nine tests (test_boot_attempts_drive_rollback, test_erase_resets_boot_attempts, and the rest) reworked onto the fuller simulated board ops. Merging this branch now would replace that with my simpler direct mocks — a regression, not a contribution.

Since it needs a fresh review it cannot get from you, and there is nothing to review, closing is cleaner than leaving it open.

---

One thing that came out of checking: master does not currently build.

tests/unit/test_image_verify.c: 24 errors
ctest: 13 of 19 failing

TEST() in that file lost a line continuation in #70 (881f00c), so the macro ends early and its body leaks to file scope. Opened #77 with the one-character fix — 0 errors, 19/19 pass. CI — eBoot has been red on master for it since 08:07 today.