Integrating Resiliator, our fault-injection framework, into Pavona for continuous testing

[Vincent Ulitzsch]

Dear Pavona Team, 

We, a team of researchers from MIT and TU Berlin, are interested in integrating our fault-injection framework, Resiliator [1], into your continuous testing (CI/CD) pipeline.

 Resiliator takes an RTL design, a firmware, and a security property as input, and outputs potential fault-injection points where a single bit-flip during computation would allow an attacker to bypass this security property. It does so through exhaustive Verilator simulation with various optimizations that increase scalability. We have successfully used this tool to uncover a security issue in the OpenTitan [2]. Under certain pipelining conditions, the ECC signal was masked and therefore ignored. 

If you are interested, let us know a good way to move forward - e.g., is there any interface that Resiliator could expose? Do you want to pull a signed and tagged commit?

- Vincent, Konrad, Niclas

[1] https://github.com/kjnsen/resiliator 
[2] https://github.com/lowRISC/ibex/issues/2188

[Aaron Durbin]

Hi Vincent, Konrad, Niclas,

This sounds like a very interesting technology. Pavona absolutely welcomes contributions.  Do you have expectations on how one should hook this into various blocks? Since it requires firmware, I assume it's more of a "full" system TB you need to target. I'm sure others on the list would have ideas, but it seems like we need to craft some specialized build targets that Resiliator can then use.

As for contributing as an individual, the Pavona project requires a completed CLA. The pdfs can be found here https://pavona.org/get-engaged under "Do I have to be a member to contribute?".  If you have further questions on that topic, please email in...@pavona.org.

Looking forward to the Resiliator integration into Pavona.

-Aaron

To unsubscribe from this group and stop receiving emails from it, send an email to pavona+un...@pavona.org.

[Ryan Torok]

Hi Vincent, Konrad, and Niclas,

I am a software engineer at ZeroRISC, one of the founding members of the Pavona project, and I designed and built Pavona's continuous integration (CI) system.

Thank you for reaching out about your Resiliator project! Several members of our team work on side-channel analysis and fault-injection mitigation (SCA/FI) and have expressed interest in integrating your FI testing framework into the Pavona CI.

I might be able to provide some guidance with integrating your work into the Pavona repository. However, I recommend familiarizing yourself with Pavona's Verilator flow first, because it's a bit different than what you might have seen on OpenTitan. Most importantly, a few months ago I updated the Bazel build system in Pavona to fetch a pinned version of Verilator from GitHub and build it from source, rather than relying on the developer's local installation. This improves reproducibility because we make sure that everyone is running the same version of Verilator. To see how this works, take a look at third_party/verilator/extensions.bzl and the surrounding files. You should be able to integrate your Resiliator fork in the same way, by copying the `third_party/verilator` directory to, e.g. `third_party/resiliator`. Creating a GitHub release of your Resiliator repo will make it easier to fetch a pinned version. I would also take a look at the Verilator CI job in Pavona, because a CI test for Resiliator would probably look similar.

Please let me know if you have more questions.

- Ryan Torok

On Fri, Jul 24, 2026 at 11:48 AM Vincent Ulitzsch <vincent....@gmail.com> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to pavona+un...@pavona.org.

[Evan Apinis]

Hi Vincent, Konrad, and Niclas,

Thanks for sharing, this is some very interesting work, and I like the idea of being able to do automated checking of critical security properties on a regular basis. I'm a hardware engineer at ZeroRISC, and have primarily made contributions to Pavona's ACC block to support post-quantum acceleration, so I'll defer to Ryan about the CI portion of this.

However, I'd be interested in hearing/discussing what it would take to extend this framework from being applied on Ibex to ACC, given its importance as the primary crypto engine and list of implemented countermeasures. Do you have any examples of how the security property input was defined for Ibex, I would love to take a look.

- Evan Apinis

[Zain Ul Abideen]

HI Vincent, Konrad, Niclas, Ryan, and Aaron,

My previous research on Fault-tolerant systems at Grenoble-INP, France, and my current work on PQC hardware accelerators are also well aligned with it. I am also happy to contribute and work together; I am looking forward to having more details, and perhaps a meeting would also be a great idea.

-- thanks  

On Fri, Jul 24, 2026 at 2:06 PM 'Evan Apinis' via Pavona <pav...@pavona.org> wrote:

Hi Vincent, Konrad, and Niclas,

Thanks for sharing, this is some very interesting work, and I like the idea of being able to do automated checking of critical security properties on a regular basis. I'm a hardware engineer at ZeroRISC, and have primarily made contributions to Pavona's ACC block to support post-quantum acceleration, so I'll defer to Ryan about the CI portion of this.

