1/18

Enforcing Well-Bracketed Control Flow on aCapability Machine using Local Capabilities

Lau Skorstengaard1 Dominique Devriese2 Lars Birkedal1

1Aarhus University

2imec-DistriNet, KU Leuven

SCM, January 15, 2017

2/18

Why capability machines?

I Interesting compilation targetI C-like calling conventionI Enforcement of well-bracketed calls

I Subject of systems researchI CHERI

3/18

Talk outline

A simple capability machine

ApplicationsEnforcing well-bracketedness

Semantic modelKripke worldsLogical relationInteresting properties

Conclusion

4/18

Road map

A simple capability machine

ApplicationsEnforcing well-bracketedness

Semantic modelKripke worldsLogical relationInteresting properties

Conclusion

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

Jstore r1 r2K (Φ) =

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

Jstore r1 r2K (Φ) =

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memory

I Capabilities (perm, base, end , a)I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

Jstore r1 r2K (Φ) =

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

Jstore r1 r2K (Φ) =

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

Jstore r1 r2K (Φ) =

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

w = Φ.reg(r2)

Jstore r1 r2K (Φ) = Φ[mem.? 7→ w ]

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

w = Φ.reg(r2) Φ.reg(r1) = (perm, base, end , a)

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

w = Φ.reg(r2) Φ.reg(r1) = (perm, base, end , a)perm ∈ {rw, rwx}Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

5/18

Memory capabilities

Challenge:

I Low-level machines provide no means to enforce fine-grainedaccess control.

Solution:

I Assembly language that uses capabilities instead of pointers

I Tagged memoryI Capabilities (perm, base, end , a)

I Permission e.g. read (r), write (w), execute (x)I Range of authorityI Pointer

I Capability aware instructions enforce capability permissions

w = Φ.reg(r2) Φ.reg(r1) = (perm, base, end , a)perm ∈ {rw, rwx} base ≤ a ≤ end

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

6/18

Enter capabilities

Challenge:

I Execute capabilities provide no encapsulation: how can wegive the callee more authority than caller?

Solution (from M-Machine):I Enter capability:

I Completely opaque, you can only jump to itI Becomes rx when jumped to

I ∼ encapsulated closure

I Security boundaries

I Modularisation

6/18

Enter capabilities

Challenge:

I Execute capabilities provide no encapsulation: how can wegive the callee more authority than caller?

Solution (from M-Machine):I Enter capability:

I Completely opaque, you can only jump to itI Becomes rx when jumped to

I ∼ encapsulated closure

I Security boundaries

I Modularisation

7/18

Local capabilities

Challenge:

I Capabilities are irrevocable.

Solution (from CHERI):

I Local capabilities (form of temporal information-flow control)

I Capabilities extended with a local tag and a permit write localpermission (wl)

I Local capabilities can only be written to memory through a wlcapability

I (to make it useful:) wl-capabilities must be local themselves

w = Φ.reg(r2) Φ.reg(r1) = ((perm, g), base, end , a)perm ∈ {rw, rwx, }

base ≤ a ≤ end

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

7/18

Local capabilities

Challenge:

I Capabilities are irrevocable.

Solution (from CHERI):

I Local capabilities (form of temporal information-flow control)

I Capabilities extended with a local tag and a permit write localpermission (wl)

I Local capabilities can only be written to memory through a wlcapability

I (to make it useful:) wl-capabilities must be local themselves

w = Φ.reg(r2) Φ.reg(r1) = ((perm, g), base, end , a)perm ∈ {rw, rwx, }

base ≤ a ≤ end

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

7/18

Local capabilities

Challenge:

I Capabilities are irrevocable.

Solution (from CHERI):

I Local capabilities (form of temporal information-flow control)

I Capabilities extended with a local tag and a permit write localpermission (wl)

I Local capabilities can only be written to memory through a wlcapability

I (to make it useful:) wl-capabilities must be local themselves

w = Φ.reg(r2) Φ.reg(r1) = ((perm, g), base, end , a)perm ∈ {rw, rwx, }

base ≤ a ≤ end

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

7/18

Local capabilities

