Conversation
sha256sum --check's checksum-file parsing differs across coreutils implementations: Rust/uutils coreutils rejects our tab-separated sha256sum.txt format that GNU coreutils accepts fine. Rather than change the on-disk format (which would break byte-for-byte reproducibility against already-published release tarballs), verify each entry directly with a portable read/sha256sum loop. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
arl-s (Arrow Lake S) previously only had a community-signed binary borrowed from mtl via symlink, with an empty intel-signed/ directory. Add its own real Intel-signed firmware, built directly into the existing v2.15 release (there is no v2.15.1 point release) and named after the public platform name arl-s, not the internal-only mtl-s codename it was built under. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nothing previously checked that when a platform's firmware is re-shipped in a later point release, it's still signed with the same Intel key as before. Extend validate_sof_install.py (both the local and remote/SSH manifest parsers) to extract a sha256 fingerprint of the CSS manifest's RSA modulus, and add a --compare-signing-keys PREV_DIR CURR_DIR mode that diffs .ri/.llext signing keys between two version directories: files only on one side are informational (new platform), a key mismatch on a shared path is an error. Every checked file gets its own OK/ERROR/INFO line with both sides' key fingerprints, so a CI log shows exactly which key each file was checked against rather than just a final match/mismatch count. Wire this into a new tests/key_continuity.bats that dynamically discovers every consecutive point-release pair under sof-ipc4-v* and sof-ipc4-lib-v*, and a dedicated .github/workflows/key-continuity.yml (no sibling sof checkout or tag fetch needed, unlike BATS.yml). Scoped to the modern IPC4 layout only: the legacy pre-IPC4 sof-vX.Y tree had genuine historical key rotations (jsl, ehl), so a full-history check there would need a from-day-one exception list. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kv2019i
approved these changes
Sep 19, 2026
kv2019i
left a comment
Collaborator
There was a problem hiding this comment.
Looks good now!
The v2.15 tree is still missing these two symbolic links. The final release is still ok as we include the v2.14 paths in the build recipe, but this as you are tuning a new way to make these PRs, good to fix this as well (can be a separate PR):
Manifest from multiversion tarball test with this PR:
sof-ipc4-v2.14.1 ./arl/intel-signed/sof-arl.ri -> ../../mtl/intel-signed/sof-mtl.ri
sof-ipc4-v2.14.1 ./arl/sof-arl.ri -> intel-signed/sof-arl.ri
Comparing v2.14 and v2.15 binary sets with this PR:
$ find v2.14.x/sof-ipc4-v2.14.1/ -name sof-arl.ri -ls
39632922 0 lrwxrwxrwx 1 kvehmane kvehmane 23 Dec 19 2025 v2.14.x/sof-ipc4-v2.14.1/arl/sof-arl.ri -> intel-signed/sof-arl.ri
39632921 0 lrwxrwxrwx 1 kvehmane kvehmane 33 Dec 19 2025 v2.14.x/sof-ipc4-v2.14.1/arl/intel-signed/sof-arl.ri -> ../../mtl/intel-signed/sof-mtl.ri
39632056 0 lrwxrwxrwx 1 kvehmane kvehmane 30 Dec 18 2025 v2.14.x/sof-ipc4-v2.14.1/arl/community/sof-arl.ri -> ../../mtl/community/sof-mtl.ri
$ find v2.15.x/sof-ipc4-v2.15/ -name sof-arl.ri -ls
39372696 0 lrwxrwxrwx 1 kvehmane kvehmane 30 Sep 17 21:40 v2.15.x/sof-ipc4-v2.15/arl/community/sof-arl.ri -> ../../mtl/community/sof-mtl.ri
Collaborator
|
@lgirdwood Another minor the nit, v2.15 folder doesn't provide mtrace-reader.py copy. Not sure do we need to keep including this (it's just a Python source file), but if you don't include it, there's a risk of releasing a very old file. E.g. now the multiversion picks the one from v2.14: sof-bin-2026.09/manifest.txt |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tarball_multi_releases.bashchecksum verification for non-GNUsha256sumimplementations.validate_sof_install.py --compare-signing-keys,tests/key_continuity.bats,.github/workflows/key-continuity.yml) that verifies a platform's Intel signing key doesn't silently change across consecutive point releases, printing an OK/ERROR/INFO line per file compared so CI logs show exactly which key each file was checked against.Supersedes #210, which was based on an incorrect premise (a v2.15.1 point release that doesn't exist, and the internal mtl-s codename instead of the public arl-s platform name).
Test plan
python3 -m py_compile validate_sof_install.pybats tests/*.batssuite (21/21 passing)shellcheckon touched shell/bats files (clean)compare_signed_unsigned.pyconfirms arl-s's new intel-signed firmware matches expected module content--compare-signing-keysmanually verified against existing point-release pairs (v2.7→v2.7.1, v2.8→v2.8.1, v2.14→v2.14.1)🤖 Generated with Claude Code