However, I'd be interested in hearing/discussing what it would take to extend this framework from being applied on Ibex to ACC, given its importance as the primary crypto engine and list of implemented countermeasures. Do you have any examples of how the security property input was defined for Ibex, I would love to take a look.

- Evan Apinis

On Fri, Jul 24, 2026 at 2:32 PM 'Ryan Torok' via Pavona <pav...@pavona.org> wrote:

Hi Vincent, Konrad, and Niclas,

I am a software engineer at ZeroRISC, one of the founding members of the Pavona project, and I designed and built Pavona's continuous integration (CI) system.

Thank you for reaching out about your Resiliator project! Several members of our team work on side-channel analysis and fault-injection mitigation (SCA/FI) and have expressed interest in integrating your FI testing framework into the Pavona CI.

I might be able to provide some guidance with integrating your work into the Pavona repository. However, I recommend familiarizing yourself with Pavona's Verilator flow first, because it's a bit different than what you might have seen on OpenTitan. Most importantly, a few months ago I updated the Bazel build system in Pavona to fetch a pinned version of Verilator from GitHub and build it from source, rather than relying on the developer's local installation. This improves reproducibility because we make sure that everyone is running the same version of Verilator. To see how this works, take a look at third_party/verilator/extensions.bzl and the surrounding files. You should be able to integrate your Resiliator fork in the same way, by copying the `third_party/verilator` directory to, e.g. `third_party/resiliator`. Creating a GitHub release of your Resiliator repo will make it easier to fetch a pinned version. I would also take a look at the Verilator CI job in Pavona, because a CI test for Resiliator would probably look similar.

Please let me know if you have more questions.

- Ryan Torok

On Fri, Jul 24, 2026 at 11:48 AM Vincent Ulitzsch <vincent....@gmail.com> wrote:

Dear Pavona Team, 

We, a team of researchers from MIT and TU Berlin, are interested in integrating our fault-injection framework, Resiliator [1], into your continuous testing (CI/CD) pipeline.

 Resiliator takes an RTL design, a firmware, and a security property as input, and outputs potential fault-injection points where a single bit-flip during computation would allow an attacker to bypass this security property. It does so through exhaustive Verilator simulation with various optimizations that increase scalability. We have successfully used this tool to uncover a security issue in the OpenTitan [2]. Under certain pipelining conditions, the ECC signal was masked and therefore ignored. 

If you are interested, let us know a good way to move forward - e.g., is there any interface that Resiliator could expose? Do you want to pull a signed and tagged commit?

- Vincent, Konrad, Niclas

[1] https://github.com/kjnsen/resiliator 
[2] https://github.com/lowRISC/ibex/issues/2188

To unsubscribe from this group and stop receiving emails from it, send an email to pavona+un...@pavona.org.

To unsubscribe from this group and stop receiving emails from it, send an email to pavona+un...@pavona.org.

To unsubscribe from this group and stop receiving emails from it, send an email to pavona+un...@pavona.org.

--

Regards,

Zain Ul Abideen

University of Idaho

Assistant Professor |  ECE | zabi...@uidaho.edu

[Vincent Ulitzsch]

Hi everyone,

We are very happy that Resiliator has gathered so much interest. We will get back to you with completed CLAs.

Let me address questions 1-by-1:

# Testbech and Security Property Definition

Resiliator indeed needs a testbench. The testbench needs to set a new GPIO output to values indicating "security property bypassed / not bypassed". For instance, for OpenTitan we implement the following:

We execute the bootrom that is loading a binary with a wrong signature and then: 
   - If the fault-injection gets the OpenTitan to execute an instruction from flash, the testbench sets the GPIO to "security property bypassed".
   - If a major alert is raised, the testbench sets the GPIO to "security property not bypassed" (injection failed).
   - If the instruction at the boot address is executed twice, we assume that the bootloader "jumped back", e.g., because of an invalid signature and also set the GPIO to "not bypassed".

Provided with this testbench (and the simulated RTL), Resiliator can conduct the simulations automatically.

# Pavona Verilator Flow

@Ryan Torok: Thanks for the pointers! We will look into this and get back to you with an adjusted GitHub release.

# Application to ACC

@Evan: For an example security property, see testbench. A note on the ACC:
The nice thing about the OpenTitan is that in the "SecureIbex" configuration, _no_ single bit-flip should propagate, since the OpenTitan is protected by dual-core lockstep. That makes it easy to define a security property.
I am not sure whether we can also define such a clear-cut security property for the ACC core/or the ACC core executing a specific crypto implementation. Happy to have a call and discuss what exact security guarantees the ACC should provide, and then how we could test those.

- Vincent