Challenge:

I Capabilities are irrevocable.

Solution (from CHERI):

I Local capabilities (form of temporal information-flow control)

I Capabilities extended with a local tag and a permit write localpermission (wl)

I Local capabilities can only be written to memory through a wlcapability

I (to make it useful:) wl-capabilities must be local themselves

w = Φ.reg(r2) Φ.reg(r1) = ((perm, g), base, end , a)perm ∈ {rw, rwx, rwl, rwlx}

base ≤ a ≤ end

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

7/18

Local capabilities

Challenge:

I Capabilities are irrevocable.

Solution (from CHERI):

I Local capabilities (form of temporal information-flow control)

I Capabilities extended with a local tag and a permit write localpermission (wl)

I Local capabilities can only be written to memory through a wlcapability

I (to make it useful:) wl-capabilities must be local themselves

w = Φ.reg(r2) Φ.reg(r1) = ((perm, g), base, end , a)perm ∈ {rw, rwx, rwl, rwlx}

base ≤ a ≤ end w = (( , local), , , )

Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

7/18

Local capabilities

Challenge:

I Capabilities are irrevocable.

Solution (from CHERI):

I Local capabilities (form of temporal information-flow control)

I Capabilities extended with a local tag and a permit write localpermission (wl)

I Local capabilities can only be written to memory through a wlcapability

I (to make it useful:) wl-capabilities must be local themselves

w = Φ.reg(r2) Φ.reg(r1) = ((perm, g), base, end , a)perm ∈ {rw, rwx, rwl, rwlx}

base ≤ a ≤ end w = (( , local), , , )⇒ perm ∈ {rwl, rwlx}Jstore r1 r2K (Φ) = Φ[mem.a 7→ w ]

8/18

Road map

A simple capability machine

ApplicationsEnforcing well-bracketedness

Semantic modelKripke worldsLogical relationInteresting properties

Conclusion

9/18

Enforcing well-bracketedness (without a trusted stack)

Basic idea:

I Return pointer as local enter-capabilityI Stack pointer as local rwlx-capability

I Only place one can store local capabilities

Many details to get right:

I Clear non-argument registers before jumps to untrusted code

I Clear part of the stack the callee gains control over

I Adversary callbacks must be global

Results:

I Provably enforce well-bracketed control flow and local stateencapsulation, without a trusted stack!

I (Even with a trusted stack, some points above still needed.)

9/18

Enforcing well-bracketedness (without a trusted stack)

Basic idea:

I Return pointer as local enter-capabilityI Stack pointer as local rwlx-capability

I Only place one can store local capabilities

Many details to get right:

I Clear non-argument registers before jumps to untrusted code

I Clear part of the stack the callee gains control over

I Adversary callbacks must be global

Results:

I Provably enforce well-bracketed control flow and local stateencapsulation, without a trusted stack!

I (Even with a trusted stack, some points above still needed.)

9/18

Enforcing well-bracketedness (without a trusted stack)

Basic idea:

I Return pointer as local enter-capabilityI Stack pointer as local rwlx-capability

I Only place one can store local capabilities

Many details to get right:

I Clear non-argument registers before jumps to untrusted code

I Clear part of the stack the callee gains control over

I Adversary callbacks must be global

Results:

I Provably enforce well-bracketed control flow and local stateencapsulation, without a trusted stack!

I (Even with a trusted stack, some points above still needed.)

9/18

Enforcing well-bracketedness (without a trusted stack)

Basic idea:

I Return pointer as local enter-capabilityI Stack pointer as local rwlx-capability

I Only place one can store local capabilities

Many details to get right:

I Clear non-argument registers before jumps to untrusted code

I Clear part of the stack the callee gains control over

I Adversary callbacks must be global

Results:

I Provably enforce well-bracketed control flow and local stateencapsulation, without a trusted stack!

I (Even with a trusted stack, some points above still needed.)

10/18

Road map

A simple capability machine

ApplicationsEnforcing well-bracketedness

Semantic modelKripke worldsLogical relationInteresting properties

Conclusion

11/18

Kripke worlds

I Recursive Kripke worldI Collection of regions

I Regions model evolvable invariants (protocols) on memoryI State machines with public and private transitions

I A future world is an extension of a world

11/18

Kripke worlds

I Recursive Kripke worldI Collection of regions

I Regions model evolvable invariants (protocols) on memoryI State machines with public and private transitions

I A future world is an extension of a world

11/18

Kripke worlds

I Recursive Kripke worldI Collection of regions

I Regions model evolvable invariants (protocols) on memoryI State machines with public and private transitions

I A future world is an extension of a world

11/18

Kripke worlds

Challenge: we want to reuse memory e.g., on the stack

I Permanent regions, remain present in any future world

I Temporary regions, may be revoked in private future worlds

I Revoked regions

11/18

Kripke worlds

Permanent:

Temporary:

Challenge: we want to reuse memory e.g., on the stack

I Permanent regions, remain present in any future world

I Temporary regions, may be revoked in private future worlds

I Revoked regions

11/18

Kripke worlds

Permanent:

Temporary:

Challenge: we want to reuse memory e.g., on the stack

I Permanent regions, remain present in any future world

I Temporary regions, may be revoked in private future worlds

I Revoked regions

11/18

Kripke worlds

Permanent:

Temporary:

Revoked:

Challenge: we want to reuse memory e.g., on the stack

I Permanent regions, remain present in any future world

I Temporary regions, may be revoked in private future worlds

I Revoked regions

11/18

Kripke worlds

Permanent:

Temporary:

Revoked:

Relation to local capabilities

I Local capabilitiesI Can depend on temporary and permanent regions

I Global capabilitiesI Can only depend on permanent regions

11/18

Kripke worlds

Permanent:

Temporary:

Revoked:

Local capability:

Relation to local capabilitiesI Local capabilities

I Can depend on temporary and permanent regions

I Global capabilitiesI Can only depend on permanent regions

11/18

Kripke worlds

Permanent:

Temporary:

Revoked:

Local capability:

Global capability:

Relation to local capabilitiesI Local capabilities

I Can depend on temporary and permanent regions

I Global capabilitiesI Can only depend on permanent regions

11/18

Kripke worlds

Permanent:

Temporary:

Revoked:

Local capability:

Global capability:

Relation to local capabilitiesI Local capabilities

I Can depend on temporary and permanent regions

I Global capabilitiesI Can only depend on permanent regions

12/18

Logical relation

V(W )def= {(n, i) | i ∈ Z}

∪{

(n, ((r, g), base, end , a)) |(n, (base, end)) ∈ readCondition(g)(W )

}∪ · · ·

R(W )def= {(n, reg) | ∀r ∈ RegisterName \ {pc}. (n, reg(r)) ∈ V(W )}

E(W )def=

{(n, pc)

∣∣∣∣∀n′ ≤ n,(n′, reg

)∈ R(W ),ms :n′ W .(

n′, (reg [pc 7→ pc],ms))∈ O(W )

}

I Semantic model of well-behaved programsI Captures the safe behaviour of the system

I e.g., no global permit-write-local capabilities

I Uses PL techniques known from high-level languages

12/18

Logical relation

V(W )def= {(n, i) | i ∈ Z}

∪{

(n, ((r, g), base, end , a)) |(n, (base, end)) ∈ readCondition(g)(W )

}∪ · · ·

R(W )def= {(n, reg) | ∀r ∈ RegisterName \ {pc}. (n, reg(r)) ∈ V(W )}

E(W )def=

{(n, pc)

∣∣∣∣∀n′ ≤ n,(n′, reg

)∈ R(W ),ms :n′ W .(

n′, (reg [pc 7→ pc],ms))∈ O(W )

}

I Semantic model of well-behaved programsI Captures the safe behaviour of the system

I e.g., no global permit-write-local capabilities

I Uses PL techniques known from high-level languages

12/18

Logical relation

V(W )def= {(n, i) | i ∈ Z}

∪{

(n, ((r, g), base, end , a)) |(n, (base, end)) ∈ readCondition(g)(W )

}∪ · · ·

R(W )def= {(n, reg) | ∀r ∈ RegisterName \ {pc}. (n, reg(r)) ∈ V(W )}

E(W )def=

{(n, pc)

∣∣∣∣∀n′ ≤ n,(n′, reg

)∈ R(W ),ms :n′ W .(

n′, (reg [pc 7→ pc],ms))∈ O(W )

}I Semantic model of well-behaved programsI Captures the safe behaviour of the system

I e.g., no global permit-write-local capabilities

I Uses PL techniques known from high-level languages

12/18

Logical relation

V(W )def= {(n, i) | i ∈ Z}

∪{

(n, ((r, g), base, end , a)) |(n, (base, end)) ∈ readCondition(g)(W )

}∪ · · ·

R(W )def= {(n, reg) | ∀r ∈ RegisterName \ {pc}. (n, reg(r)) ∈ V(W )}

E(W )def=

{(n, pc)

∣∣∣∣∀n′ ≤ n,(n′, reg

)∈ R(W ),ms :n′ W .(

n′, (reg [pc 7→ pc],ms))∈ O(W )

}I Semantic model of well-behaved programsI Captures the safe behaviour of the system

I e.g., no global permit-write-local capabilities

I Uses PL techniques known from high-level languages

12/18

Logical relation

V(W )def= {(n, i) | i ∈ Z}

∪{

(n, ((r, g), base, end , a)) |(n, (base, end)) ∈ readCondition(g)(W )

}∪ · · ·

R(W )def= {(n, reg) | ∀r ∈ RegisterName \ {pc}. (n, reg(r)) ∈ V(W )}

E(W )def=

{(n, pc)

∣∣∣∣∀n′ ≤ n,(n′, reg

)∈ R(W ),ms :n′ W .(

n′, (reg [pc 7→ pc],ms))∈ O(W )

}I Semantic model of well-behaved programsI Captures the safe behaviour of the system

I e.g., no global permit-write-local capabilities

I Uses PL techniques known from high-level languages

13/18

Interesting properties

Lemma (Revoke temporary memory satisfaction)

If ms :n W , then ms = ms ′ ]msr and ms ′ :n revokeTemp(W )

Lemma (Double monotonicity of value relation)

I If (n,w) ∈ V(W ) and W ′ wpub W then (n,w) ∈ V(W ′).

I If (n,w) ∈ V(W ) and W ′ wpriv W and w is not a localcapability, then (n,w) ∈ V(W ′).

13/18

Interesting properties

Lemma (Revoke temporary memory satisfaction)

If ms :n W , then ms = ms ′ ]msr and ms ′ :n revokeTemp(W )

Lemma (Double monotonicity of value relation)

I If (n,w) ∈ V(W ) and W ′ wpub W then (n,w) ∈ V(W ′).

I If (n,w) ∈ V(W ) and W ′ wpriv W and w is not a localcapability, then (n,w) ∈ V(W ′).

14/18

Fundamental theorem of logical relations

I General statement of the guarantees provided by thecapability machine.

I Intuitively: any program is safe as long as it only has access tosafe values.

Theorem (FTLR)

Ifperm = rx ∧ (n, (base, end)) ∈ readCondition(g)(W )

(or similarly for rwx and rwlx),then

(n, ((perm, g), base, end , a)) ∈ E(W )

15/18

Road map

A simple capability machine

ApplicationsEnforcing well-bracketedness

Semantic modelKripke worldsLogical relationInteresting properties

Conclusion

16/18

Conclusion

I Reasoning about a capability machineI Logical relation with some interesting novel aspects

I local capabilities require public/private future worlds, used innew way

I Provably enforce well-bracketed control flow using (just) localcapabilities

I Several details to get right

17/18

Questions/discussion

18/18

Recursive domain equation (simplified)

Wor ≈ Region∗

Region::=revoked

| (temp, s, (φpub, φ),H) with H ∈ State→ (Wormon, ne−−−−−→wpub

UPred(MemSegment))

| (perm, s, (φpub, φ),H) with H ∈ State→ (Wormon, ne−−−−−→wpriv

UPred(MemSegment))