Typed Memory Management in a Calculus of Capabilities

1. Typed Memory Managementin aCalculus of Capabilities David Walker (with Karl Crary and Greg Morrisett)

2. The TAL Project Compile Verify Link Code Types System Interface Code Types Code GC Code Types David Walker, Cornell University

3. TAL Goals • Security • reduce the trusted computing base • Software Engineering • eliminate dynamic failure modes; use static checking • Flexibility • give programmers control over low-level details • admit varying compilation strategies David Walker, Cornell University

4. TAL Memory Management • Garbage Collection: behind-the-scenes cleanup • Problems: • Complex code in the trusted computing base • Under-specified invariants link client and collector (type tags, pointer restrictions, etc) • No control over memory management decisions • Java, PCC, SPIN, ECC also use GC David Walker, Cornell University

5. Regions (Tofte and Talpin) • Explicit but provably safe deallocation • Static error checking • Simple, constant-time routines • Regions are allocated on a stack • Objects are allocated into regions • Topmost regions are deallocated David Walker, Cornell University

6. Towards Region-Based TAL High-level Code: Low-level Code: CALL SITE: newrgn ; mov r, RET; jmp f; RET: freergn ; more code letrgn  in f ( ) end; ... more code region lifetime • Region lifetimes are unclear in low-level code • Optimizations break the LIFO allocation structure David Walker, Cornell University

7. Contributions • The Capability Calculus: • A new statically-typed region-based intermediate language • A syntactic proof of soundness • Typed Assembly Language with primitives for safely allocating and freeing regions • A translation from a variant of the Tofte-Talpin framework David Walker, Cornell University

8. A New Perspective Static Capabilities Regions 2 1 1 2 x Free regionr1 2 2 1 x David Walker, Cornell University

9. The Capability Calculus • A continuation-passing style language: e ::= let d in e|v[t1,...,tm](v1,...,vn)|... • With declarations for separate allocation and deallocation of regions: d ::= newrgn | freergn  | x=v@ | ... David Walker, Cornell University

10. Types • Types: ints, tuples, polymorphic functions • <t1,...,tn> @ r • [D].(C,t1,...,tn) -> 0 @ r • Capabilities: the collection of regions currently accessible • C ::= Ø | e | {} | C1  C2(first try) David Walker, Cornell University

11. An Example ; C = {r1} ; C = {r1,r2} ; r1 ok ; r2 ok ; C = {r2} ; r2 ok ; r1 not ok! ; Initial Capability C = Ø let newrgn r1 newrgn r2 x = <2,3>@r1 y = <x,4>@r2 freergn r1 z = p1 y w = p1 z in ... r2 r1 y 4 2 3 r2 y 4 z David Walker, Cornell University

12. A Second Example ; C = {r1,r2} ; C = {r2} ; r2 ok fun f[r1,r2]({r1,r2}, x : <int>@r2, ...). let freergn r1 z = p1 x in ... ; C = {r} f [r,r](<3>@r, ...) ; instantiation causes r1 to alias r2: David Walker, Cornell University

13. Aliasing • Safe revocation requires that all copies of a capability be deleted • Type instantiation creates aliases • No local analysis can detect these aliases David Walker, Cornell University

14. Previous Work • Linear Type Systems (Girard,Wadler,...) • Syntactic Control of Interference (Reynolds) • These systems prevent aliasing; we need to track aliasing. David Walker, Cornell University

15. Alias Tracking • New Capabilities: {1} and {+} • {1} indicatesis unique • {+} indicatesis duplicatable • {+} = {+,+} but {1}  {1,1} • {+,+} is good but {1,1} is bad David Walker, Cornell University

16. Safe Deallocation ; Capability = C newrgn  ; Capability = C  {1} ; Capability = C  {1} freergn  ; Capability = C David Walker, Cornell University

17. An Example Revisited fun f[r1,r2]({r11,r21}, x : <int>@r2, ...). let freergn r1 z = p1 x in ... ; C = {r1} f [r,r](<3>@r, ...) ; C = {r31,r41} f [r3,r4](<3>@r4, …) ; C = {r11,r21} ; r1 unique, C = {r21} ; r2 ok ; No: {r1} {r1,r1} ; Yes! David Walker, Cornell University

18. Subcapabilities • Duplicatable capabilities: necessary to make functions sufficiently polymorphic • Unique capabilities provide all of the privileges of duplicatable capabilities: {r1}  {r+} David Walker, Cornell University

19. Using Subcapabilities fun g[r1,r2]({r1+, r2+}, x: <int>@r1, y: <int>@r2, ...). … ; neither region is deallocated ; Current Capability = {r1} let x = <3>@rin g [r,r](x, x, ...) ; ok: {r1}  {r+} = {r+, r+} David Walker, Cornell University

20. Final Pieces • Solution: bounded quantification allocate regions ; grants unique capabilities ... | jump to f ; lose some privileges: {r1}  {r+} | ... deallocate regions ; requires unique capabilities, ; but we’ve given them up ... David Walker, Cornell University

21. BQ Example let newrgn r ; capability C = {r1} ... ; f: [r1, r2,   {r1+, r2+}]. (, ..., (, ...) -> 0 @ r1) -> 0 @ r ... ; cont: ({r1}, ...) -> 0 @ r, frees region r in f [r, r, {r1}](..., cont) ; ok: {r1}  {r+} = {r+, r+} David Walker, Cornell University

22. Related Work • Region inference • Tofte and Talpin (PoPL ‘94) • Aiken et al. (PoPL ‘95) • Birkedal et al. (PoPL ‘96) • ML Kit with regions • Effect Systems, Monads • Linear Types, Syntactic Control of Interference David Walker, Cornell University

23. Summary • Capabilities govern access to sensitive data • We control capability aliasing by tracking uniqueness information • The result: flexible and provably safe deallocation David Walker, Cornell University