Using LLVM to guarantee program integrity Simon Cook Background - PowerPoint PPT Presentation

Using LLVM to guarantee program integrity Simon Cook

Background • Compiling for security is becoming increasingly important • Finding bugs through AddressSanitizer, MemorySanitizer, etc. • Research programs such as LADA • Use of security-enhancing hardware can added to existing programs by extending their use in the compiler

Topics to Discuss • Hardware • C attributes • Clang/Sema, Clang/Codegen • LLVM Optimization Tweaks • Instruction Lowering/Selection • AsmPrinting • Creating post-link tools using MC

What are we trying to protect? • Instruction integrity • Detection of any modification to program code at runtime • Control flow integrity • Ensuring that calls/branches only go to known locations and that return values are correct • If either of these are invalid the hardware should trap as soon as possible

Encoding Instructions: Hardware Each instruction becomes dependent on the previous one Given an instruction 𝐽 " , and internal state 𝑇 $ , we can produce the encoded instruction 𝐹 " and output state 𝑇 " 𝑓𝑜𝑑𝑝𝑒𝑓 , → , 𝐽 " 𝑇 $ 𝐹 " 𝑇 " add r0, r1 0xbeef At run time, the hardware can use the same state, and using the encoded instruction, reproduce the original instruction 𝑒𝑓𝑑𝑝𝑒𝑓 , → , 𝐹 " 𝑇 $ 𝐽 " 𝑇 " 0xbeef add r0, r1

Encoding a Function int foo(int x, int y) { return (4*x) + (y&5); } 𝐽 " lsli $r10, $r2, 2 919a 4000 𝐽 . andi $r13, $r3, 5 5d87 4002 𝐽 / add $r2, $r13, $r10 aa82 0900 𝐽 0 jmp $r0 0050 𝑓 , → lsli 𝐽 " 𝑇 $ 𝐹 " 0001 0203 𝑓 , → andi 0405 0607 𝐽 . 𝑇 " 𝐹 . 𝑓 , → add 0809 0a0b 𝐽 / 𝑇 . 𝐹 / 𝑓 , → jmp 0c0d 𝐹 0 𝐽 0 𝑇 /

Encoding Branches int foo(int x, int y, bool z) { return z ? x : y; } ; BB#0: 𝐽 " movi $r10, 0 809e 4000 𝐽 . bne .LBB0_2, $r4, $r10 e2c6 0100 ; BB#1: mov $r2, $r3 9812 𝐽 / .LBB0_2: jmp $r0 0050 𝐽 0 𝑓 , → 𝐽 0 𝑇 / 𝐹 0 𝑓 , → 𝐽 0 𝑇 2 𝐹 0 For two cases, this may be solvable, but not for blocks with many direct predecessors

Encoding Branches int foo(int x, int y, bool z) { return z ? x : y; } ; BB#0: 𝐽 " movi $r10, 0 809e 4000 𝐽 . bne .LBB0_2, $r4, $r10 e2c6 0100 _correction_value_ .... 𝐷 ; BB#1: mov $r2, $r3 9812 𝐽 / .LBB0_2: jmp $r0 𝐽 0 0050 𝑓 , → 𝑓 , → 𝐹 0 𝐹 . 𝐽 0 𝑇 / 𝐽 . 𝑇 " 𝑓 , → 𝑓 , → 𝐹 0 𝐹 3 𝐽 0 𝐷 𝐷 𝑇 "

Function Calls int foo(int x) { return bar(x+2); } 𝐽 " subi $r1, $r1, 2 4a16 𝐽 . stw [$r1, 0], $r0 4038 𝐽 / addi $r2, $r2, 2 9214 𝐽 0 bal bar, $r0 00c2 0000 𝐽 4 ldw $r0, [$r1, 0] 0828 addi $r1, $r1, 2 𝐽 5 4a14 jmp $r0 𝐽 6 0050 • Calling bar pushes state to the encoding stack 𝑇 0 • Returning pops this value, so calls can be treated as part of same BB

Scaling up to an entire program baz.c bar.c foo.c

Clang: -mencode-instructions ? Pros Cons • Easy to enable, one flag • ABI break, flag required enables system for entire CU across entire project • Only affects C, assembly still needs patching • Potential concerns about code size In the end we decided not to go down this route

Clang: __attribute__((protected)) Pros Cons • Per function granularity • Only affects C, assembly still needs patching • Lower cost overhead for “non-secure” functions • Risk of user neglecting to add attribute to all declarations of • ABI change is limited to those a function functions it was requested for

Clang Function Attribute • Added as a TypeAttr • We want to add error checking as pointers to protected functions are not the same as to unprotected • Extend FunctionType to support having protected as a property • For calls, add protected as bit in ExtInfo • This is not the same as a different calling convention, as we use different CCs and want to turn this on independently • For CodeGen, we map this down to a LLVM function attribute “protected”

int (*__attribute__((protected)))() • Function pointers present a challenge • We need to know what 𝑇 $ the target function is expecting • If 𝑇 $ based on address of function, we have no problem… • … otherwise we need to calculate it • Could use same for each function? Defeats security benefits. • Calculate all possible call targets? Not necessarily possible. • User should know, let’s ask them! • Attribute becomes __attribute__((protected("somestring")))

Changes to Middle-End LLVM • None, really… • … except one small change to the inliner • Avoid inlining secure functions into non-secure • Merging non-secure into secure is generally safe

Instruction Selection • Update call target nodes with custom flag field let isCall = 1 in def JAL : Inst_rrr <0x2, 0x9, (outs), (ins i64imm:$ i64imm:$flags flags , GR64:$rD, GR64:$rB), "jal\t $rD, $rB”, [(AAPcall timm timm:$ :$flags flags , GR64:$rD, GR64:$rB)]>; • Flag field contains: • Bit indicating whether function expects security • 16-bit representation of group name

Encoding Control Flow I • Just before emission, SecurityAnalysisPass: • Prepares a function for annotation • Builds lists of branches/calls/jump tables • Adds placeholders for correction values • Generates report on code size impact ===--- CF encoding statistics for 'main' ---=== Bytes added: 10 Words added: 5 NOP gaps added: 3 Enable/Disable insns added: 1

.debug_secure Record Format • Start function: 1 Function Start Address Group • End function: 2 Function End Address • Direct Call: 6 Call Site Call Target • Jump Table: 11 Count Target 1 Target 2

Encoding Control Flow II • AsmPrinterHandler – Adds hooks to assembly printing • Used by us for adding labels/emitting encoding at end of module • beginInstruction • endInstruction • beginFunction • endFunction • endModule

Resolving Values 1. Reconstruct the control flow graph of all secure functions 2. Assign correction values/ 𝑇 $ to all functions/groups 3. Encode each basic block, noting state of each reloc 4. Validate all values are known 5. Fill in relocations 6. Writeback

End result simon@shadowfax$ llvm-objdump -d a.out a.out: file format ELF32-aap Disassembly of section .text: Section has correction values, printing real instructions foo: 8000000: [8f39] 91 9a 40 00 lsli $r10, $r2, 2 8000004: [81ca] 5d 87 40 02 andi $r13, $r3, 5 8000008: [053b] aa 82 09 00 add $r2, $r13, $r10 800000c: [93e4] 00 50 jmp $r0

Thank you