The Quest for Formally Secure Compartmentalizing Compilation

Cătălin Hrițcu

1

Habilitation Defense

My research in the last 7 years

Program Verification

3

Property-Based TestingTag-based Monitoring

Secure Compilation

My research in the last 7 years

Program Verification

3

Property-Based TestingTag-based Monitoring

Secure Compilation

Devastating low-level attacks

4

Devastating low-level attacks

inherently insecure languages like C/C++

– e.g. memory unsafe: any buffer overflow is catastrophicallowing remote attackers to gain complete control

4

Devastating low-level attacks

inherently insecure languages like C/C++

– e.g. memory unsafe: any buffer overflow is catastrophicallowing remote attackers to gain complete control

– ~100 different undefined behaviors in usual C compiler

4

Devastating low-level attacks

inherently insecure languages like C/C++

– e.g. memory unsafe: any buffer overflow is catastrophicallowing remote attackers to gain complete control

– ~100 different undefined behaviors in usual C compiler

insecure interoperability with lower-level code

– even code in more secure languages (Java, OCaml, Rust)has to interoperate with low-level code (C, C++, ASM)

– insecure interoperability: all source-level guarantees lost

4

Devastating low-level attacks

inherently insecure languages like C/C++

– e.g. memory unsafe: any buffer overflow is catastrophicallowing remote attackers to gain complete control

– ~100 different undefined behaviors in usual C compiler

insecure interoperability with lower-level code

– even code in more secure languages (Java, OCaml, Rust)has to interoperate with low-level code (C, C++, ASM)

– insecure interoperability: all source-level guarantees lost

4Part 1: formalize what it means to solve this problem

Devastating low-level attacks

inherently insecure languages like C/C++

– e.g. memory unsafe: any buffer overflow is catastrophicallowing remote attackers to gain complete control

– ~100 different undefined behaviors in usual C compiler

insecure interoperability with lower-level code

– even code in more secure languages (Java, OCaml, Rust)has to interoperate with low-level code (C, C++, ASM)

– insecure interoperability: all source-level guarantees lost

4Part 1: formalize what it means to solve this problem

Part 2: give meaning to compartmentalization mitigation

Secure Interoperabilitywith Lower-Level Code

Part 1 of 2

5

Secure Interoperabilitywith Lower-Level Code

Part 1 of 2

5

CarmineAbate

DeepakGarg Marco

Patrignani

CătălinHrițcu

JérémyThibault

MPI-SWS

Stanford& CISPA

Inria ParisInria Paris Inria Paris

RobBlanco

Journey Beyond Full Abstractionhttps://arxiv.org/abs/1807.04603

Inria Paris

Good programming languages providehelpful abstractions for writing more secure code

6

Good programming languages providehelpful abstractions for writing more secure code

• e.g. HACL* and miTLS written in Low* which provides:

6

Good programming languages providehelpful abstractions for writing more secure code

• e.g. HACL* and miTLS written in Low* which provides:

– low-level abstractions of safe C programs• structured control flow, procedures, abstract memory model

6

Good programming languages providehelpful abstractions for writing more secure code

• e.g. HACL* and miTLS written in Low* which provides:

– low-level abstractions of safe C programs• structured control flow, procedures, abstract memory model

– higher-level abstractions of ML-like languages• modules, interfaces, and parametric polymorphism

6

Good programming languages providehelpful abstractions for writing more secure code

• e.g. HACL* and miTLS written in Low* which provides:

– low-level abstractions of safe C programs• structured control flow, procedures, abstract memory model

– higher-level abstractions of ML-like languages• modules, interfaces, and parametric polymorphism

– specifications of a verification system like Coq and Dafny• effects, dependent types, refinements, logical pre- and post-conditions

6

Good programming languages providehelpful abstractions for writing more secure code

• e.g. HACL* and miTLS written in Low* which provides:

– low-level abstractions of safe C programs• structured control flow, procedures, abstract memory model

