earlgrey: Add static stack size verification tooling and firmware tests - #424
Open
anthonychen1251 wants to merge 2 commits into
Open
earlgrey: Add static stack size verification tooling and firmware tests#424anthonychen1251 wants to merge 2 commits into
anthonychen1251 wants to merge 2 commits into
Conversation
Add static stack size and cumulative call-stack verification tooling to inspect Rust ELF binaries against process memory budgets declared in system.json5. Includes: - MODULE.bazel: expose hermetic @llvm_toolchain for llvm-readobj and llvm-objdump. - check_stack_sizes.py: parses system.json5 allocations, extracts function stack frame sizes via llvm-readobj, constructs directed call graphs via llvm-objdump, computes worst-case cumulative call paths for userspace processes, and detects/warns on recursive cycles and unresolved reachable indirect jumps. - stack_size_test.bzl: defines rust_stack_size_test rule and macro using hermetic llvm tools. - BUILD.bazel: exposes tooling targets. Signed-off-by: Anthony Chen <antchen@google.com>
…ize allocations Add rust_stack_size_test to HWE and Transport firmware targets to verify that userspace process cumulative call paths conform to system.json5 memory allocations. Also adjust updatemgr ram_size_bytes from 8192 to 4096 and kernel_stack_size_bytes from 4096 to 2048 in transport system.json5 based on static stack analysis findings. Signed-off-by: Anthony Chen <antchen@google.com>
anthonychen1251
force-pushed
the
stack-static-check
branch
from
August 18, 2026 08:54
342ad84 to
585f313
Compare
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.
This PR introduces an automated, compile-time static stack size analysis tooling for
pw_kerneluserspace processes on OpenTitan earlgrey firmware (hweandtransport).In
pw_kernel, each process has a fixed static RAM allocation (ram_size_bytes) declared insystem.json5and enforced by hardware PMP regions.Previously, determining the required RAM for a new or modified process required guesswork. This tooling reconstructs the caller-to-callee call graph, computes the worst-case cumulative stack depth for each process protection domain, and enforces safety margins at compile time.
Dynamic Indirect Jumps (jalr): The static call-graph reconstructor parses disassembly to identify direct or PC-relative calls (such as jal or auipc + jalr ). However, dynamic indirect calls—including dynamic trait objects (&dyn Trait) using vtables or standard function pointers (fn())—retrieve target addresses at runtime via CPU registers (jalr rs1). Since these lack static symbol labels, they remain unresolvable through pure disassembly and are excluded from the cumulative depth calculation.
When running
bazel test //target/earlgrey/firmware/transport:stack_size_transport, the tool produces a detailed report: