Skip to content

chore: sync main into earlgrey-hwe#337

Open
synchronizebot[bot] wants to merge 14 commits into
earlgrey-hwefrom
sync/main-to-earlgrey-hwe
Open

chore: sync main into earlgrey-hwe#337
synchronizebot[bot] wants to merge 14 commits into
earlgrey-hwefrom
sync/main-to-earlgrey-hwe

Conversation

@synchronizebot

Copy link
Copy Markdown

Automated daily sync from main to earlgrey-hwe.

⚠️ If conflicts exist, click the "Resolve conflicts" button below to fix them in your browser.

Bumps [actions/cache](https://github.com/actions/cache) from 5 to 6.
- [Release notes](https://github.com/actions/cache/releases)
- [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md)
- [Commits](actions/cache@v5...v6)

---
updated-dependencies:
- dependency-name: actions/cache
  dependency-version: '6'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
dependabot Bot and others added 13 commits July 10, 2026 09:29
Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v6...v7)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: '7'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
Add RAM_NC memory region (0x000A0000, 128K) to target.ld.tmpl and
a .ram_nc (NOLOAD) section so statics tagged with
#[unsafe(link_section = ".ram_nc")] are placed in the AST1060's
non-cached SRAM window rather than cached RAM.

Shrink ram_size_bytes in all system.json5 files that used 384KB
(ending at 0x000A0500) so that the cached RAM region ends exactly
at the RAM_NC boundary (0x000A0000).
The no_panics_test scans the compiled ELF and fails if any panic path is
reachable. Two root causes remained in the SHA-2 / HMAC code linked into
the hace_sha256 binary:

- div_by_zero: chunks_exact(4).zip(..) in load_iv / digest_from_context.
  ChunksExact stores its chunk size as a runtime field, so Zip::new emits
  a len / chunk_size division the optimizer cannot prove non-zero.
  Replaced with index-stride loops over length-proven [u8; 4] arrays.

- copy_from_slice len_mismatch_fail: the staging copies in
  HaceDigest::update and HaceHmacCtx::update copy between two range-sliced
  &[u8] of equal-by-construction length the optimizer cannot prove equal.
  Replaced with zip element-wise copies (no length assert, no division).

Also hardened the AES IV copies (AesCipher::crypt, AesSkin CBC chaining)
to use <[u8; AES_BLOCK]>::try_from array assignment instead of
copy_from_slice, per the project no-panic patterns.

no_panics_test now PASSES; nm shows no panic_is_possible, len_mismatch_fail,
or div_by_zero symbols.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The HACE SHA-2/HMAC KAT test (hace_sha256_test) HardFaulted with an
unaligned UsageFault (wild pointer 0x191818f6) at the sha256 stream-9000
case. Root cause: run_hace_sha2_kats builds a large single stack frame
that overflowed the pigweed-default 2 KiB kernel bootstrap stack into
adjacent .bss (INPUT_BUF); the first case that writes that 4 KiB buffer
(stream-9000) clobbered the live frame and corrupted a saved pointer.
The one-shot cases passed only because they never write INPUT_BUF.

Two parts:
- hmac.rs: move the large HMAC working buffers (key, ipad, opad, and the
  1 KiB msg) off the stack into a single .ram_nc static (HmacNcBufs), so
  HaceHmacCtx is just a few scalars (~20 bytes). This removes the dominant
  per-op stack pressure from the back-to-back HMAC cases. Remaining
  copy_from_slice calls are also converted to zip-copies.
- config.rs: raise KernelConfigInterface::KERNEL_STACK_SIZE_BYTES from the
  2 KiB default to 16 KiB, giving the bootstrap/idle kernel stacks ample
  headroom for the crypto KAT workloads. The AST10x0 has 768 KiB SRAM so
  the extra RAM is negligible.

hace_sha256_test and no_panics_test both pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants