Security Enhanced LLVM

--
class: center, middle

## Security Enhanced LLVM

</br>
__Hans Winderix__
</br>
_hans.winderix@cs.kuleuven.be_
</br>
imec-DistriNet, KU Leuven, Celestijnenlaan 200A, B-3001 Belgium
</br>
</br>
</br>
</br>
CLUSIB - BELCLIV, Sint-Lambrechts-Woluwe, May 2019</br>

---

## Short Bio

- Current
  - PhD student at imec-DistriNet

- Working on a compiler countermeasure against Nemesis (an interrupt based 
    side channel attack)

- Previous

- RainCode, Software Developer (7 years)

- Septentrio Satellite Navigation, Embedded Software Engineer (8 years)

- Main interests

- Compiler Technology

- Domain Specific Languages & Code Generation

- Software Security & Trusted Computing

- Defenses against side channel attacks

---

## My Master Thesis - The Key Idea

### Security Enhanced LLVM

</br>

<center>
A proposal for a unified infrastructure for secure compilation
</center>

---

## Security Challenges

</br>

- The number of computing devices keeps growing

- The amount of software installed on computing devices keeps growing

- Computing devices are increasingly connected

- Computing devices are becoming more and more extensible

---

## Security Incidents

---

## Why is it so hard to design secure computer systems?

</br>
</br>

1. System software has been written in unsafe languages

2. Isolation at a coarse level of granularity

3. Large Trusted Computing Base (TCB)

4. Closed architectures

5. Abstraction gap between high-level and low-level representation of computer 
   programs

---

## Why is it so hard to design secure computer systems?

</br>
</br>

1. System software has been written in unsafe languages

2. Isolation at a coarse level of granularity

3. Large Trusted Computing Base (TCB)

4. Closed architectures

5. __Abstraction gap between high-level and low-level representation of computer programs__

---

## Security Solutions

</br>

- _Issue 1 : Undefined behavior_

- Solution : Language Safety

- _Issue 2 : Coarse-grained isolation_

- Solution : Trusted Execution Environments (TEE)

- _Issue 3 : Large TCB_

- Solution : Trusted Execution Architectures (TEE)

- _Issue 4 : Closed architectures_

- Solution : Open architectures

- _Issue 5 : Abstraction gap_

- Solution : Secure compilation

---

## Security Solutions

</br>

- _Issue 1 : Undefined behavior_

- Solution : Language Safety

- _Issue 2 : Coarse-grained isolation_

- Solution : Trusted Execution Environments (TEE)

- _Issue 3 : Large TCB_

- Solution : Trusted Execution Environments (TEE)

- _Issue 4 : Closed architectures_

- Solution : Open architectures

- __Issue 5 : Abstraction gap__

- __Solution : Secure compilation__

---

## Abstraction and Computer Systems

---

## Why do we need abstractions?

<center>ENIAC (1947)</center>

---

## The Modern Equivalent of ENIAC's Input

```
...
457f464c0102000100000000000000000001003e000100000000000000000000
000000000000000002d8000000000000000000000040000000000040000c000b
4855e589834810ec7d8989fcf875058b00000000453975fc8b0ff84540be0f42
8900e8c700000000c99000c3bc3ecdd247004343203a55287562746e20752e37
2e342d3075317562746e3175317e2e38343020292e372e340030000000000000
00140000000000007a010052780101100c1b080701900000001c0000001c0000
00000000002b00004100100e02860d436606070c000800000000000000000000
00000000000000000000000000000000000100000004fff10000000000000000
0000000000000000000000000003000100000000000000000000000000000000
00000000000000000000000000000000000d0000001200010000000000000000
002b000000000000001800000010000000000000000000000000000000000000
002e0000001000000000000000000000000000000000000075002e7500634553
5243544562007975745f6369656b0074475f4f4c41425f4c464f53465445545f
4241454c005f72746e6166737265000000100000000000000002000000030000
fffcffffffffffff002400000000000000040000000b0000fffcffffffffffff
0020000000000000000200000002000000000000000000002e007973746d6261
2e007473747262612e0068737473747262612e006572616c742e78650074642e
74610061622e73732e006f636d6d6e6500746e2e746f2e654e472d5574736361
006b722e6c652e616865665f6172656d00000000000000000000000000000000
0000000000000000001b00000004000000400000000000000000000000000000
0230000000000000003000000000000000090000000100000008000000000000
0018000000000000002600000001000000030000000000000000000000000000
006c000000000000000400000000000000000000000000000004000000000000
...
```

---

## Raising the Level of Abstraction

</br>

- Create concepts (abstractions) for humans to better understand computer 
  programs

- Common abstractions found in "high level" programming languages

- Variable

- Type

- Module

- Procedure

- Structured control-flow

- Access control

- ...

---

## High Level Programming Languages

### A simple example in the Rust language

</br>

```rust
pub mod casino
{
  SECRET: i64 = 424359935038;

pub fn guess_secret(guess: i64, account: bankAccount)
  {
    if (guess == SECRET)
    {
      transfer_money(bankAccount, 1_000_000);
    }
  }
}
```

