The Quest for Formally Secure Compartmentalizing Compilation · 2019-01-29 · –shared...
Transcript of The Quest for Formally Secure Compartmentalizing Compilation · 2019-01-29 · –shared...
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