Security is an every increasing concern across the computing industry, most recently in the emerging Internet of Things market. LLVM cannot magically write secure code, but it can help a good programmer write secure code.

The Leakage Aware Design Automation project is an EPSRC funded programme running over four years at Bristol University led by Elizabeth Oswald and Dan Page. It is looking at how all aspects of software tooling can improve security of systems, particularly by minimizing information leakage. An important part of this project is extending compiler technology, and the programme includes a postdoctoral post to research this area.

Embecosm are the "industrial supporters" of this project. Our role is to take the research ideas and make them work in real compilers - including LLVM. Some of this will be about guiding the programmer - warning of coding styles that are insecure. The other part of the project is providing assistance to the programmer in implementing advanced cryptographic techniques.

Many of the areas the compiler can warn about are related to information leakage which can be detected by variation in power usage, program timing or memory access. Where we see control flow, cycle times or memory accesses which depend on critical variables (such as cryptographic keys). Such variables can be marked with a "sensitive" attribute and the compiler warn if they or their aliases are involved in control flow, impact cycle timing or affect memory access.

There are a great many techniques that users can adopt to make their code more secure. Some of these are straightforward for the compiler to implement. For example ensuring that critical functions clear their stack frame on return or longjmp.

It is not difficult to slice the top off a memory chip and use a scanning electron microscope to read values. A (relatively) easy way to scan for candidate cryptographic keys. Bit-splitting defends against this, but scattering individual bits of critical values throughout memory, combining them on the fly for a calculation and scattering them back out to memory. By hand this is laborious in the extreme, but the compiler can reduce this to a simple "bit-split" attribute on a variable.

Other attacks use intense radiation to disrupt a processor or memory. The hope is that a critical variable will be impacted. To fix this, code will often repeat important operations. A standard compiler optimizer will promptly remove such operations, so such code is used unoptimized. But it would be much better to tell the compiler which bits of code to leave in place. Or even better to identify code at danger and let the compiler insert the duplicate operations automatically.

There are many other techniques which we hope to explore in this project, including - atomicity - balancing control flow paths to minimize information leakdave - shuffling - varying the time at which particular instructions are executed - algorithmic variation - using different algorithms at random to perform operations. - machine learning and superoptimization to minimize information leakage? - automated identification of instruction set extensions to improve cryptographic robustness?

Some of these techniques are not new, but none are yet in mainstream compilers. We plan to add these features and new ideas which our academic colleagues are researching. The project is still in its early stages and the purpose of this talk is to raise awareness and get community feedback on some of the areas we will be working on, and suggestions for other areas to consider.