---

## Going From High Level to Low Level

### Compilation

</br>

- The automated translation of

- a program expressed in a human-centric programming language

- into a semantically equivalent program expressed in a machine-specific 
    language

</br>

- The focus of a compiler

- Functional correctness

- Enforce abstractions at high level

- Performance

---

## Compilation

```rust
pub mod casino {
  SECRET: i64 = 424359935038;

pub fn guess_secret(guess: i64, account: bankAccount) {
    if (guess == SECRET) {
      transfer_money(bankAccount, 1_000_000);
    }
  }
}
```

```
...
5243544562007975745f6369656b0074475f4f4c41425f4c464f53465445545f
4241454c005f72746e6166737265000000100000000000000002000000030000
fffcffffffffffff002400000000000000040000000b0000fffcffffffffffff
2e007473747262612e0068737473747262612e006572616c742e78650074642e
74610061622e73732e006f636d6d6e6500746e2e746f2e654e472d5574736361
006b722e6c652e616865665f6172656d00000000000000000000000000000000
0018000000000000002600000001000000030000000000000000000000000000
006c000000000000000400000000000000000000000000000004000000000000
...
```

---

## Abstractions, Compilation and Security

</br>

- Software developers often have (implicit) assumptions about the security
  properties of programming language abstractions

- A compiler "lowers abstractions"

- After lowering to the machine level, the assumptions do not hold anymore

- Abstraction gap between the high-level and the low-level representation of

computer programs

- Reasoning about the security of an application requires

knowledge about the intricate details of the execution environment

---

## Example

- The security properties we want to maintain
  - SECRET should remain secret
  - only when the secret is guessed, money should be transferred

```rust
pub mod casino {
  SECRET: i64 = 424359935038;

pub fn guess_secret(guess: i64, account: bankAccount) {
    if (guess == SECRET) {
      transfer_money(bankAccount, 1_000_000);
    }
  }
}
```

```
...
5243544562007975745f6369656b0074475f4f4c41425f4c464f53465445545f
4241454c005f72746e6166737265000000100000000000000002000000030000
fffcffffffffffff002400000000000000040000000b0000fffcffffffffffff
74610061622e73732e006f636d6d6e6500746e2e746f2e654e472d5574736361
006c000000000000000400000000000000000000000000000004000000000000
...

```

---

## Secure Compilation

</br>
</br>

- Provides a solution for this abstraction gap between high-level and

low-level representation.

- Preserves abstractions and their associated security properties

after compilation

- Allows to reason about security at a comfortable abstraction level

- Needs efficient mechanisms to enforce the abstractions

---

### (Very High Level) Design of Conventional Compilers

- Front end

- _Language specific_

- Back end

- _Machine specific_

- Middle end

- _Language and machine independent_

---

## Current Design of Secure Compilers

###  _Why is there so little effort to share infrastructure?_

</br>

- Secure compiler implementations are typically realized with 
  
  - a low-level security mechanism

- and a special purpose compiler that supports

- a single programming language.

</br>

- Secure compiler implementations have an ad hoc design

- Mechanism specific concepts in programming language
  
  - Language specific toolchain
  
  - Mechanism specific compiler

---

## Current Design of Secure Compilers

- Ad hoc programming models

- Ad hoc algorithms

- N languages and M targets result in N x M compilers

</br>
</br>

---

## A Secure Compiler Infrastructure

- Common programming models

- Common algorithms

- N languages and M targets result in N + M components

</br>
</br>

-->

- And this is an illustration of how it should be done

- Where a secure compiler infrastructure mimics the design of conventional

- compilers to reduce the implementation effort by sharing generic programming

- models and generic algorithms.

- This leads to an improved quality and an improved security

- Researchers strive to minimize the amount of code that we have to trust

- although the quality of the code we trust is just as important for

- establishing this trust.

- It's common knowledge that sharing implementations with peers can advance

- development and testing more effectively than most proprietary methods.

---

## Security Enhanced LLVM

</br>

- Security Enhanced LLVM extends the __LLVM__ Compiler Infrastructure

- Developed by University of Illinois at Urbana-Champaign
  
  - Provides reusable components for building compilers
  
  - Reduce the time/cost to build a new compiler
  
  - The language and target independent intermediate representation (IR) is at 
    the heart of LLVM

---

## Security Enhanced LLVM

### Towards a Secure Compiler Infrastructure

</br>
- Common security-oriented abstractions and programming models

- Common algorithms for security-related program analyses

- Common algorithms for security-related program transformations

- Important requirements

- Uniformity

- Reusability

- Programmability

- Quality
 
---

## Contributions

</br>

- A proposal for a unified secure compiler infrastructure

- A proof of concept to securely compile _software module isolation_

- A prototype for an improved Sancus toolchain

- Generic programming model for software module isolation in LLVM IR

- Generic programming model for software module isolation in C

- Introduction of the Rust ecosystem to Sancus

- Foundational work for a native Rust SGX SDK