– higher-level abstractions of ML-like languages• modules, interfaces, and parametric polymorphism

– specifications of a verification system like Coq and Dafny• effects, dependent types, refinements, logical pre- and post-conditions

– coding patterns specific to cryptographic code• abstract types and interfaces for defending against side-channel attacks

6

7

But abstractions not enforced when compiling and linking with adversarial low-level code

8

HACL* library

~20.000 LOC in Low*

But abstractions not enforced when compiling and linking with adversarial low-level code

8

HACL* library Firefox web browser

~20.000 LOC in Low* 16.000.000+ LOC in C/C++

But abstractions not enforced when compiling and linking with adversarial low-level code

8

HACL* library Firefox web browser

ASM ASM

~20.000 LOC in Low* 16.000.000+ LOC in C/C++

KreMLin+ CompCert GCC

Verified

But abstractions not enforced when compiling and linking with adversarial low-level code

8

HACL* library Firefox web browser

ASM ASM

Insecure interoperability: linked code can read and writedata and code, jump to arbitrary instructions, smash the stack, ...

~20.000 LOC in Low* 16.000.000+ LOC in C/C++

KreMLin+ CompCert GCC

Verified

Secure compilation chains

• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...

– shared responsibility: compiler, linker, loader, OS, HW

9

Secure compilation chains

• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...

– shared responsibility: compiler, linker, loader, OS, HW

• Goal: enable source-level security reasoning

9

Secure compilation chains

• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...

– shared responsibility: compiler, linker, loader, OS, HW

• Goal: enable source-level security reasoning– adversarial target-level context cannot break the security of

compiled program any more than some source-level context

9

Secure compilation chains

• Protect source-level abstractionseven against linked adversarial low-level code– various enforcement mechanisms: processes, SFI, ...

– shared responsibility: compiler, linker, loader, OS, HW

• Goal: enable source-level security reasoning– adversarial target-level context cannot break the security of

compiled program any more than some source-level context

– no "low-level" attacks

9

Robustly preserving security

10

Robustly preserving security

sourcecontext

source secureprogram

10

sourcecontext∀

Robustly preserving security

sourcecontext

target context

source

compiled

compiler

secure

secure

program

program

10

sourcecontext∀

targetcontext∀

⇒

Robustly preserving security

sourcecontext

target context

source

compiled

compiler

secure

secure

program

program

no extra powerprotected

10

sourcecontext∀

targetcontext∀

⇒

Robustly preserving security

sourcecontext

target context

source

compiled

compiler

secure

secure

program

program

no extra powerprotected

10

But what should "secure" mean?

sourcecontext∀

targetcontext∀

⇒

11

What properties should we robustly preserve?

11

What properties should we robustly preserve?

trace properties(safety & liveness)

11

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

11

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

11

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

11

More secure

More efficientto enforce

Easier to prove

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

No one-size-fits-all security criterion

11

More secure

More efficientto enforce

Easier to prove

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

only integrity

No one-size-fits-all security criterion

11

More secure

More efficientto enforce

Easier to prove

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

only integrity

+ data confidentiality

No one-size-fits-all security criterion

11

More secure

More efficientto enforce

Easier to prove

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

only integrity

+ data confidentiality

+ code confidentiality

No one-size-fits-all security criterion

11

More secure

More efficientto enforce

Easier to prove

What properties should we robustly preserve?

trace properties(safety & liveness)

hyperproperties(noninterference)

relationalhyperproperties(trace equivalence)

only integrity

+ data confidentiality

+ code confidentiality

No one-size-fits-all security criterion

Robust Trace Property Preservation

43

sourcecontext

targetcontext

source program

compiledprogram

sourcecontext∃

target context∃

.

.

compiler

∀source programs.∀(bad/attack) trace t.

⇒

sourcecontext

targetcontext

source program

compiledprogram

sourcecontexttrace t∀

target contexttrace t

∀

.

.

compiler

∀source programs.∀π trace property.

⇒

⇝t⇒ t∈π

