Stage-0 verifies an empty stage-1: eboot_firmware.bin links to 0 bytes and the embedded hash is SHA-256("") #136

Found by the automated review of #129 (finding 1, Critical); reproduced here with build.yml's flags and with toolchains/arm-none-eabi.cmake.

What

On every board build with a stage-1 linker script, eboot_firmware.bin is 0 bytes:

• stage1/main.c exports eboot_main(), not a reset handler, and nothing in stage1/ provides a vector table;
• boards/stm32f4/stm32f4_stage1.ld has no ENTRY() and keeps no section (the stage-0 script has KEEP(*(.isr_vector)));
• the target links with -nostartfiles and -Wl,--gc-sections, so the linker has nothing to anchor: arm-none-eabi-objdump -h eboot_firmware.elf → .text 00000000.

tools/embed_stage1_hash.py has no minimum-size check — size = os.path.getsize(input_path) is used verbatim — so it emits stage1_expected_size = 0u and stage1_expected_hash = e3b0c442…b855 (the SHA-256 of the empty string) and prints both as a normal build line. On the device, stage0/jump_stage1.c's while (off < 0) runs zero iterations, computed equals the expected digest trivially, EOS_LOG_IMAGE_VALID is appended, and ops->jump(stage1_addr) transfers control to whatever is in flash. The first link of the secure boot chain reports success without having run, and CI is green over it.

Alongside: stage0/reset_entry.c's vector table stops at UsageFault (7 entries), while board_early_init() on stm32f4 enables the SysTick interrupt, whose vector is entry 15 — so one millisecond after reset the core fetches its SysTick handler address from the code that follows the table.

Expected

Three independent guards: the stage-1 link anchored (a reset entry owning the vector table, ENTRY(Reset_Handler) and a kept vector section in every stage-1 linker script); the embed tool refusing an empty or implausibly small image; and stage-0 refusing stage1_expected_size == 0 before the hash loop. Both vector tables reaching SysTick.