From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds

From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds Maisha Mastora✉

Dean Sullivan

arXiv:2609.01769v1 [cs.SE] 1 Sep 2026

University of New Hampshire Durham, USA maisha.mastora@unh.edu

University of New Hampshire Durham, USA dean.sullivan@unh.edu

Abstract

Keywords

Automated program repair (APR) research has been constrained to design time. Current techniques localize and fix bugs in RegisterTransfer Level (RTL) or High Level Synthesis (HLS) designs before a chip reaches production. Once a hardware vulnerability surfaces post-silicon, the patch content must be manually generated. Existing automation methods address patch deployment but not patch synthesis. Based on established pre-silicon APR methods, we study the feasibility of extending to this firmware layer a dictionaryguided, localize-synthesize-validate APR methodology originally developed for RTL repair. An automated commit-clustering miner surfaces recurring fix templates across the EDK II (UEFI) firmware repository’s full commit history without depending on previously known Common Vulnerabilities and Exposures (CVE) identifiers, recovering all three known CVE-fix campaigns and surfacing two additional candidate bug families. Grounding our detectors in real fix evidence, we build four independent localizers: missing speculation barriers in C (CVE-2017-5753, Spectre v1), missing bounds checks before array writes in C (decompression library CVE), missing Return Stack Buffer (RSB)-stuffing macro calls in x86 assembly (CVE-2017-5715), and missing integer-overflow guards in Hand-Off Block (HOB) creation C code (surfaced by the miner itself). All four achieve 100% recall; precision ranges from 2.1–15.5% on the C families to 100% on the assembly and HOB families. We perform root-cause analysis for the C-family false positives mechanically, which attributes 77–90% to two intra-procedural causes, isolating the inter-procedural alias-analysis gap as a measured 15–20% rather than an estimate. A held-out test confirms Spectre v1 localization holds at 100% recall on unseen files; a fifth, independently built dictionary entry (CVE-2018-3630) shows the methodology extends to a new bug signature at low added cost; and a naive syntactic baseline recalls at most 14% where our targeted detector recalls 100%. We frame these results within a broader research agenda for a unified hardware-to-firmware correctness lifecycle.

Automated program repair, UEFI firmware, EDK II, Spectre, speculative execution, hardware security, commit mining

CCS Concepts • Security and privacy → Hardware attacks and countermeasures; Software security engineering; • Software and its engineering → Software defect analysis.

This work is licensed under a Creative Commons Attribution 4.0 International License. FTA ’26, Oakland, CA, USA © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2969-0/2026/10 https://doi.org/10.1145/3842651.3843185

ACM Reference Format: Maisha Mastora and Dean Sullivan. 2026. From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds. In Proceedings of the 1st International Workshop on Firmware Testing and Analysis (FTA ’26), October 4–9, 2026, Oakland, CA, USA. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3842651.3843185

1

Introduction

Hardware security vulnerabilities discovered at post-silicon levels present a fundamental problem. The artifact that contains the bug cannot be changed. The Spectre and Meltdown disclosures made this concrete at scale, engineers spent months writing hand-crafted microcode and firmware patches for vulnerabilities rooted in the speculative-execution microarchitecture of billions of already distributed processors [5, 7]. Each patch had to be manually localized, synthesized, and validated, then manually re-applied across every affected firmware branch and product variant. APR has not addressed this class of problem. State-of-the-art RTL repair systems (CirFix [1], RTL-Repair [6], SRepair [8], and dictionary-guided mutation operator based fixes [10]) focus on design time, producing a corrected design before fabrication. Nothing in this pipeline applies once the chip has taped out. Post-silicon, the firmware layer (BIOS/UEFI code that initializes the platform before the operating system loads) is the only accessible portion for software-level workarounds. A different line of work on firmware hotpatching (RapidPatch [3], AutoPatch [13], StackPatch [15]) automates deployment without rebooting, but explicitly depends on a human-written correct patch. As AutoPatch [13] states directly, all existing hotpatching approaches require developers to write the patch manually. Automatically localizing every vulnerable site and synthesizing a correct fix from a bug-class description before deployment has, to our knowledge, not been explored. We ask whether the core APR methodology transfers from RTL to this firmware layer. The methodology we explore is dictionaryguided and commit-driven. The pipeline we built mines real historical fixes to build a dictionary of fix patterns, localizes bug sites matching those patterns, instantiates a repair template at each site, and validates it against the historical fix as ground truth. This mirrors how prior RTL repair work derived Design-Under-Test (DUT)-specific mutation operators from production hardware bug fixes [10]; the question is whether the same three-step structure survives when the target language changes from Verilog to C and

FTA ’26, October 4–9, 2026, Oakland, CA, USA