property-based characterization

⇝t⇒ t∈π

property-free characterization

⇔

⇝t

⇝t

back-translation

what one can achieve how one can prove it

13

back-translatingprog & context & trace∀P∀CT∀t∃CS...

Some of the proof difficulty is manifest inproperty-free characterization

13

back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...

back-translatingprog & context & trace∀P∀CT∀t∃CS...

Some of the proof difficulty is manifest inproperty-free characterization

13

back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...

back-translatingfinite set offinite trace prefixes∀k∀P1..Pk∀CT

∀m1..mk ∃CS...

back-translatingprog & context & trace∀P∀CT∀t∃CS...

Some of the proof difficulty is manifest inproperty-free characterization

13

back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...

back-translatingprog & context∀P∀CT∃CS∀t...

back-translatingcontext

∀CT∃CS∀P∀t...

back-translatingfinite set offinite trace prefixes∀k∀P1..Pk∀CT

∀m1..mk ∃CS...

back-translatingprog & context & trace∀P∀CT∀t∃CS...

Some of the proof difficulty is manifest inproperty-free characterization

Journey Beyond Full Abstraction

• First to explore space of secure compilation criteriabased on robust property preservation

14

Journey Beyond Full Abstraction

• First to explore space of secure compilation criteriabased on robust property preservation

• Carefully study the criteria and their relations

– Property-free characterizations

– implications, collapses, separations results

14

Journey Beyond Full Abstraction

• First to explore space of secure compilation criteriabased on robust property preservation

• Carefully study the criteria and their relations

– Property-free characterizations

– implications, collapses, separations results

• Introduce relational (hyper)properties (new classes!)

14

Journey Beyond Full Abstraction

• First to explore space of secure compilation criteriabased on robust property preservation

• Carefully study the criteria and their relations

– Property-free characterizations

– implications, collapses, separations results

• Introduce relational (hyper)properties (new classes!)

• Formally study relation to full abstraction ...

14

Journey Beyond Full Abstraction

• First to explore space of secure compilation criteriabased on robust property preservation

• Carefully study the criteria and their relations

– Property-free characterizations

– implications, collapses, separations results

• Introduce relational (hyper)properties (new classes!)

• Formally study relation to full abstraction ...

• Embraced and extended proof techniques ...

14

Where is Full Abstraction?

15

(i.e. robust behavioral equivalence preservation)

without internal nondeterminism,full abstraction is here

Where is Full Abstraction?

15

(i.e. robust behavioral equivalence preservation)

without internal nondeterminism,full abstraction is here

Where is Full Abstraction?

15

doesn't imply any of our criteria(even assuming compiler correctness)

(i.e. robust behavioral equivalence preservation)

without internal nondeterminism,full abstraction is here

Where is Full Abstraction?

15

doesn't imply any of our criteria(even assuming compiler correctness)

no one-size-fits-all criterion!

(i.e. robust behavioral equivalence preservation)

Embraced and extended™ proof techniques

16

for simple translation from statically to dynamically typed language with first-order functions and I/O

Embraced and extended™ proof techniques

16

back-translatingcontext

∀CT∃CS∀P∀t...

for simple translation from statically to dynamically typed language with first-order functions and I/O

strongestcriterion

achievable

Embraced and extended™ proof techniques

16

back-translatingcontext

∀CT∃CS∀P∀t... generic techniqueapplicableback-translatingfinite set offinite trace prefixes∀k∀P1..Pk∀CT

∀m1..mk ∃CS...

for simple translation from statically to dynamically typed language with first-order functions and I/O

strongestcriterion

achievable

Some open problems

• Practically achievingsecure interoperability with lower-level code

– More realistic languages and compilation chains

17

Some open problems

• Practically achievingsecure interoperability with lower-level code

– More realistic languages and compilation chains

• Verifying robust satisfaction for source programs

– partial semantics, program logics, logical relations, ...

17

Some open problems

• Practically achievingsecure interoperability with lower-level code

