I am using the Chipwhisperer-Husky with the target board on CW308 UFO. I am doing some experiments with the single clock glitching using the default clock glitching setup mentioned in the tutorial notebook.
My experiment requires knowing the exact location where the glitch is inserted, e.g., which exact instruction I am glitching. In the API document, there is a parameter “ext_offset,” which is explained as follows:
After the glitch module is triggered, it waits for a number of clock cycles before generating glitch pulses.
I found this definition quite confusing. In the target firmware, I trigger the glitch module with the trigger_high() function. However, if you check the assembly of this trigger function, there will be a store instruction that sets the value in a system register and thus pulls up the corresponding GPIO pin. After the store, there is a branch instruction that returns back to the caller. All these instructions take clock cycles. So, my question is, what is the start reference point of the “ext_offset” parameter?
For example, I have the following firmware code:
trigger_high();
asm volatile (
"nop\n\t"
"nop\n\t"
"nop\n\t"
"nop\n\t"
"mov.w r7, #2\n\t"
"mov.w r8, r7\n\t"
...
);
Let’s say I want to insert a glitch exactly at the second mov instruction. In this case, what should be the value of ext_offset? If this parameter is not dependable, is there a way I can know the exact location where the glitch got inserted?
Thank you in advance.
There are a number of factors at play here, but the bottom line is that trying to glitch a specific instruction this way isn’t the right approach. On all but the most simple processors, there will be an execution pipeline, meaning that a particular assembly instruction will make its way through the processor over more than a single clock cycle. Even if there is no pipeline, glitching is partly black magic, and down at the transistor level (where glitches actually do their damage), who is to say that it’s not the cycle before (or after) your target instruction that the glitch will have the intended effect?
This is why, if you go through our glitch courses, we always set up a glitch campaign, where we sweep over a range of glitch parameters in order to find the sweet spot.
There is also, BTW, some fixed latency from when Husky receives the trigger condition to when it issues the glitch. That latency will vary depending on the trigger source (scope.trigger.module). We don’t document it because it doesn’t really matter, as per above.
What does matter is that the glitch timing is 100% repeatable: if you set scope.glitch.ext_offset to X, then the glitch will always be X cycles after some fixed time reference.
1 Like
Thanks for the reply. I understand your point of the pipeline here, and it’s good to hear that the glitch timing is 100% repeatable. The fact is that in my project, I do not really care whether the glitch can skip the target instruction or not; instead, I’m trying to figure out the effect of the glitching on different pipeline stages of a specific instruction.
For example, say if the target device has a two-stage pipeline: fetch and execute. I want to test the effect of the glitching on the fetching stage of the target instruction, so I may put a nop before the target instruction (which does nothing in its execution stage) and insert the glitch at this nop’s execution cycle (1 cycle before the target instruction), which may affect the fetching stage of the target instruction. The same principle applies to glitching the execution stage as well.
That’s why I’m pretty sure that I will need to determine the exact location of the glitch pulse in clock cycles. As you mentioned, there is some fixed latency from Husky about the glitch triggering that hasn’t been documented. Is there a way I could access this information, as it could be really helpful in my project? Thanks again for your detailed explanation.
If you have a logic analyzer or oscilloscope, the easiest way would be probe GPIO4 on your CW308, and the trigger/glitch out MCX on Husky (with scope.io.glitch_trig_mcx set to 'glitch'), and measure the actual latency that way.
Then you can measure it yourself. Note that the glitch timing will also depend on scope.glitch.offset (even if you have scope.glitch.output set to 'enable_only'). This is why I suggest you actually measure it, there are 3 different internal clock domains involved in generating glitches so latency is not a simple equation.
Otherwise, you can also adapt our Husky glitch demo notebook to your own trigger/glitch settings and use Husky’s own logic analyzer for the task.