assembly, the oracle changes from a testbench simulator to a commit history, and the bug taxonomy shifts from functional RTL errors to security-relevant firmware vulnerabilities. To assess our hypothesis, we target the EDK II (TianoCore) UEFI firmware [14], which provides a well-documented history of CVE repairs across C-language System Management Mode (SMM) handlers and x86 assembly SMI entry stubs. The contributions of this paper are: • An automated fix-template miner that clusters EDK II’s 36,153-commit history by diff-content similarity, recovers all three major CVE-fix campaigns without supplying their names, and surfaces two further candidate families. • Four independent localization and repair detectors, each grounded in real fix evidence: missing speculation barriers in C (Spectre v1); missing bounds checks in C (decompression); missing RSB-stuffing in x86 assembly; missing integer-overflow guards in HOB creation C code (minerdiscovered). • A root-cause triage of the false-positive population on the two low-precision C families, attributing 77–90% to two intra-procedural causes and isolating a measured 15–20% alias-analysis gap on the Spectre v1 family, upgrading the precision limitation from an estimate to a diagnosis. • A measured cost of dictionary extension: a fifth, independently built entry (CVE-2018-3630), compared against two naive syntactic baselines that recall at most 14% where our targeted rules recall 100%: two real sites have no syntactic guard signature at all, unreachable by any such baseline regardless of tuning. • A quantified manual-effort cost: 13 distinct fix sites were manually re-applied to stable branches 31 additional times, at up to 62 days of propagation lag, and a demonstration of automated propagation to 4 stable branches for one fix site.

2

Background and Related Work

APR for hardware: Published hardware APR systems operate at design time and follow a specific structure: propose a candidate, simulate against a testbench oracle, accept or reject. CirFix [1] applied genetic programming to synthesizable Verilog guided by testbenchoutput divergence; RTL-Repair [6] constrains candidates to be synthesizable via symbolic execution; SRepair [8] replaces GP with LLM-guided mutation. Recent work [10] established dictionaryguided mutation for Verilog repair, showing DUT-specific mutation dictionaries derived from the design outperform generic operators. The insight this paper builds on: the methodology (build a dictionary of fix patterns, localize matching sites, instantiate a repair, validate) does not inherently require a simulation oracle or an HDL. Our approach is derived from the hypothesis that, on changing the oracle to a commit history and the target language to firmware C/assembly, the three-step structure should still apply. To our knowledge, no existing RTL/HLS APR system addresses the scenario where the buggy artifact is a fabricated, deployed chip that cannot change. UEFI firmware and the patching landscape: UEFI/EDK II firmware runs in System Management Mode (SMM), a privileged x86 environment isolated from the OS; vulnerabilities there can give an attacker full platform control before any software protection layer

Maisha Mastora and Dean Sullivan

applies [2]. Discovery-side tools (CHIPSEC’s configuration and protection checks, static analysis on UEFI modules) surface vulnerabilities but produce reports, not patches. Deployment-side hotpatching automates applying a patch without rebooting: HERA [11] redirects execution via ARM Cortex-M hardware breakpoints; RapidPatch [3] executes patches through a small on-device bytecode runtime so one patch release covers heterogeneous devices; AutoPatch [13] statically analyzes an official patch and generates an equivalent hotpatch automatically; StackPatch [15] extends coverage via stackframe reconstruction. None of these produce the patch content itself (AutoPatch and StackPatch both state this limitation explicitly). In the EDK II history we study, a security engineer manually identifies each site, writes the fix, and re-applies it to every affected stable branch, taking up to 62 days of propagation lag for some fixes (Section 4.1). Automated repair would slot in immediately upstream of hotpatching. Commit history mining: Commit history mining originates with SZZ [12], linking bug-fix commits to introducing commits for defect prediction. In ongoing work on RTL bug mining, we applied this lineage to production RTL repositories to derive mutation operators from actual bug fixes; as that work is unpublished and under review, we omit its results here. In this context, we adapt the same lineage differently: we cluster fixes by content similarity to surface recurring fix templates, related to the recurring-fix-pattern literature [9] but focused on security-relevant CVE remediations, where the fix for a hardware vulnerability class is usually architecturally constrained. Spectre and firmware-level mitigations: The Spectre/Meltdown disclosures [5, 7] are the most prominent prior works for this paper’s problem: hundreds of hand-written patches, none fixable by a chip respin. RSB-stuffing addresses Spectre v2 at SMM exit [4]: the Return Stack Buffer may underflow to branch prediction on return from SMM, so the fix fills it with harmless entries before the resumefrom-SMM (rsm) instruction. Bounds-check-bypass (Spectre v1) addresses array accesses where the processor may speculatively execute an out-of-bounds access before a guard resolves, requiring a speculation barrier (AsmLfence()) between check and use. Both were applied manually, site by site. Our mining process quantifies the scale of that effort. The RSB fix touched 3 original sites and was then backported (manually re-applied to older maintained release branches) 4 times, while the bounds-check-bypass fix touched 7 sites and was backported 18 times.

3

Methodology

