fix(secure-boot): build the secure boot module, and stop it booting plaintext

[AshrafAhmed9]

core/secure_boot.c is not in eboot_core's source list. It has never been
compiled, nothing calls eos_secure_boot(), and it has no tests — 238 lines
implementing the verification chain the bootloader exists to perform:

$ for f in core/*.c; do grep -q "$f" CMakeLists.txt || echo "orphaned: $f"; done
orphaned: core/fdt_loader.c
orphaned: core/secure_boot.c

Wiring it in also needs core/rollback.c, which it calls and which is missing
from the list too. (#69 adds rollback.c for its own reasons; the line is the
same either way.)

Compiling it turned up a policy doing the opposite of its name.
require_encryption is documented in eos_secure_boot.h as "Enforce AES-GCM
decryption". Step 6 read:

if (cfg->require_encryption && (hdr.flags & EOS_IMG_FLAG_ENCRYPTED)) {
    ...
    return EOS_SBOOT_ERR_DECRYPT;
}

An encrypted image reaches the body and is refused, because decryption isn't
implemented yet. A plaintext image fails the second half of the condition,
falls past the gate, and boots.

That branch was also the only failure return in the function that didn't call
attest_record(), so a refusal left no measurement in the attestation log.

The change

• core/secure_boot.c and core/rollback.c join eboot_core
• require_encryption alone decides whether the gate applies; an image without
  EOS_IMG_FLAG_ENCRYPTED is refused rather than booted
• the refusal is attested, like every other branch in the function

Testing

tests/unit/test_secure_boot.c is new — the first coverage this module has had.
It follows the simulated-flash pattern the other unit tests use, and pins four
behaviours: a plaintext image under require_encryption is rejected, an
encrypted one is rejected while decryption is unimplemented, a plaintext image
still boots when the policy doesn't ask for encryption, and the refusal is
recorded.

Against the current secure_boot.c the first case fails, because the image
boots:

  test_plaintext_image_rejected_when_encryption_required [FAIL]
  test_secure_boot.c:154: rc == EOS_SBOOT_ERR_DECRYPT

With the change:

  test_plaintext_image_rejected_when_encryption_required [PASS]
  test_encrypted_image_rejected_while_decrypt_unimplemented [PASS]
  test_plaintext_image_boots_when_encryption_not_required [PASS]
  test_decrypt_failure_is_attested                   [PASS]
4 passed

Full suite, macOS 15 / Apple Clang: 18/18, up from 17.

Master doesn't compile right now — core/recovery.c has a duplicate slot_size
and core/image_verify.c a conflicting eos_crc32, which #69 repairs. I ran
the suite with #69 applied locally to get the numbers above; this branch touches
neither of those files.

While reading the source list I noticed core/boot_log.c is listed twice, and
core/fdt_loader.c is orphaned the same way secure_boot.c was. Both left
alone here as separate questions.

[srpatcha]

This is a real secure-boot bypass and the fix is right. I verified both halves of
the title rather than taking them on trust.

"build the secure boot module"

secure_boot.c was referenced zero times by any CMakeLists.txt. It was not
compiled, not linked, not tested. Whatever it said about policy had no bearing on
what the bootloader did.

"stop it booting plaintext"

The gate read:

if (cfg->require_encryption && (hdr.flags & EOS_IMG_FLAG_ENCRYPTED)) {
    /* decrypt ... */
}

The decrypt path ran only for images that are encrypted. A plaintext image on
a device configured to require encryption matched neither arm, fell past the
block, and booted. The one image the policy exists to reject was the one image it
let through.

Your structure separates the two questions correctly — first "does policy demand
encryption", then "is this image encrypted":

if (cfg->require_encryption) {
    if (!(hdr.flags & EOS_IMG_FLAG_ENCRYPTED)) {
        return EOS_SBOOT_ERR_DECRYPT;
    }
    ...
}

Verified

Applied on a base where master's build is repaired:

0 build errors
100% tests passed, 0 tests failed out of 17

Secure boot policy tests
  test_plaintext_image_rejected_when_encryption_required      [PASS]
  test_encrypted_image_rejected_while_decrypt_unimplemented   [PASS]
  test_plaintext_image_boots_when_encryption_not_required     [PASS]
  test_decrypt_failure_is_attested                            [PASS]

Then I reverted only the condition, back to require_encryption && ENCRYPTED:

test_plaintext_image_rejected_when_encryption_required
  [FAIL] test_secure_boot.c:154: rc == EOS_SBOOT_ERR_DECRYPT

So the test genuinely pins the bypass rather than describing it.

The third test is the one I would have asked for if it were missing:
test_plaintext_image_boots_when_encryption_not_required proves the fix did not
over-correct into refusing plaintext on devices that never required encryption.
And test_encrypted_image_rejected_while_decrypt_unimplemented is the right call
— an encrypted image must not boot while decryption is a stub, and "we cannot
decrypt this" has to fail closed like any other unreadable input.

One note for when you rebase

eBoot#71 namespaces every test target in tests/ as eboot_*, because eos and
eBoot both defined test_crypto and test_multicore and ebuild composes them
into one CMake project. Its configure-time guard caught your new target while I
was verifying:

CMake Error: Test target 'test_secure_boot' is not namespaced.  Name it
'eboot_test_secure_boot' ...

So after #71 lands this needs eboot_test_secure_boot as the target name. The
add_test(NAME test_secure_boot ...) label stays as it is — the collision is
between targets, not test names, so your ctest output does not change.

Approving. Merge order here is #58, then #71, then this.

[AshrafAhmed9]

@srpatcha both follow-ups from your review are pushed, see the two new commits (the eboot_test_secure_boot rename here, and the poll-granularity note on eos#96). I can't re-request a review as an outside contributor, hence the ping.

[srpatcha]

Re-approving — my earlier review was auto-dismissed when you pushed the
namespacing commit, not withdrawn.

eboot_test_secure_boot is exactly right, and keeping add_test(NAME test_secure_boot ...) unchanged is the detail I was hoping you would catch: the
collision CMake rejects is between targets, so the ctest output stays as it was.

Re-verified on #71's branch, which carries the namespace guard:

0 build errors
100% tests passed, 0 tests failed out of 17

Everything in my previous review stands. The important part, for anyone reading
this later: secure_boot.c was compiled by nothing at all, and the policy gate
read require_encryption && (flags & ENCRYPTED) — so the decrypt path ran only
for images that were encrypted, and a plaintext image on a device requiring
encryption fell straight past it and booted. Reverting just that condition turns
your test red:

test_plaintext_image_rejected_when_encryption_required
  [FAIL] test_secure_boot.c:154: rc == EOS_SBOOT_ERR_DECRYPT

Merge order remains #58, then #71, then this.