The Politecnico di Torino team built InjectV, a free tool that runs thousands of simulated bit flip attacks on unmanufactured RISC V chip designs, letting engineers catch hardware security flaws on a laptop; the authors report a 95.8% time saving on a standard benchmark.
The first thing to understand about a RISC-V chip is that, by the time it reaches a customer's board, its security is already baked into the silicon. Any flaw in the hardware itself, whether a missing check or a bit that flips the wrong way under stress, cannot be patched with a software update. It is a recall-class event, or worse, a quiet backdoor that lives for the life of the device.
That is why a small research team in Turin is putting their tool in front of chip designers as early as possible. InjectV, released this month as a free, open framework on the gem5 architectural simulator, lets engineers run thousands of simulated "fault injection" attacks against an unmanufactured RISC-V core and see which ones break its security checks before any silicon is produced. In their own benchmark evaluation, the Politecnico di Torino and CEA-List team reports that InjectV cuts the time required for that work by 95.8% compared with traditional fault-injection approaches on a standard academic suite.
Fault injection, in this context, is the deliberate corruption of a chip's computation or memory: flipping a register bit, perturbing an instruction, jamming a comparison value to see whether a security guarantee holds. It is a hardware security technique, not a software-testing one, and the gold-standard way to do it has long been a physical lab. That means a chip on a bench, an electromagnetic pulse generator or a clock-glitcher, and an engineer watching the device fail in real time. Those labs are accurate, slow, and expensive, which is why most design teams run them sparingly, if at all, before a tape-out.
The new framework, described in an arXiv preprint dated 10 June 2026, takes a different path. InjectV instruments the widely used open gem5 simulator and runs "white-box" attacks, in which the framework can see the internal state of the simulated core, at the architectural level. Designers mark the execution points they care about, such as control-flow decisions, security counters, and comparison operations, and InjectV automates the campaign of register and memory faults that target those points. The write-up in Semiconductor Engineering frames the work as a way to make fault-injection analysis routine during pre-silicon design rather than a research project that happens to run a few physical experiments.
The 95.8% figure deserves careful handling. The authors measured it on the FISSC benchmark suite, which includes hardened versions of a reference PIN-checking application. They did not claim it as a universal speedup, and no third party has replicated it. The paper is also a v1 preprint, four days old at the time of writing, with no peer review, no field adoption, and no shipped product behind it. What the number does suggest is that the integration overhead, including setting up each campaign, configuring the simulator, and parsing the traces, collapses when the campaign itself is automated. That is the part of fault-injection work that has historically eaten engineering weeks.
The timing matters because RISC-V is moving into markets where a silicon-level vulnerability is no longer an academic concern. Automotive safety controllers, secure-boot silicon, payment terminals, and edge AI accelerators are all shipping or piloting RISC-V cores, and a skipped authentication check or a corrupted counter on any of them is the kind of failure that ends in a recall notice, a regulator inquiry, or a quiet firmware workaround that customers will never see. If a designer can find that class of bug on a laptop in an afternoon, the cost calculus for "we should fault-test this core" changes from aspirational to practical.
There are limits to what simulation can catch. Physical fault injection covers electromagnetic pulses, voltage glitching, and persistent faults that survive reset. An architectural simulator sees the bit flip but not the package, the power rail, or the silicon delay path. Out in the real world, the security team will still want a physical campaign against the fabricated chip. What InjectV changes is the earlier, cheaper question: does the design of this core contain the kinds of security holes a glitcher would find? On the FISSC suite, the authors say, that question now takes hours rather than weeks.
The framework is open, the paper is on arXiv, and the next checkpoint is whether anyone outside the Politecnico and CEA-List group picks it up and runs the same campaign on a real RISC-V core slated for production silicon.