Figure 1 summarizes the approach. Mining the commit history of a firmware repository yields a set of dictionary entries, one per recurring bug family. Each entry then supplies the three components that drive the repair pipeline: a pattern that locates candidate sites, a template that instantiates the fix, and an oracle that checks the result independently of the human fix. The remainder of this section defines the dictionary, describes the miner that builds it, and explains how each entry becomes a working detector.

From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds

FTA ’26, October 4–9, 2026, Oakland, CA, USA

Dictionary construction, once per repository

Commits

Fingerprint

Cluster

Entries

36,153 total

155 CVE fixes

16 candidates

5 families

𝜎 signature

𝜌 template

𝜈 oracle

Firmware

Localize

Synthesize

Validate

C and x86 asm

line scanner

bind, insert

match or gcc

Taint filter

Patched source

Spectre v1 only

Figure 1: Dictionary-guided repair applied to firmware. Mining the repository’s commit history (top) yields one dictionary entry per bug family; each entry supplies the bug signature 𝜎, repair template 𝜌, and validation oracle 𝜈 that drive the corresponding stage of the repair pipeline (bottom). Gray denotes data and artifacts, teal denotes processing steps, and amber denotes the one stage that runs for a single family rather than all of them.

3.1

The Firmware Repair Dictionary

We first make precise what we mean by a dictionary, since the term is inherited from RTL repair and its transfer to firmware is the conceptual core of this work. In dictionary-guided RTL repair [10], the dictionary is a DUT-specific mutation vocabulary derived from the Verilog grammar and the buggy design: it enumerates the structurally valid, category-constrained token edits available for that design, so that the repair search is confined to grammar-plausible candidates rather than a generic edit space. We carry the same principle to firmware. A firmware repair dictionary is a set of entries, one per bug family, where each entry is a triple ⟨𝜎, 𝜌, 𝜈⟩: 𝜎 (the bug signature) indicates the structural pattern that identifies a vulnerable site (for example, a guard clause with no subsequent AsmLfence barrier); 𝜌 (the repair template) is the code to instantiate at that site (for example, an inserted AsmLfence () call); and 𝜈 (the validation oracle) is the check that the instantiated repair is correct independently of the human fix (for example, a structural match or a gcc -fsyntax-only compile). Figure 2 makes this concrete for the HOB integer-overflow family. The bug signature is an alignment expression that rounds a length up to the next multiple of eight whose immediately preceding non-blank, non-comment line is not an overflow guard, so the addition can wrap the sixteen-bit length and yield an allocation far smaller than intended. The repair template is a guard on the same variable, bounded against the maximum representable value less the rounding slack, inserted before the expression. The validation

/* Vulnerable site matched by the bug signature */ HandOffHob = GetHobList (); HobLength = (UINT16)((HobLength + 0x7) & (~0x7)); /* Synthesized output */ HandOffHob = GetHobList (); // // Check HobLength to avoid integer overflow in alignment. // if (HobLength > MAX_UINT16 - 0x7) { return NULL; } HobLength = (UINT16)((HobLength + 0x7) & (~0x7));

Figure 2: A dictionary entry applied to the HOB integeroverflow family. The signature matches an alignment expression whose immediately preceding non-blank, non-comment line is not an overflow guard. The template is bound to the variable name at the located site and indented to match the surrounding code, so the same entry applies unchanged to sites that align a differently named length.

oracle is the pair of checks described in Section 4.2: a structural test that a guard on that same variable appears in the ten lines preceding the expression, and a syntax-only compile of the enclosing function against minimal type stubs.

FTA ’26, October 4–9, 2026, Oakland, CA, USA

3.2

Automated Fix-Template Mining

To avoid hand-picking known CVE campaigns, we mine EDK II’s full commit history for recurring fix patterns without any prior knowledge of bug names or identifiers. The miner first collects every commit whose message references a CVE, giving 155 candidates. For each commit, it extracts a content fingerprint made up of the lines added and removed across C, header, and assembly files, stripping unrelated metadata like copyright notices. It then groups commits by similarity in two passes. The first pass does an exact match on the fingerprint. The second applies a structuralskeleton match, replacing all variable names and numeric literals with placeholder tokens, so two commits that follow the same fix shape but use different variable names still group together. For example, one HOB fix inserts if (HobLength > MAX_UINT16 0x7) and another inserts if (DataLength > MAX_UINT16 - 0x7). After tokenization both become if ( ID > ID - NUM ) and cluster together. Any group of two or more commits is then reported as a candidate bug family. Of the 155 candidates, 23 produced empty fingerprints, meaning their diffs contained no changes to C, header, or assembly files, and were excluded from clustering. The remaining 132 commits yielded 16 clusters, and all three known CVE fix campaigns were recovered automatically without the miner being told their names. The code changes themselves were distinctive enough to form the clusters. The miner also surfaced two previously unlabeled candidates: an integer-overflow check in the Hand-Off Block creation code, and a pointer alignment applied in only one branch of a conditional. We build full detectors for both (Sections 4.2, 4.4). One cluster was discarded after manual inspection revealed it grouped two commits that fixed completely unrelated bugs by coincidental structural similarity. This reflects an inherent limitation of content-similarity clustering, which produces candidates rather than verified families. In this work, final confirmation was manual. Automating this confirmation step, so that spurious clusters like this are rejected without manual review, remains an open problem.