– More realistic languages and compilation chains

• Verifying robust satisfaction for source programs

– partial semantics, program logics, logical relations, ...

• Exploring other kinds of secure compilation

– target observations richer than source observations

– generalize noninterference preservation with side-channels?

17

Secure Compilation for Unsafe Languages

When Good Components Go Bad (CCS 2018)Beyond Good and Evil (CSF 2016)Micro-Policies (IEEE S&P 2015)A verified information-flow architecture (POPL 2014)

Part 2 of 2

18

When Good Components Go BadComputer and Communications Security (CCS 2018)

CătălinHrițcu

MarcoStronati

ArthurAzevedo

de Amorim

Ana NoraEvans

AndrewTolmach

BenjaminPierce

ThéoLaurent

CarmineAbate

Inria Paris CMU U. Virginia Portland State UPenn

GuglielmoFachini

19

RobBlanco

Inherently insecure languages like C

– any buffer overflow can be catastrophic

20

Inherently insecure languages like C

– any buffer overflow can be catastrophic

– ~100 different undefined behaviorsin the usual C compiler:• use after frees and double frees, invalid casts,

signed integer overflows, ...............................

20

Inherently insecure languages like C

– any buffer overflow can be catastrophic

– ~100 different undefined behaviorsin the usual C compiler:• use after frees and double frees, invalid casts,

signed integer overflows, ...............................

– root cause, but very challenging to fix:

• efficiency, precision, scalability,

backwards compatibility, deployment

20

Compartmentalization mitigation

• Break up security-critical applications into mutually distrustful components with clearly specified privileges

21

Compartmentalization mitigation

• Break up security-critical applications into mutually distrustful components with clearly specified privileges

• Protect source abstractions all the way down

– separation, static privileges, call-return discipline, types, ...

21

Compartmentalization mitigation

• Break up security-critical applications into mutually distrustful components with clearly specified privileges

• Protect source abstractions all the way down

– separation, static privileges, call-return discipline, types, ...

• Compartmentalizing compilation chain:

– compiler, linker, loader, runtime, system, hardware

21

Compartmentalization mitigation

• Break up security-critical applications into mutually distrustful components with clearly specified privileges

• Protect source abstractions all the way down

– separation, static privileges, call-return discipline, types, ...

• Compartmentalizing compilation chain:

– compiler, linker, loader, runtime, system, hardware

• Base this on efficient enforcement mechanisms:

– OS processes (all web browsers) — hardware enclaves (SGX)

– WebAssembly (web browsers) — capability machines

– software fault isolation (SFI) — tagged architectures

21

Strong security!?

22

Strong security!?

• Security guarantees one can make fully water-tight

– beyond just "increasing attacker effort"

22

Strong security!?

• Security guarantees one can make fully water-tight

– beyond just "increasing attacker effort"

• Intuitively, if we use compartmentalization ...

... a vulnerability in one component does not immediately

destroy the security of the whole application

22

Strong security!?

• Security guarantees one can make fully water-tight

– beyond just "increasing attacker effort"

• Intuitively, if we use compartmentalization ...

... a vulnerability in one component does not immediately

destroy the security of the whole application

... since each component is protected from all the others

22

Strong security!?

• Security guarantees one can make fully water-tight

– beyond just "increasing attacker effort"

• Intuitively, if we use compartmentalization ...

... a vulnerability in one component does not immediately

destroy the security of the whole application

... since each component is protected from all the others

... and each component receives protection as long as

it has not been compromised (e.g. by a buffer overflow)

22

Can we formalize this intuition?

23

Can we formalize this intuition?

23

What is a compartmentalizing compilation chain supposed to enforce precisely?

Can we formalize this intuition?

23

We answer this question:

Formal definition expressing theend-to-end security guaranteesof compartmentalization

What is a compartmentalizing compilation chain supposed to enforce precisely?

Challenge formalizing security of mitigations

• We want source-level security reasoning principles

– easier to reason about security in the source languageif and application is compartmentalized

