Firmware Verification and DMA-Capable Devices: Protect Bytes After They Are Checked
A signature result remains useful only while the bytes and policy inputs it covers stay unchanged through their use. When a peripheral can write relevant RAM, the boot review needs a memory-ownership timeline covering the verification interval and handoff. A successful hash at one instant does not establish that timeline.
This is a platform qualification method, not a DMA-disable recipe. It uses Linux 6.12 DMA documentation for address/coherency distinctions, MCUboot v2.2.0 for one load/verify sequence, and U-Boot v2024.10 for trust-chain context. No specific platform isolation mechanism or target test is claimed.
1. Enumerate every possible writer
List the image region, verification metadata, expected digests, trusted-key policy and handoff structures. Then identify every agent that can modify each region: loader code, another CPU, DMA controllers, bus-master peripherals, debug hardware and board-specific firmware.
For a device, record its physical identity and any stream or requester identity used by the selected protection mechanism. Include boot-time devices needed to fetch the image. A peripheral being idle during one observed boot does not prove that it cannot write the range.
The Linux DMA guide distinguishes CPU virtual, physical and device bus addresses. Device DMA does not pass through the CPU’s virtual-memory translation; IOMMUs may provide separate translation. Consequently, a CPU read-only mapping alone is not evidence that device writes are excluded.
2. Mark the protected interval correctly
Begin the integrity interval before the verifier starts consuming authenticated bytes. If a writer changes the buffer while hashing proceeds, protecting it only after the final digest is produced is too late to establish one stable input.
End the interval only when the next trusted component has taken responsibility under a qualified policy. A handoff that tears down isolation before the successor establishes its own protection creates another interval to review.
| Phase | Ownership question | Required evidence |
|---|---|---|
| Image acquisition | Which buffers may the storage/network device write? | Bounded transfer destinations and exact completion definition |
| Before verification | Have unauthorized writers lost access? | Platform-specific quiescence/isolation completion |
| Verification | Are bytes and verification policy stable? | Coverage of all relevant masters and memory aliases |
| Final preparation | Do fixups, copies or cleanup alter the validated object? | Approved transformation and ownership record |
| Handoff | Does protection remain effective across the transition? | Successor takeover and no uncovered interval |
Record exact events, not only function names such as “stop DMA.” The event must establish what has completed, what outstanding transactions remain possible and when a new transfer could be started.
3. Separate coherence, ordering and exclusion
The Linux guide explains that coherent mappings still require appropriate ordering. Those concepts concern which bytes an agent observes and in what order; they do not by themselves establish who is permitted to write.
A cache clean can make current CPU data visible to another agent. It cannot be treated as revocation of that agent’s access. Similarly, a memory barrier is not a substitute for a platform protection policy. Document all three obligations separately.
Do not transplant Linux DMA calls into a pre-OS loader. The cited guide does not prove that a bootloader has initialized an IOMMU, that every master passes through it, or that its mappings survive a platform reset or handoff.
4. Trace copy and authentication order
In the MCUboot RAM-load branch, a candidate is copied into RAM and then authenticated there. That addresses a check/use concern when copying from an untrusted source. The sequence alone does not establish that all DMA-capable agents are excluded from the destination.
If a different loader verifies a source buffer and copies it afterward, review both the source’s stability during copying and the destination’s subsequent ownership. If approved fixups alter authenticated input, describe exactly which transformation is trusted and why.
RFC 9124 explicitly requires manifest and extracted-data immutability between authentication and use. Extending the ownership analysis to executable payload buffers here is an engineering application of the same check/use concern, not a claim that this section specifies every bootloader memory operation.
5. Choose controls only from actual platform evidence
For each writer, identify a documented control and the evidence needed to rely on it. Possibilities may include an enforced memory firewall, an appropriate IOMMU policy, inaccessible memory placement, or a supported device-quiescence procedure. None can be assumed available from a feature name alone.
| Proposed control | Qualification question |
|---|---|
| Device isolation | Does every relevant transaction route through the enforcing hardware? |
| Device quiescence | What proves outstanding work completed and cannot restart? |
| Protected memory placement | Which masters and aliases can still reach the region? |
| Successor takeover | What preserves exclusion while ownership and mappings change? |
| Reverification | What protects the interval during and after this new check? |
A second hash can detect some changes but creates another last-check boundary. Without a stable interval after it, repeating verification is not a complete exclusion argument.
Hypothetical network-loader handoff
A fictional loader receives an image through a network peripheral, verifies it and later reuses a descriptor buffer. The review cannot establish that all receive descriptors were retired before verification. A valid signature log therefore leaves the ownership claim unresolved.
The next step is to obtain the controller’s documented completion and isolation evidence, then qualify the final sequence. Disabling caches or inserting an arbitrary delay would not answer whether a device can still write the image.
6. Test the contract without overstating the result
Begin with traceable inert buffers and an instrumented development configuration. Verify the declared ownership events and protection decisions under the approved platform test procedure. Any controlled attempted-write test must use disposable ranges and a safe recovery plan, never production executable memory or live actuators.
Retain master identity, region, protection state, boot phase and observed result. A sampled trace showing no writes is weaker than an enforced-denial result, and neither automatically covers untested masters or reset paths.
The verified-boot trust chain supplies authentication context. Close the release review with the separate writer-by-region timeline and platform evidence. Where that evidence is missing, mark the integrity interval unqualified rather than promising complete secure boot.