3.3

Detector Construction

Each dictionary entry becomes a detector through three components: a localizer that finds candidate sites, a synthesizer that instantiates the repair, and, where a family needs it, a precision filter that prunes spurious candidates. We describe each in turn. Table 1 states the five entries in the form introduced in Section 3.1; the fifth is built in Section 4.4 to measure what extending the dictionary costs. 3.3.1 Localization. We build the bug signature 𝜎 as a lightweight line and brace-depth scanner rather than a full parser. The scanner reads each source file, tracks block structure through brace depth, and looks for the structural pattern that identifies a vulnerable site. When it finds a match, it checks whether the corresponding repair template 𝜌 is already present at that location, which happens when a duplicate copy of the code was patched in an earlier commit. If the repair is absent, it flags the site as a candidate. What changes across families is the specific pattern the scanner looks for; the three-step structure of locate, check, flag stays the same. We chose scanners over full parsers because EDK II’s headers require heavy stub-work for off-the-shelf parsers, and the fix patterns are syntactically regular enough that structured scanning suffices.

Maisha Mastora and Dean Sullivan

3.3.2 Synthesis. At each flagged site, the synthesizer instantiates the repair template 𝜌 directly rather than searching a candidate space. It binds the variables in the template to the names at the located site and inserts the result. Because the template is fixed, correctness reduces to whether the located site and the instantiated template match the historical fix, which we evaluate in Section 4. Ground truth for this comparison is derived directly from the fix commits by script, with no human labeling. For C families, it is the first real statement following each inserted guard in the fixed file. For assembly, it is the ordinal position of each resume-from-SMM (rsm) instruction, verified by comparing per-file counts between the buggy and fixed versions. 3.3.3 The Precision Filter. The RSB stuffing, HOB, and decompression families localize cleanly, with few or no spurious candidates. The Spectre v1 family required additional engineering. A Spectre v1 gadget is a guard clause that checks a value before it is used in a speculative memory access, and the fix inserts an AsmLfence() barrier between the check and the use. The problem is that C code contains many guard clauses that match this structural shape but protect no memory access at all, so the base detector flags far more candidates than are real. To prune these, we implement a forward taint-propagation postfilter. Starting from the identifiers in the guard condition, the filter scans forward 60 lines (set above the maximum check-to-use distance observed across fix sites, with recall insensitive to the exact window), propagating taint through alias assignments and CopyMem calls, and retains a candidate only if a tainted identifier eventually reaches a memory operation, such as a subscript or a pointer dereference. The intuition is that a real Spectre gadget must eventually access memory speculatively; a guard whose checked value reaches no memory operation is almost certainly not a real gadget.

4

Empirical Evaluation

We evaluate each detector on the EDK II clone described above, organized as three questions: • How large is the manual effort our pipeline targets? (Section 4.1) • How well does each detector localize and repair its family? (Sections 4.2–4.4) • Does the approach earn its complexity over naive alternatives? (Section 4.5) Ground truth throughout is extracted by script from real commit diffs, with no human labeling. We build each detector by inspecting a set of real fix commits, which we call the training set, and evaluate generalization on held-out files never examined during construction. No machine learning is involved; the train/held-out split tests whether a hand-written rule overfits the examples it was built from, in the same sense as a software-engineering train/test split.

4.1

Commit Mining and Backport Cost

Before measuring detector accuracy, we quantify the manual effort the pipeline is meant to replace. Table 2a summarizes the three CVE campaigns after deduplicating backports. We identify backports two ways: the explicit cherry picked from commit trailer that

From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds

FTA ’26, October 4–9, 2026, Oakland, CA, USA

Table 1: The five dictionary entries. Each is a triple of a bug signature, a repair template, and a validation oracle. Four entries share a line-local signature; the alignment entry requires comparing two branches of a conditional, which is why its detector is structurally different. Entry

Lang.

Bug signature 𝜎

Repair template 𝜌

Validation oracle 𝜈

Spectre v1

C

Insert barrier call

Structural match to fix commit

Decompression

C

Insert bounds check

Structural match to fix commit

RSB stuffing

asm

Insert macro call

Ordinal match to fix commit

HOB overflow

C

Insert overflow guard

Structural test and compile

Alignment

C

Guard clause with no following barrier Array write with no preceding bounds check Resume-from-SMM not preceded by stuffing macro Alignment expression with no bound on the variable Pointer aligned in one branch only

Hoist call after the block

Structural test, compile at one site

