Security Enhanced LLVM

class: center, middle

# Security Enhanced LLVM

---

## Agenda

- Background

- Terminology and Context

- Language Safety

- Protected Module Architecture (PMA)

- Secure Compilation

- Security Enhanced LLVM (SLLVM)

- Software Module Isolation in SLLVM-IR

- Software Module Isolation in SLLVM-C

- SLLVM and Sancus
  
  - SLLVM and Intel SGX

- Software Module Isolation in SLLVM-Rust

---

## Terminology

- Trusted Computing Base (TCB)

- Security properties and security objectives

- Example: Software isolation

- Attacker model

---

## Software Module Isolation

- An __isolated module__ is a software entity with these properties:

- Public data
  
  - Public code

- Private data
   
  - Private code
  
  - Restricted number of entry points.

---

## Security Challenges

- 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 Issues

1. System software is written in unsafe languages

2. Isolation guarantees at coarse granularity
  
3. Large TCB

4. Abstraction gap between high-level and low-level representation

---

## Security Solutions

- Issue 1 : Undefined behavior
  
  - Solution : Language Safety

- Issue 2 : Coarse-grained isolation

- Solution : Protected Module Architectures (PMAs)

- Issue 3 : Large TCB

- Solution : Protected Module Architectures (PMAs)

- Issue 4 : Abstraction gap

- Solution : Secure compilation

---

## Language Safety

- Provides a solution for undefined behavior

- Examples of undefined behavior in C

- Accessing an array out of bounds

- Accessing deallocated memory
     
  - Treating a data pointer as a function pointer

- A trade-off between safety and control/performance ?

---

## Protected Module Architecture (PMA)

- Provides a solution for

- Coarse-grained isolation

- Large TCBs

- A PMA offers a mechanism that

- Provides access control for software modules and their associated data

- Ensures that code can only be started from predefined entry points

_The terms isolated module, protected module, PM and enclave 
are used interchangeably in this presentation_

---

## Safe languages and PMAs

- Safe languages and PMAs complement each other well

- PMAs limit the interactions of a malicious environment and a PM

- Language safety makes sure that the execution of PMs is always well-defined

---

## Secure Compilation

- Abstraction is an important technique to manage complexity of computer systems

- Secure compilation:

- Provides a solution for the abstraction gap between high-level and 
    low-level representation.

- Preserves the security properties of linguistic abstractions

- Allows to reason about security at a comfortable abstraction level

---

## Towards a Secure Compiler Platform

- Secure compiler implementations

- Low level security mechanism

- Language specific toolchain

- Mechanism specific compiler

###  _Is it possible to generically represent and manipulate security properties at the different levels of abstraction?_

---

## Security Enhanced LLVM (SLLVM)

### A Secure Compiler Platform

- Uniformity
  - Common representations
  - Common programming models
  - Common formal models
- Reusability
  - Common algorithms for analysis
  - Common algorithms for transformation
  - Common proofs
- Programmability
  - Focus on programmer comfort
  - Stay close to native programming models 
- TCB minimization of
  - Toolchain implementation
  - Generated code
- High quality design of
  - Programming models
  - Compiler implementation
- Configurability 
  - Do the security objectives of the application match the security guarantees
    of execution infrastructure?

---

## Security Enhanced LLVM (SLLVM)

### Proof of concept

- 1 security property
  - Software module isolation

- 2 system programming languages
  - Unsafe language *C*
  - Safe language *Rust*

- 2 hardware based PMAs
  - *SGX* targets high-end computing devices
  - *Sancus* targets low-power, low-cost embedded devices

---

## Special Purpose Secure Compilers

### N languages + M targets: N x M compilers

---

## Secure Compiler Platform

### N languages + M targets: N + M components

---

## SW Module Isolation in SLLVM-IR

### SLLVM-IR Programming Model

- An LLVM IR module enriched with SLLVM extensions

- 1 _llvm.module.flags_ flag

__sllvm-module__

- 1 LLVM _attribute_
  
  __sllvm-entry__

- 4 LLVM _intrinsics_

- __sllvm\_ecall__
  - __sllvm\_exit__
  - __sllvm\_ocall__
  - __sllvm\_return__

---

```llvm
 1  source_filename = "enclave1.c"
 2  declare i16 @enclave2_entry(i16) #0
 3  
 4  @enclave1_shared = global i16 0, align 2
 5  @secret = internal global i16 0, align 2
 6  
 7  define internal void @internal_func() {
 8  entry:
 9    %0 = load i16, i16* @secret, align 2
10  }
11  
12  define void @enclave1_entry1() #0 {
13  entry:
14    call void @internal_func()            
15    call i16 @enclave2_entry(i16 @secret)
16  }
17  
18  define void @enclave1_entry2(i16 %p) #0 {
19  entry:
20    call i16 @unprotected_f(i16 p)
21  }
22  
23  attributes #0 = {"sllvm-entry"="true"}
24  
25  !0 = !{i16 2, !"sllvm-module", !"enclave1"}
26  
27  !llvm.module.flags = !{!0}
```

---

## SW Module Isolation in SLLVM-C

### SLLVM-C Programming Model

- A C compilation unit corresponds to an isolated module

- Symbols with internal linkage belong to the protected part of the module

- __sllvm-entry__ attribute to mark PM entry points

- Annotation of entry points is required in header only

- Pragma to automate the annotation of entry points

*Other relevant information can be inferred from this model*

---

```c
#ifndef ENCLAVE1_H
#define ENCLAVE1_H

#pragma sllvm module

extern int enclave1_shared;

void enclave1_entry1(void);

void enclave1_entry2(int p);

#endif
```

---

```c
#include "enclave1.h"
#include "enclave2.h"
#include "unprotected.h"

int enclave1_shared;

static int secret;

static void internal_func(void)
{
  secret++;
}

void enclave1_entry1(void)
{
  internal_func();        /* Invocation of an internal function */
  enclave2_entry(secret); /* An out call to protected code */
}

void enclave1_entry2(int p)
{
  unprotected_f(p); /* An out call to unprotected code */
}
```

---

## SLLVM and Sancus

- Proposal for new secure Sancus compiler that
  - Leverages the LLVM framework
  - Prefers LLVM IR over MSP430 assembly for Sancus specifics
  - Generates more optimal code (size and speed)
  - Simplifies the compilation process
  - Simplifies the linking process

- Changes to IR programming model
  - SANCUS\_ENTRY (_cc97_) calling convention
  
- Improvements
  - C programming model
  - Design and implementation
  - Performance
  - Security

---

## SLLVM and Intel SGX

### Intel SGX SDK

- C and SGX specific

- Enclave Description Language (EDL)

- Edger8r tool generates C code based on EDL

### SLLVM's approach

- Language agnostic and generic

- SLLVM-C programming model

- SLLVM-IR programming model

- LLVM pass generates LLVM IR code based on SLLVM-IR model

---

## SW Module Isolation in SLLVM-Rust

- Safe languages and PMAs complement each other well

- Ad-hoc programming model, but it demonstrates
 
  - the genericity of the SLLVM approach

- the feasibility of running Rust on Sancus

- Rust provides safety without losing control and performance

---

## Conclusion

- Proposal for a unified secure compiler infrastructure

- Common secure model for SW module isolation in LLVM IR

- Common secure model for SW module isolation in C

- Proof of concept with support for
  - C 
  - Rust
  - Sancus 
  - Intel SGX

- Prototype for a new Sancus toolchain with improvements in
  - Design and implementation
  - Security
  - Performance 
  - Programmability

- Introduction of the Rust ecosystem to Sancus PMA

- Foundational work on an alternative to the Baidu Rust SDK for SGX