ToyOS's own SHA-256 and SHA-512, as fast as sha2's soft backend, replace the sha2 crate in the loader's and update's image verification, swap, pkg and the build

Cargo.toml

@@ -61,6 +61,7 @@ members = [
     "toyos-quiesce",
     "toyos-random",
     "toyos-rootimage",
+    "toyos-sha2",
     "toyos-smmu",
     "toyos-ssh",
     "toyos-swap",
@@ -208,9 +209,10 @@ toyos-ssh = { path = "toyos-ssh" }
 # disagree about which files on it are `logkeeper`'s.
 toyos-wallclock = { path = "toyos-wallclock" }
 image = { version = "0.25", default-features = false, features = ["jpeg"] }
-# The digest behind `NOTICE`'s record of every committed binary file
-# (`src/sourcegate.rs`).
-sha2 = "0.10"
+# Every SHA-256 the build takes: `NOTICE`'s record of a committed file, a
+# store key, a ROOT's name, a release asset's digest, and the harness's of a
+# body a guest fetches over TLS.
+toyos-sha2 = { path = "toyos-sha2" }
 # The toolchain release's tarball, packed in-process (`src/release.rs`): Rust's
 # own tar and gzip, where the binaries are hosts' tools.
 tar = { version = "0.4.46", default-features = false }

NOTICE

@@ -426,3 +426,35 @@ toyos-microcode/intel-ucode/* — Intel microcode, redistributable unmodified
     Licence text: licenses/Intel-microcode-license.txt (upstream's `license`,
     sha256 03efb1491c7e899feb2665fa299363e64035e5444c1b8bc1f6ebed30de964e12)
     SPDX-License-Identifier: LicenseRef-Intel-Microcode
+
+
+tests/cavp/ — NIST's SHA-2 test vectors, CAVP SHAVS
+----------------------------------------------------
+
+    SHA256ShortMsg.rsp     10,299 bytes
+      sha256 75e1cb83994638481808e225b9eb0c1ebd0c232d952ac42b61abce6363be283c
+    SHA256LongMsg.rsp     426,209 bytes
+      sha256 6fac36f37360bcf74ffcf4465c18e30d6d5a04cc90885b901fc3130c16060974
+    SHA256Monte.rsp         8,751 bytes
+      sha256 29ea30c6bb4b84e425fb8c1d731c6bb852dac935825f2bd1143e5d3c4f10bfb9
+    SHA512ShortMsg.rsp     36,800 bytes
+      sha256 e53a36c03609e5a3e3cc4b6e117a499db7864c23ec825c6cec99503a45f40764
+    SHA512LongMsg.rsp   1,687,845 bytes
+      sha256 b1f3f05d5c209777954d49521d7ea1349447c36a0c52849e044bc397a27dd410
+    SHA512Monte.rsp        15,215 bytes
+      sha256 8ca78659286c2f01667a98fc7accd32fc171ae7b24ac00f1a8ce6b77770247fa
+    Upstream: https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/shs/
+    shabytetestvectors.zip (sha256
+    929ef80b7b3418aca026643f6f248815913b60e01741a44bba9e118067f4c9b8), each
+    file byte for byte, CRLF line ends and all
+    SPDX-License-Identifier: NIST-PD
+
+The response files NIST's Cryptographic Algorithm Validation Program publishes
+for the SHA Validation System: messages and the digests FIPS 180-4 gives them,
+the external oracle `toyos-sha2`'s tests hold it to. A work of the United States
+government, not under copyright in the United States (17 U.S.C. §105). Test
+input only: nothing built from this repository carries them, and no shipped
+package's directory holds them.
+
+Of the archive, only SHA-256's and SHA-512's files, the two hashes the crate
+has.

bootloader/Cargo.toml

@@ -35,9 +35,10 @@ toyos-tsc = { path = "../toyos-tsc" }
 # The signed image, the slot table and the anti-rollback floor: every decision
 # this loader makes about which slot to boot, host-tested there.
 toyos-update = { path = "../toyos-update" }
-# `force-soft`, unified into the SHA-256 and SHA-512 `toyos-update` hashes
-# with: this target is soft-float, and the x86 backend reaches for SSE and
-# SHA-NI registers a UEFI application may not assume are its own.
+# Not hashed with here: `force-soft`, unified into the `sha2` that
+# `ed25519-dalek` takes its SHA-512 from inside a verification. This target is
+# soft-float, and the x86 backend reaches for SSE and SHA-NI registers a UEFI
+# application may not assume are its own.
 sha2 = { version = "0.10", default-features = false, features = ["force-soft"] }
 # `alloc`: `variable_keys` and `get_variable_boxed`, which are how the boot
 # entry pointing at this image is found among the firmware's own variables.

issues/the-build-runs-host-tools-outside-rust-and-qemu.md

@@ -33,7 +33,7 @@ arrives and is not one. M4 and M5 are stages of `issues/toyos-builds-itself.md`.
 | `cc`, `c++`, `ar` and `xcrun` on a macOS host, Apple's Command Line Tools | what the Linux row's tools do, and rustc asks `xcrun` for the SDK on every host link that names no `SDKROOT` (`rust/compiler/rustc_codegen_ssa/src/back/apple.rs`), as `src/llvm.rs` does for the LLVM's key | refused: one host OS alone | M5: no host in the loop |
 | `diag/flash.sh` | the owner's flash of a stick by hand: `bash`, and the `stat`, `seq`, `tr`, `grep`, `cut` and `sync` it strings together | refused: shell of our own | `issues/the-owners-flash-script-runs-diskutil.md` |
 | `diskutil` and `plutil` | `diag/flash.sh`, and `diskutil` in the README's flashing steps | refused: one host OS alone | `issues/the-owners-flash-script-runs-diskutil.md` |
-| `shasum`, a Perl script on macOS | `diag/flash.sh` hashes the image with it | refused: a Rust tool does it, `sha2`, which `src/release.rs` hashes with | `issues/the-owners-flash-script-runs-diskutil.md` |
+| `shasum`, a Perl script on macOS | `diag/flash.sh` hashes the image with it | refused: a Rust tool does it, `toyos-sha2`, which `src/release.rs` hashes with | `issues/the-owners-flash-script-runs-diskutil.md` |
 | `lsblk` | the README's Linux flashing steps find the stick with it | refused: one host OS alone | `issues/the-owners-flash-script-runs-diskutil.md` |
 | `dd` | `diag/flash.sh` and the README's flashing steps write the stick with it | refused: a Rust tool does it, the build system can write the image itself | `issues/the-owners-flash-script-runs-diskutil.md` |
 | `sync` | the README's Linux flashing steps flush the stick with it | refused: a Rust tool does it, the build system can flush what it writes | `issues/the-owners-flash-script-runs-diskutil.md` |

issues/x86-64-hashing-runs-scalar-where-the-cpu-has-sha-instructions.md

@@ -0,0 +1,32 @@
+---
+status: owner
+kind: question
+opened: 2026-10-09
+---
+
+# x86-64 hashing runs scalar where the CPU has SHA instructions
+
+`toyos-sha2` is scalar on every target and forbids `unsafe`, so the callers
+that took `sha2`'s x86 backend — SHA-NI for SHA-256 and AVX2 for SHA-512,
+chosen by CPUID — lost it: `update`'s streamed ROOT hash, `pkg` and `swap` on
+the T14, and the build's hashing (`src/cicache.rs`, `src/image.rs`'s
+`root_uuid`, `src/sysroot.rs`) on x86-64 CI runners. The loader is not among
+them: its target is soft-float and it was scalar before.
+
+The loss is bounded by the scalar time itself, which the T14 measured: the
+loader on main at d6298c83e hashed the `testcases` image's 320,864,256-byte
+ROOT with `sha2`'s soft backend in 5,343,577,520 counter ticks at 2,419,200,000
+Hz, 2.21 s (138.5 MiB/s), and read the same ROOT off the stick in 9.31 s. So
+`update` gives up at most 2.2 s of a 306 MiB ROOT it also writes, and at most
+0.4 s of the default image's 56 MiB one; the build's largest hash, every
+tracked file for `cicache` (47,906,184 bytes at c8aad54b1), at most 0.33 s
+at that rate. `update`'s own hash time on the T14 is unmeasured.
+
+An instruction path needs `core::arch` intrinsics, which are `unsafe`, in an
+x86-64 module of the crate with a CPUID selector, for userland callers alone.
+
+The question: is up to 2.2 s of an update worth `unsafe` in the crate every
+signed image is verified with?
+
+Exit: the owner's ruling; on a yes, the T14's `update` reading of its ROOT hash
+before and after the instruction path lands.

src/cicache.rs

@@ -44,8 +44,6 @@ use std::io::ErrorKind;
 use std::path::{Path, PathBuf};
 use std::time::{Duration, SystemTime, UNIX_EPOCH};
 
-use sha2::{Digest, Sha256};
-
 const MANIFEST: &str = "target/ci-sources";
 pub const DRIVER: &str = "target/ci-driver";
 
@@ -308,7 +306,7 @@ fn sources(root: &Path) -> Result<Sources, String> {
             continue;
         }
         let bytes = fs::read(&file).map_err(|e| format!("read {path}: {e}"))?;
-        sources.insert(path, format!("{:x}", Sha256::digest(bytes)));
+        sources.insert(path, crate::release::sha256_hex(&bytes));
     }
     Ok(sources)
 }

src/image.rs

@@ -6,7 +6,7 @@ use std::path::Path;
 use bcachefs::{BlockBuf, BlockIO, BlockNum, Formatted, FsUuid, Superblock, VecBlockIO};
 
 use crate::arch::Arch;
-use sha2::{Digest, Sha256};
+use toyos_sha2::Sha256;
 use toyos_fat32::{BlockAccess, Fat32, FatTime, IoError};
 
 /// The image that goes on the ROOT partition, named by a UUID **derived, never

src/release.rs

@@ -24,7 +24,7 @@ use std::path::{Path, PathBuf};
 use std::process::Command;
 
 use serde_json::Value;
-use sha2::{Digest, Sha256};
+use toyos_sha2::Sha256;
 use toyos_tmpdir::TempDir;
 
 use crate::buildlock::Keyed;

src/sourcegate.rs

@@ -277,8 +277,7 @@ fn host_files() -> Vec<PathBuf> {
 /// `bytes` as lower-case hex SHA-256, the spelling `NOTICE` records.
 #[cfg(test)]
 fn digest(bytes: &[u8]) -> String {
-    use sha2::{Digest, Sha256};
-    Sha256::digest(bytes).iter().map(|b| format!("{b:02x}")).collect()
+    toyos_sha2::Sha256::digest(bytes).iter().map(|b| format!("{b:02x}")).collect()
 }
 
 /// The shapes of a value that identifies a machine or the network it is on,

src/sysroot.rs

@@ -46,7 +46,7 @@ use std::fs;
 use std::path::{Path, PathBuf};
 use std::process::Command;
 
-use sha2::{Digest, Sha256};
+use toyos_sha2::Sha256;
 
 use crate::arch::Arch;
 use crate::buildlock::{self, Guard, Held, Keyed};