Git records on a re-applied commit, and, for three duplicates that carried no such trailer, a match on the commit’s content fingerprint. The pattern that motivates automation is the gap between original sites and total effort. Across 13 distinct fix sites, engineers re-applied the same fixes to stable branches 31 additional times (avg. 2.38 per site), and one fix took 62 days to reach all affected branches. Every one of those 31 re-applications is a place a copy could have been missed, which is precisely the failure a detector that re-scans each branch avoids.

4.2

Localization and Repair Results

Table 2c reports recall and precision for all four detectors. Recall is the fraction of real fix sites the detector finds; precision is the fraction of flagged sites that are real. All four reach 100% recall, so the discriminating axis is precision, which is where the families differ sharply. Spectre v1 (C). With the data-flow filter, the detector finds all 7 sites at 9.7% precision. To test whether it merely memorized the training files, we froze the detector (verifying its checksum was unchanged) and ran it on 4 files it had never seen, each 3–10× larger than the training files. It again found all 7 held-out sites, evidence that the rule generalizes rather than overfits. Precision falls to 2.1% on these files because larger files contain proportionally more generic guards that share the vulnerable shape without being vulnerable. The lexical taint filter is shown as a negative result: it drops recall to 71.4%, missing one site buried 10 lines deep in nested blocks and one where the checked value reaches memory through a twohop alias chain (CommBuffer→CopyMem→mVariableBufferPayload→SmmVariableHeader) unreachable by literal name matching. The forward data-flow filter recovers both. Decompression (C). The array-write bounds-check detector finds all 9 sites across 3 files at 15.5% precision, on its first iteration with no tuning. As a check that families genuinely need separate detectors, we ran the frozen Spectre v1 detector on these files: it finds 0 of 9 (102 candidates, none real), confirming the two families do not share a signature. RSB stuffing (x86 assembly). The detector flags every resumefrom-SMM (rsm) instruction not preceded by the StuffRsb macro,

and reaches 100% recall and 100% precision (14/14, no false positives) across 12 files in both MASM and NASM assembly dialects. Precision is perfect here for a structural reason, not luck: rsm appears only at SMM exit and nowhere else, so an unguarded rsm is unambiguously a real site, unlike a C comparison guard that can appear in countless benign contexts. HOB integer overflow (C, miner-discovered). This family was surfaced by the miner rather than chosen in advance, so it is a test of the full pipeline end to end. The detector reaches 100% recall and 100% precision (3/3). We validate it two independent ways that do not simply re-check against the human fix: a structural oracle confirming the alignment expression is preceded by a guard on the same variable, bounded against MAX_UINT16 (3/3 pass on patched files, 0/3 on the unpatched originals), and a gcc -fsyntax-only compile of the extracted CreateHob() function with minimal stubs, confirming the instantiated patch is syntactically valid C (3/3 pass).

4.3

False-Positive Root-Cause Triage

The C-family precision numbers are low, so we ask a sharper question than “how many false positives,” namely “why does each one occur.” We mechanically classify every false positive from the two low-precision C families into categories. This classification runs over all candidates with no filtering, so unlike the precision filter in Section 3.3.3, it carries no risk to recall; it is a diagnostic, not a filter. For Spectre v1 the categories are: no-memory-use, where the checked variable never reaches a subscript or memory-op argument in the forward window; status/guard, where every identifier is a status, error, or NULL-style check rather than a data access; aliasgap, where the value does reach a memory access but the link back to the SMM communication buffer crosses out of the function and cannot be traced within it; and other. For decompression the categories distinguish loops with constant or runtime bounds, literal indices, read-only accesses, and other. Table 3 gives the breakdown. For Spectre v1, the two intraprocedural categories (no-memory-use and status/guard) account for 81.4% of false positives on the training set and 76.7% held-out, which leaves the genuinely hard inter-procedural alias-gap as a measured 15–20%, not a vague estimate. For decompression, the provably-safe and non-write categories account for 79.6%, with no

FTA ’26, October 4–9, 2026, Oakland, CA, USA

Maisha Mastora and Dean Sullivan

Table 2: Manual remediation cost and detector accuracy across the four bug families. (a) EDK II CVE remediation campaigns: distinct original fix sites vs. manually re-applied backports. Campaign

Sites

Bkpt

Avg

Bounds check (5753) RSB stuffing (5715) Decompression

7 3 3

18 4 9

2.57 1.33 3.00

Total

13

31

2.38

(c) Localization results. GT: ground-truth sites; Cand: candidates flagged; h/o (held-out) applies only to Spectre v1 (4 unseen files, 7 GT sites); “unfiltered” is the detector’s three rules with no taint post-filter, distinct from the naive baselines in Section 4.5.

(b) Naive syntactic baselines vs. our detector on the Spectre v1 ground truth (7 sites); see Section 4.5. Method Any comparison if Any if statement Our detector

Cand

Rec.

Prec.

110 159 79

0.0% 14.3% 100%

0.0% 0.6% 8.9%

