[PhantomGremlin]

The paper mentions standard methods of attack, such as glitching voltage and/or clock.

Does anyone want to comment on how feasible it would be to defend against stuff like that in both hardware and software?

E.g. in software, instead of just storing an address in memory, store a tuple. Something like (address, ~address). Validate each tuple on use, i.e. (address ^ ~address) must result in all bits set. That's obviously a naive thing, but there are probably similar relatively low overhead things that can be done.

Same with hardware. It wouldn't be too difficult to store a parity bit to accompany each register byte. Any hardware glitching that flipped register bits would tend to result in parity errors. Parity checks are not very secure when considered individually, but collectively it would be very difficult to glitch the hardware without introducing massive numbers of parity errors.

[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.)