fix(image_verify): fail closed when the CRC32 integrity path cannot read flash

[Kartikey1306]

Summary

The CRC32 branch of eos_image_verify_integrity() failed open. eos_crc32()
returned 0 when eos_hal_flash_read() failed, and 0 is indistinguishable
from a region that genuinely hashes to 0. An image whose payload could not be
read at all therefore passed the integrity check, provided the stored CRC was
0.

The SHA-256 branch has always failed closed — eos_crypto_verify_image()
returns rc straight from eos_hal_flash_read(). This PR makes the two
branches behave the same.

The bug

uint32_t eos_crc32(uint32_t addr, size_t len)
{
    ...
        if (eos_hal_flash_read(addr, buf, chunk) != EOS_OK)
            return 0;                    // <-- a valid CRC value
    ...
}

and the caller:

uint32_t computed_crc = eos_crc32(payload_addr, hdr->image_size);
uint32_t stored_crc;
memcpy(&stored_crc, hdr->hash, sizeof(stored_crc));
if (computed_crc != stored_crc) return EOS_ERR_CRC;
return EOS_OK;                           // 0 == 0 -> verified

stored_crc is the first four bytes of hdr->hash. That field is in the image
header, and the header is not covered by the signature —
eos_image_verify_signature() signs hdr->hash itself, not the surrounding
header — so setting those four bytes to 0 costs an attacker nothing. It is
also the natural value in erased or zeroed flash.

Reproduced against the simulated flash already in tests/unit/test_image_verify.c,
placing an image so its payload runs past the end of the device:

flash read of payload tail -> -6 (EOS_ERR_FLASH)
eos_image_verify_integrity -> 0  (EOS_OK)
*** FAIL-OPEN: unreadable image passed integrity check ***

For a bootloader this is the wrong direction to fail in: a slot that cannot be
read is a slot that should send the device to recovery, not one that should be
booted.

Approach

Add eos_crc32_checked(addr, len, *out_crc), which returns EOS_ERR_FLASH on a
read failure and only writes *out_crc on success, and switch the verification
path to it.

eos_crc32() is kept and now delegates to the checked variant. It is
declared in the public eos_image.h, and removing it would be an API break for
a defect that is fixable without one. Its doc comment now carries an explicit
@warning that it cannot report a read failure and must not be used to decide
whether an image is intact. If maintainers would rather retire the unchecked
form outright, that is a one-line follow-up — I did not want to bundle an API
break into a security fix.

Two smaller fixes in the same function, both the same don't verify what you
didn't read shape:

• image_size == 0 is rejected rather than CRC'd to a fixed value. The SHA-256
  path already rejects it via eos_crypto_verify_image().
• addr + hdr->hdr_size is rejected when it wraps uint32_t, rather than
  producing a payload_addr that is not the payload.

I did not add the double-call fault-injection pattern used on the SHA-256
path. CRC32 is not a security primitive and duplicating the read would double
the verification time for no attacker-facing benefit.

Scope note — what this does not fix

While tracing the stored CRC I noticed that the image header as a whole is
unauthenticated: eos_image_verify_signature() covers hdr->hash only, so
flags, image_size, load_addr and entry_addr can be changed without
invalidating the signature. Clearing EOS_IMG_FLAG_HASH_SHA256 downgrades a
signed image from SHA-256 to forgeable CRC32.

That is a design-level issue needing a header-format change, and it is well
outside a fail-closed fix. Flagging it rather than fixing it here — happy to
open a separate issue if useful.

Testing

Seven cases added to tests/unit/test_image_verify.c — 12 total, was 5. The
CRC32 used to build expectations is implemented independently in the test, so
the tests do not simply restate image_verify.c.

Test	What it pins
test_crc_image_with_matching_crc_verifies	a genuinely valid CRC image still passes — the fix does not just reject everything
test_crc_image_with_wrong_crc_is_rejected	a corrupted payload still returns EOS_ERR_CRC
test_crc_unreadable_payload_fails_closed	the regression — asserts the read really fails first, then that verification does not return EOS_OK
test_crc32_checked_reports_flash_failure	EOS_ERR_FLASH on failure, out_crc untouched, EOS_ERR_INVALID on NULL, correct value on success
test_zero_length_image_is_rejected	zero image_size
test_payload_address_overflow_is_rejected	wrapping addr + hdr_size
test_verify_integrity_null_header	NULL header

$ cmake -S . -B build -DEBLDR_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Debug
$ cmake --build build -j            # no new warnings in the touched files
$ ./build/tests/test_image_verify
12/12 tests passed
$ ctest --test-dir build
93% tests passed, 1 tests failed out of 14

Also passes with -DEBLDR_SANITIZE=ON (ASan/UBSan): 12/12.

Before / after, same reproducer linked against the pre-change and
post-change libraries:

pre-change:   eos_image_verify_integrity -> 0  (EOS_OK)     *** FAIL-OPEN ***
this change:  eos_image_verify_integrity -> -6 (EOS_ERR_FLASH)  fails closed

Pre-existing failure, not from this PR

test_recovery is Not Run — it fails to link with undefined
eos_boot_log_append / eos_boot_log_get_head / eos_boot_log_read, because
boot_log.c lives in eboot_stage1 which the test does not link. I confirmed
this fails identically on a clean master checkout before making any changes.
It is already addressed by #35, so I have deliberately left it alone rather than
conflict with that PR. Every other test builds and passes (13/14).

Limitations and considerations

• Behaviour change on flaky flash. A device that previously booted through a
  transient read error on a CRC-only image will now go to recovery instead. That
  is the intended direction, but it is a behaviour change worth calling out for
  anyone running CRC-only (Phase 1) images.
• eos_crc32() remains in the public API and remains fail-open by
  construction. It has no in-tree callers after this change; the @warning and
  the new checklist row are what guard against it being picked up again.
• The header is still unauthenticated — see Scope note above.
• Line endings preserved. core/image_verify.c and CHANGELOG.md have mixed
  CRLF/LF endings in master. I re-applied my edits byte-wise so untouched lines
  keep their original endings — the diff is 37 insertions / 5 deletions rather
  than a whole-file rewrite.

Type of Change

• fix — Bug fix (security)
• test — Add or fix tests
• docs — Documentation

Changes

• core/image_verify.c — eos_crc32_checked(); CRC path fails closed;
  zero-size and payload-address-overflow guards.
• include/eos_image.h — declare eos_crc32_checked(); @warning on eos_crc32().
• tests/unit/test_image_verify.c — 7 new cases (12 total).
• docs/security_review_checklist.md — required item on failing closed on I/O
  error, plus a Common Mistakes row.
• docs/secure_boot_chain.md — EOS_ERR_FLASH added to the failure-mode table.
• CHANGELOG.md — Unreleased entries.

Pre-Submission Checklist

• Compiles without new warnings
• All tests that build on master still pass (13/14; the 14th is the
  pre-existing test_recovery link failure, verified present before my changes)
• New tests added, and the regression verified against pre-change code
• Documentation updated
• Public API preserved (addition only)