Bug family

Filter

Spectre v1 (C)

unfiltered +lex-taint +data-flow

GT Cand

Rec.

Prec.

7 7 7

79 100% 8.9% 49 71.4% 10.2% 72 100% 9.7%

Spectre v1 (h/o) +d-flow

7

329

100%

Decompress (C) targeted RSB (asm) targeted HOB (C) targeted

9 14 3

58 14 3

100% 15.5% 100% 100% 100% 100%

2.1%

Table 3: False-positive root-cause triage (% of each dataset’s FPs, counted over the filtered candidate set). Dataset (FPs)

No-mem-use

Status/guard

Alias-gap

Other

78.0% 64.3%

3.4% 12.4%

15.3% 19.9%

3.4% 3.4%

Spectre v1 train (59) Spectre v1 held-out (322) Dataset (FPs)

Const-loop

Runtime-loop

Literal

Read

Other

61.2%

10.2%

10.2%

8.2%

10.2%

Decompression (49)

alias component at all. Across all three datasets, 77–90% of false positives trace to intra-procedural causes that better local analysis could remove. The residual “other” category on held-out Spectre v1 (11 sites, all CommBufferPayloadSize guards) is not detector noise: these are genuinely attacker-facing checks that the original campaign chose not to fence, so the detector’s precision floor coincides with a human exploitability judgment rather than an error.

4.4

site for compilation because its enclosing function depends on FFSspecific macros, so that site rests on the structural oracle and the exact match alone. Once the commit evidence was in hand, building this entry took minutes, against the days-to-weeks timescale of the manual campaigns in Section 4.1. This is preliminary evidence that the cost of extending the dictionary scales with a bug signature’s structural complexity, not with the size of the codebase.

Extensibility: A Fifth Dictionary Entry

To measure what adding a new bug family costs, we build a fifth entry for the miner’s alignment cluster (CVE-2018-3630, surfaced in Section 3.2): a pointer is assigned in both branches of an if/else, but the ALIGN_POINTER call is applied in only one branch, leaving the other path unaligned. The repair moves the alignment call to a single unconditional statement after the block. This signature is harder than the other four: rather than a line-local pattern, it requires reasoning about the asymmetry between two branches, so its detector uses a character-level brace matcher that resolves nested blocks rather than a line scanner. The two known real sites served as a regression check while building it. The detector reaches 100% recall and 100% precision (2/2) on both real sites (FwVolDxe/FwVol.c, PeiCore/FwVol.c), and the instantiated repair reproduces the historical fix exactly at both (the only diff is an unrelated copyright-year line). We also validate the repair independently of the human fix, as we did for the HOB entry: a structural oracle confirming exactly one unconditional alignment call on the assigned variable after the block passes at both sites, and a gcc -fsyntax-only compile of the extracted function passes at the FwVolDxe site. We did not stub the PeiCore

4.5

Naive Baseline Comparison

Finally, we check that the targeted rules earn their complexity. A natural objection to any pattern-based detector is that a much simpler pattern might work just as well, so we compare the Spectre v1 detector against the two simplest signatures someone would reach for before building a targeted rule (Table 2b): flagging every if(...) that uses a comparison operator, and flagging every if(...) at all. If either matched our recall, the targeted rule would not be worth its complexity. Neither comes close. The comparison-operator baseline (110 candidates) finds zero real sites. The reason is that most real guards are not value comparisons at all but function-call checks such as if (!EFI_ERROR (Status)), which test whether a prior operation succeeded before running the protected code. Our detector had to be extended to recognize this function-call form of guard, added after inspecting a real site it first missed, and it is invisible to a comparison-operator match. The any-if baseline (159 candidates) is broader but almost useless, finding only 1 of 7 sites at 0.6% precision, against our detector’s 7 of 7 at 8.9%.

From Silicon to Boot Code: Extending Automated Program Repair to Firmware-Layer Security Workarounds

The sharpest evidence is structural rather than numerical. Two real sites in SmmLockBox.c have no if guard anywhere near the vulnerable line: the tainted data flows straight into a function-call parameter (SaveLockBox(&TempLockBoxParameterSave.Guid, ...)). No if-based baseline, however carefully tuned, can ever reach these two sites, because there is no if there to match. Our detector reaches them because its dictionary-guided rule recognizes the known validation-function call itself, not the surrounding syntax, which is direct evidence that the rule does real work beyond generic scanning.

4.6

