[mox1]

In software it is very difficult to "protect" against. The goal with glitching is simply two switch a 1 to a 0 somewhere (conditional branch, memory store, etc). No mater how many extra if statements and bits you set, your not going to get all of them. And the attacker can just glitch twice.

Remember, your not causing the memory to go funky, your messing with the processors reads from registers and cache. So if the next instruction says "jump not equal 0" and the attacker wants "jump not equal 1" parity can't really help you in that scenario.

If you add parity, then the attack just needs to glitch that parity check out.

Hardware defenses are the best. In particular it looks like apple is using a "PLL". It has been a while since I worked with all this stuff, but I believe the PLL makes clock glitching impractical.

For voltage glitching, I'm sure they have components that monitor voltage and either smooth it out, or just shut the chip down if it sees something weird.

[robryk]

If you need to cause glitches in a few precisely chosen moments in time, while _not_ causing glitches in some other moments in time between the former, it gets a lot harder. It gets even harder if the response to a wrong sequence of glitches is to brick the processor / erase storage.

There are also known reasonably good defenses against glitches in PC that involve checking at every end of a basic block that a subset of instructions of this block has executed.

[zerohp]

I wonder if any exploits have successfully used voltage or frequency glitching on a modern processor with DVFS (Dynamic Voltage and Frequency Scaling.)