Understanding and fighting fault injections with programming languages

Would your latest program produce correct results if I skipped a statement in it? Two? Corrupted a variable at random? Then it might not be robust against _fault injection attacks_, which target hardware directly and have such effects. To be fair, nothing really resists them; still, efforts in designing protections have come a long way, relying (perhaps surprisingly) in large part on hardening code, which is much easier to deploy than new hardware. Of course, modeling the effects of physical tinkering at the abstraction level of a program requires inherent approximations, and recent work has shown that even countermeasures based on assembler-level models (the most common type) can still be bypassed by abusing micro-architectural effects. 

In this non-expert talk, I'll discuss fault attacks from a programming-language point of view. The focus will be on conceptualizing what faults and countermeasures mean for programs. I'll show how building a semantic model of a vicious kind of instruction skip leads us to design a mixed software/hardware countermeasure and formally prove it secure. I'll also touch briefly on the challenges of implementing security transformations in the LLVM compiler, which understands security about as well as C (for non-C-programmers, that's not at all). This talk will treat you to both inference rules and linker relocations.