24

Challenge formalizing security of mitigations

• We want source-level security reasoning principles

– easier to reason about security in the source languageif and application is compartmentalized

• ... even in the presence of undefined behavior

– can't be expressed at all by source language semantics!

24

Challenge formalizing security of mitigations

• We want source-level security reasoning principles

– easier to reason about security in the source languageif and application is compartmentalized

• ... even in the presence of undefined behavior

– can't be expressed at all by source language semantics!

– what does the following program do?

24

#include <string.h>

int main (int argc, char **argv) {

char c[12];

strcpy(c, argv[1]);

return 0;

}

Challenge formalizing security of mitigations

• We want source-level security reasoning principles

– easier to reason about security in the source languageif and application is compartmentalized

• ... even in the presence of undefined behavior

– can't be expressed at all by source language semantics!

– what does the following program do?

24

#include <string.h>

int main (int argc, char **argv) {

char c[12];

strcpy(c, argv[1]);

return 0;

}

Compartmentalizing compilation should ...

• Restrict spatial scope of undefined behavior

– mutually-distrustful components• each component protected from all the others

25

Compartmentalizing compilation should ...

• Restrict spatial scope of undefined behavior

– mutually-distrustful components• each component protected from all the others

• Restrict temporal scope of undefined behavior

– dynamic compromise• each component gets guarantees

as long as it has not encountered undefined behavior

• i.e. the mere existence of vulnerabilities doesn'tnecessarily make a component compromised

25

i0 i1 i2

C0 C1 C2↓ ↓ ↓ ⇝ tIf then

26

Securitydefinition:

i0 i1 i2

C0 C1 C2

∃ a sequence of component compromises explaining the finite trace tin the source language, for instance t=m1·m2·m3 and

↓ ↓ ↓ ⇝ t

i0 i1 i2

C0 C1 C2⇝* m1·Undef(C1)

↯(1)

If then

26

Securitydefinition:

i0 i1 i2

C0 C1 C2

∃ a sequence of component compromises explaining the finite trace tin the source language, for instance t=m1·m2·m3 and

↓ ↓ ↓ ⇝ t

i0 i1 i2

C0 C1 C2⇝* m1·Undef(C1)

↯(1)

(2)i0 i1 i2

C0 A1 C2⇝* m1·m2·Undef(C2)

↯∃A1.

If then

26

Securitydefinition:

i0 i1 i2

C0 C1 C2

∃ a sequence of component compromises explaining the finite trace tin the source language, for instance t=m1·m2·m3 and

↓ ↓ ↓ ⇝ t

i0 i1 i2

C0 C1 C2⇝* m1·Undef(C1)

↯(1)

(2)i0 i1 i2

C0 A1 C2⇝* m1·m2·Undef(C2)

↯

(3)i0 i1 i2

C0 A1 A2⇝ m1·m2·m3

∃A1.

∃A2.

If then

26

Securitydefinition:

i0 i1 i2

C0 C1 C2

∃ a sequence of component compromises explaining the finite trace tin the source language, for instance t=m1·m2·m3 and

↓ ↓ ↓ ⇝ t

i0 i1 i2

C0 C1 C2⇝* m1·Undef(C1)

↯(1)

(2)i0 i1 i2

C0 A1 C2⇝* m1·m2·Undef(C2)

↯

(3)i0 i1 i2

C0 A1 A2⇝ m1·m2·m3

Finite trace records which component encounteredundefined behavior and allows us to rewind execution

∃A1.

∃A2.

If then

26

Securitydefinition:

How can we prove this?

27

How can we prove this?

27

When compilation and back-translation are compositional, previous definition reduces to (a variant of)Robust Safety Preservation

How can we prove this?

27

back-translatingfinite trace prefix∀P∀CT∀m≤t∃CS...

When compilation and back-translation are compositional, previous definition reduces to (a variant of)Robust Safety Preservation

Proof-of-concept formallysecure compilation chain in Coq