• Precision reflects the detectors as built rather than as diagnosed. The triage in Section 4.3 identifies intraprocedural causes behind 77–90% of false positives, and those findings are not yet implemented as filters. The C-family precision in Table 2c is therefore a lower bound, and we have not measured how far better local analysis would move it. • Baseline comparison is limited to syntactic alternatives. The baselines in Section 4.5 establish that a trivial pattern does not suffice for this problem. We did not compare against a general-purpose static analyzer or a language model prompted with the same fix commits, so we cannot say how the detectors fare against a serious alternative. • Template instantiation is bounded by the vocabulary available at mining time. On held-out sites the insertion location is correct while the inserted call is not, because the historical fix introduced a wrapper abstraction that did not exist beforehand (Section 4.6). Synthesizing a repair that introduces a new abstraction is a distinct problem from instantiating a known one. • Detection rules and ground truth derive from the same commits. Freezing the rules before the held-out evaluation mitigates this circularity and recall survives, though the bug families were still identified by examining fixes. A family that leaves no CVE reference in a commit message would fall outside the miner’s reach. • The evidence base is one codebase with few sites per family. All experiments use EDK II, with per-family counts ranging from 2 to 14. These are feasibility results, and extending to other firmware codebases (Section 6) is required before they support a generalization claim. • The scope is security remediation rather than general firmware defects. All five families are CVE remediations whose fixes are architecturally constrained, which is what makes a fixed repair template viable. Whether the methodology extends to functional bugs, where the correct fix rarely has a canonical form, remains open.

Repair-Template Instantiation

Because the repair instantiates a fixed template rather than searching a space of candidates, its correctness reduces to a single question: does the located site plus the instantiated template match what the human actually wrote. Per true-positive site, we extract the inserted block from our patched file and from the human-fixed file and compare them structurally. On training sites the match is exact, 7/7, including indentation. On held-out sites the insertion location is correct in all 7, but the inserted call is wrong in all 7: we insert AsmLfence (), whereas the human wrote MemoryLoadFence (), an abstraction the fix commit itself introduces (it resolves to AsmLfence () in SMM and to nothing in DXE). Template instantiation reproduces a fix that has a single fixed form, but it cannot invent a new abstraction that did not exist before the fix. Localization stays correct in both cases, so the limitation is in synthesis, not in finding the site.

4.7

Patch Propagation Experiment

The last experiment targets the backport cost from Section 4.1 directly: can the repair be propagated to stable branches automatically instead of cherry-picked by hand. For FaultTolerantWriteSmm.c and 4 stable branch targets (each diverged 47–49 lines from the source), we test three strategies: Strategy A applies the patch directly with patch(1), B allows fuzzy context matching (fuzz=3), and C re-runs the detector independently on each branch instead of transplanting the patch. All three succeed on all 4 branches. Strategy C is the most robust, since it re-localizes on each branch and needs no matching context lines at all. This replaces 4 of the 31 manual cherry-picks for this one site. The 62-day lag from Section 4.1 belongs to a different site (Variable.c) that uses the MemoryLoadFence abstraction our pipeline does not yet synthesize, so this experiment is scoped to the correct-instantiation cases.

5

Limitations

The limitations below bound what the present results support rather than what the method could eventually do. We are addressing several of them in ongoing work, and Section 6 states the concrete next steps. • Validation is structural rather than semantic. The oracles confirm that a repair is placed at the correct site, that it constrains the correct variable, and, for two entries, that the enclosing function still compiles. Establishing that the inserted code mitigates the vulnerability requires an exploit differential or a regression suite, neither of which we ran.

FTA ’26, October 4–9, 2026, Oakland, CA, USA

6

Open Questions

Precision via inter-procedural analysis. Intra-procedural filters cannot close the alias-analysis gap (Table 3); whether full alias analysis reduces candidates to a practically triageable count (5– 10/file rather than 60–300) remains open. Patch propagation at scale. We demonstrated propagation for one site across 4 branches; scaling to all 13 sites/31 backports is open, especially whether independent re-detection remains reliable when synthesis produces the wrong function name. Build-oracle validation. Ground-truth string comparison does not guarantee behavioral correctness; compiling synthesized patches against the public TianoCore build system and running its unit tests is a concrete next step. Benchmark extension. The 18 fix sites across five families (four evaluated, one extensibility case study) are a starting benchmark; extending to other codebases (coreboot, u-boot, BMC firmware) would broaden the generalizability claim, now validated end-to-end by both the HOB and alignment results.

FTA ’26, October 4–9, 2026, Oakland, CA, USA

7

Discussion

Our results indicate that the dictionary-guided localize-synthesizevalidate structure transfers from RTL to firmware across four structurally different bug families and two languages, with a fifth entry added at low cost. We read firmware-layer repair as one component of a broader hardware-to-firmware correctness lifecycle, in which pre-silicon RTL and HLS repair corrects a design before fabrication and firmware repair addresses the same vulnerability classes once the silicon can no longer change, with the dictionary abstraction as the shared interface across both regimes. The held-out result (100% recall on unseen, larger files) is the property such a lifecycle would require for deployment: rules built from a handful of fix commits generalize rather than memorize.

8

Conclusion

