I am currently looking for a way to perform a dependability fault injection on an open-source RISC-V core. The goal of the campaign is to measure the core’s robustness against Single Event Upset, i.e. random bit-flips occurring in the flip-flops of the emulated core.
When performing fault injection on an emulated core, the literature uses two types of approaches: run-time reconfiguration and instrumentation. The first solution modifies the bitstream at runtime to inject bitflips in the configuration file. The second solution modifies the design to allow the modification of data stored in flip-flops (which is then driven by a PC).
A first question would be to know if anyone has tried this type of (dependability) fault injection before. In the academic literature, I couldn’t find any work doing so, but the community might have done this before.
Then, I had a look into the CW305 documentation: “NAEAN0010: Power Analysis on FPGA Implementation of AES Using CW305 & ChipWhisperer” https://media.newae.com/appnotes/NAE0010_Whitepaper_CW305_AES_SCA_Attack.pdf
It is mentioned, “Using our Register Interface means you can use the matching open-source Python code on the Control Computer to perform operations such as loading input, keys, output, or triggering operations with minimal effort.”
I am unsure if the registers mentioned here are the softcore registers (x0-x31 in RISC-V cores). If this is the case, can I use the USB interface to directly modify the register’s values at runtime ? Doing so will allow me to run this SEU fault injection campaign by:
raising an interruption;
injecting the fault (single bit-flip);
waiting for a given number of clock cycles, and;
comparing the state of all registers with a golden execution to identify any fault propagation.
If anyone has tried something like this or has some insight on how to do this type of fault injection, it will be of great help!
PS : I have the ChipWhisperer lite and pro at disposal.
I don’t have an answer for the first part of your question, but I would be surprised if this hasn’t been done before. I would expect that this is much easier to do with a simulation-based approach, rather than on a physical FPGA.
Maybe. This whitepaper discusses a hardware AES core, not a microprocessor. This AES core has what hardware designers call “registers” for storing input plaintext, key, etc… which are similar to microprocessor registers. In the case of our FPGA AES core for the CW305, we provide something that allows you to easily read and write the AES core’s registers from Python. It’s also easy to add registers to customize this to your liking.
For what you want to do, you would have to make modifications to your RISC-V core to allow its registers to get modified from an outside control source in this way. It’s possible in theory, but in practice you’ll have to do the work. The CW305’s USB interface is just a handy parallel address+data interface which allows the host PC to easily exchange data with your target as it’s running. This is not the hard part of what you’re proposing to do, but yes you could use the USB interface towards your goal.
(The same can be said for any of our FPGA target boards. Our smaller FPGA target boards have a serial UART interface instead of the parallel USB interface; the serial interface has lower bandwidth, but otherwise everything I said above applies here as well.)
As compared to the simulation approach, the emulation approach is much faster, as the core is running on the FPGA instead of the simulator. Simulation is easier to begin with, but emulation is more efficient. Additionally, I would like to perform security-oriented fault injection afterwards. Using the same environment for both would be very beneficial. This is the main reason why I want to evaluate if CW allows me to inject soft errors in addition to fault attacks.
As you mention here, instrumentation-based fault injection requires modifying the processor µarchitecture to enable the bit-flip. For example, in the article [1], the authors have modified the core with XORs to enable single bit-flips (as shown in the following figure).
[1]: Hyungmin Cho. Impact of Microarchitectural Differences of RISC-V Processor Cores on Soft Error Effects. IEEE Access, 6:41302–41313, 2018.
I was wondering if the interface would enable flipping flip-flops bits without the need to modify the architecture. It doesn’t seem to be the case then
I keep the question open if anyone has tried to do the same work.
Thanks again for your help!
Then you should be able to bring that over to our target boards fairly easily.
I think what you are trying to say is that we don’t have a pre-built system which lets you do what you are interested in doing; that’s correct. But it is possible to do build one; moreover, we would welcome a pull request for this.