Illustrates our formal definition

28

Compartmentalized unsafe source

Compartmentalized abstract machine

Micro-policy machine

Bare-bonemachine

software fault isolation

29

Compartmentalized unsafe source

Compartmentalized abstract machine

Buffers, procedures, componentsinteracting via strictly enforced interfaces

Micro-policy machine

Bare-bonemachine

software fault isolation

29

Compartmentalized unsafe source

Compartmentalized abstract machine

Buffers, procedures, componentsinteracting via strictly enforced interfaces

Micro-policy machine

Bare-bonemachine

Simple RISC abstract machine with

build-in compartmentalization

software fault isolation

29

Compartmentalized unsafe source

Compartmentalized abstract machine

Buffers, procedures, componentsinteracting via strictly enforced interfaces

Micro-policy machine

Bare-bonemachine

Simple RISC abstract machine with

build-in compartmentalization

software fault isolation

Tag-based reference monitor enforcing:- component separation- procedure call and return discipline(linear capabilities / linear entry points)

29

Compartmentalized unsafe source

Compartmentalized abstract machine

Buffers, procedures, componentsinteracting via strictly enforced interfaces

Micro-policy machine

Bare-bonemachine

Simple RISC abstract machine with

build-in compartmentalization

Inline reference monitor enforcing:- component separation- procedure call and return discipline(program rewriting, shadow call stack)

software fault isolation

Tag-based reference monitor enforcing:- component separation- procedure call and return discipline(linear capabilities / linear entry points)

29

Compartmentalized unsafe source

Compartmentalized abstract machine

Buffers, procedures, componentsinteracting via strictly enforced interfaces

Micro-policy machine

Bare-bonemachine

Simple RISC abstract machine with

build-in compartmentalization

Inline reference monitor enforcing:- component separation- procedure call and return discipline(program rewriting, shadow call stack)

software fault isolation

Tag-based reference monitor enforcing:- component separation- procedure call and return discipline(linear capabilities / linear entry points)

Verified

29

generic proof technique 26K lines of Coq, mostly proofs

Compartmentalized unsafe source

Compartmentalized abstract machine

Buffers, procedures, componentsinteracting via strictly enforced interfaces

Micro-policy machine

Bare-bonemachine

Simple RISC abstract machine with

build-in compartmentalization

Inline reference monitor enforcing:- component separation- procedure call and return discipline(program rewriting, shadow call stack)

software fault isolation

Tag-based reference monitor enforcing:- component separation- procedure call and return discipline(linear capabilities / linear entry points)

Verified

Systematically tested (with QuickChick)29

generic proof technique 26K lines of Coq, mostly proofs

When Good Components Go Bad

• Formalized security of compartmentalization

– first definition supporting dynamic compromise

– restricting undefined behavior spatially and temporally

30

When Good Components Go Bad

• Formalized security of compartmentalization

– first definition supporting dynamic compromise

– restricting undefined behavior spatially and temporally

• Proof-of-concept secure compilation chain in Coq

– software fault isolation or tag-based reference monitor

30

When Good Components Go Bad

• Formalized security of compartmentalization

– first definition supporting dynamic compromise

– restricting undefined behavior spatially and temporally

• Proof-of-concept secure compilation chain in Coq

– software fault isolation or tag-based reference monitor

• Generic definition and proof technique

– we expect them to extend and scale well

30

Making this more practical ... next steps:

31

Making this more practical ... next steps:

• Scale formally secure compilation chain to C language– allow shared memory (ongoing) and pointer passing (capabilities)

– eventually support enough of C to measure and lower overhead

– check whether hardware support (tagged architecture) is faster

31

Making this more practical ... next steps:

• Scale formally secure compilation chain to C language– allow shared memory (ongoing) and pointer passing (capabilities)

– eventually support enough of C to measure and lower overhead

– check whether hardware support (tagged architecture) is faster

• Extend all this to dynamic component creation– rewind to when compromised component was created

31

Making this more practical ... next steps:

• Scale formally secure compilation chain to C language– allow shared memory (ongoing) and pointer passing (capabilities)

– eventually support enough of C to measure and lower overhead

– check whether hardware support (tagged architecture) is faster

• Extend all this to dynamic component creation– rewind to when compromised component was created

• ... and dynamic privileges:– capabilities, dynamic interfaces, history-based access control, ...

31

Making this more practical ... next steps:

• Scale formally secure compilation chain to C language– allow shared memory (ongoing) and pointer passing (capabilities)

– eventually support enough of C to measure and lower overhead

– check whether hardware support (tagged architecture) is faster

• Extend all this to dynamic component creation– rewind to when compromised component was created

• ... and dynamic privileges:– capabilities, dynamic interfaces, history-based access control, ...

• From robust safety to hypersafety (e.g. confidentiality)

31

Making this more practical ... next steps:

• Scale formally secure compilation chain to C language– allow shared memory (ongoing) and pointer passing (capabilities)

– eventually support enough of C to measure and lower overhead

– check whether hardware support (tagged architecture) is faster

• Extend all this to dynamic component creation– rewind to when compromised component was created

• ... and dynamic privileges:– capabilities, dynamic interfaces, history-based access control, ...

• From robust safety to hypersafety (e.g. confidentiality)

• Secure compilation of Low* using components, contracts, sealing, ...

31

My dream: secure compilation at scale

32

miTLSLow* language

(safe C subset in F*)

C language+ components+ memory safety

My dream: secure compilation at scale

32

miTLSLow* language

(safe C subset in F*)

C language+ components+ memory safety

My dream: secure compilation at scale

32

miTLS

memory safe C component

Low* language(safe C subset in F*)

C language+ components+ memory safety

My dream: secure compilation at scale

32

miTLS

memory safe C component

Low* language(safe C subset in F*)

C language+ components+ memory safety

My dream: secure compilation at scale

32

miTLS

memory safe C component

Low* language(safe C subset in F*)

C language+ components+ memory safety

ASM language(RISC-V + micro-policies)

My dream: secure compilation at scale

32

miTLS

memory safe C component

legacy C component

ASM component

Low* language(safe C subset in F*)

C language+ components+ memory safety

ASM language(RISC-V + micro-policies)

My dream: secure compilation at scale

32

miTLS

memory safe C component

legacy C component

ASM component

Low* language(safe C subset in F*)

C language+ components+ memory safety

ASM language(RISC-V + micro-policies)

My dream: secure compilation at scale

32

miTLS

memory safe C component

legacy C component

ASM component

Low* language(safe C subset in F*)

C language+ components+ memory safety

ASM language(RISC-V + micro-policies)

My dream: secure compilation at scale

32

miTLS

memory safe C component

legacy C component

ASM component

Low* language(safe C subset in F*)

C language+ components+ memory safety

ASM language(RISC-V + micro-policies)

PostDocs &Researchers

Past group members:Alejandro AguirreAna Nora EvansAnna BednarikArthur Azevedo de AmorimClément Pit-ClaudelDanel AhmanDiane Gallois-WongGuglielmo FachiniLi-yao XiaMarco StronatiNick GiannarakisSimon ForestTomer LibalVictor DumitrescuYannis JuglaretZoe Paraskevopoulou

Thank you Current group:Carmine AbateExe RivasFlorian GroultGuido MartínezJérémy ThibaultKenji MaillardRob BlancoThéo Laurent

Prosecco team:Benjamin BeurdoucheBenjamin LippBruno BlanchetDenis MerigouxElizabeth LabradaÉric TanterGraham SteelHarry HalpinKarthik BhargavanMarina PolubelovaMathieu MoureyPrasad Naldurg

Jury:David PointchevalFrank PiessensGilles BartheThomas JensenDavid PichardieKarthik BhargavanTamara RezkXavier Leroy

Family:Beate BrockmannGabriela MerticariuIoan HrițcuStela Hrițcu