We have shown a dictionary-guided APR methodology transfers from RTL repair to firmware-layer security workarounds across four structurally different bug families spanning C and x86 assembly, and extends to a fifth independently built entry at low added cost. All four evaluated families reach 100% recall including a held-out test, our root-cause triage isolates a measured 15–20% alias-analysis gap on the Spectre v1 family, and template instantiation reproduces the historical fix exactly on all training sites; no single rule set covers more than one bug family, but the same methodology does.

Acknowledgments This research was supported by the National Science Foundation (NSF) under Grant CNS-2533802 on “Ensuring the Security of SafetyCritical Embedded Systems.”

References [1] Hammad Ahmad, Yu Huang, and Westley Weimer. 2022. CirFix: Automatically repairing defects in hardware design code. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. Association for Computing Machinery, New York, NY, USA, 990–1003. doi:10.1145/3503222.3507763 [2] Oleksandr Bazhaniuk, Yuriy Bulygin, Andrew Furtak, Mikhail Gorobets, John Loucaides, Alexander Matrosov, and Mickey Shkatov. 2015. A New Class of Vulnerabilities in SMI Handlers. In CanSecWest Applied Security Conference. https: //www.c7zero.info/stuff/ANewClassOfVulnInSMIHandlers_csw2015.pdf. [3] Yi He, Zhenhua Zou, Kun Sun, Zhuotao Liu, Ke Xu, Qian Wang, Chao Shen, Zhi Wang, and Qi Li. 2022. RapidPatch: Firmware hotpatching for real-time

Maisha Mastora and Dean Sullivan

embedded devices. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, 2225–2242. [4] Intel Corporation. 2018. Speculative Execution Side Channel Mitigations. Technical Report 336996-006. Intel. [5] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, and Yuval Yarom. 2020. Spectre attacks: Exploiting speculative execution. Commun. ACM 63, 7 (2020), 93–101. doi:10.1145/3399742 [6] Kevin Laeufer, Brandon Fajardo, Abhik Ahuja, Vighnesh Iyer, Borivoje Nikolić, and Koushik Sen. 2024. RTL-Repair: Fast symbolic repair of hardware design code. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3. Association for Computing Machinery, New York, NY, USA, 867–881. doi:10.1145/3620666. 3651346 [7] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, Mike Hamburg, and Raoul Strackx. 2020. Meltdown: Reading kernel memory from user space. Commun. ACM 63, 6 (2020), 46–56. doi:10.1145/3357033 [8] Zizhen Liu, Deheng Yang, Xiaoguang Mao, Jiayu He, Guangda Zhang, Yan Lei, and Jiang Wu. 2026. SRepair: Symbolic Regression-Based Repair for Hardware Design Code. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 45, 3 (2026), 1509–1522. doi:10.1109/TCAD.2025.3603097 [9] Matias Martinez, Westley Weimer, and Martin Monperrus. 2014. Do the Fix Ingredients Already Exist? An Empirical Inquiry into the Redundancy Assumptions of Program Repair Approaches. In Companion Proceedings of the 36th International Conference on Software Engineering. Association for Computing Machinery, New York, NY, USA, 492–495. doi:10.1145/2591062.2591114 [10] Maisha Mastora and Dean Sullivan. 2026. Dictionary-Guided Mutation Operators for Automated HDL Repair. In Proceedings of the 35th IEEE Microelectronics Design and Test Symposium (IEEE MDTS 2026). IEEE. To appear in IEEE Xplore. [11] Christian Niesler, Sebastian Surminski, and Lucas Davi. 2021. HERA: Hotpatching of Embedded Real-time Applications. In Network and Distributed System Security Symposium (NDSS). Internet Society. doi:10.14722/ndss.2021.24159 [12] Giovanni Rosa, Luca Pascarella, Simone Scalabrino, Rosalia Tufano, Gabriele Bavota, Michele Lanza, and Rocco Oliveto. 2021. Evaluating SZZ implementations through a developer-informed oracle. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 436–447. doi:10.1109/ICSE43902. 2021.00049 [13] Mohsen Salehi and Karthik Pattabiraman. 2024. AutoPatch: Automated Generation of Hotpatches for Real-Time Embedded Devices. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery, New York, NY, USA, 2370–2384. doi:10.1145/3658644.3690255 [14] TianoCore. 2026. EDK II. https://github.com/tianocore/edk2. Accessed: 2026-0708. [15] Ming Zhou, Xupu Hu, Zhihao Wang, Haining Wang, Hui Wen, Limin Sun, and Peng Zhang. 2025. Dynamic Vulnerability Patching for Heterogeneous Embedded Systems Using Stack Frame Reconstruction. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security. Association for Computing Machinery, New York, NY, USA, 3855–3869. doi:10.1145/3719027. 3765200

Received 2026-07-21; accepted 2026-08-09

Related documents

• La Profilée - Intel Corporation - Ex-Ante Structural Validation#120939
• CVE-2026-17503 — MEDIUM 5.1#1091653
• CVE-2026-80154 — HIGH 8.9#1067291
• BOOTP vendor information extensions#131667
• IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry#399138