Type-safe operating system abstractions.

Abstract

Operating systems and low-level applications are usually written in languages like C and assembly, which provide access to low-level abstractions. These languages have unsafe type systems that allow many bugs to slip by programmers. For example, in 1988, the Internet Worm exploited several insecure points in Unix including the finger command. A call to finger with an unexpected argument caused a buffer overflow, leading to the shutdown of most Internet traffic. A finger application written in a type-safe language would have prevented its exploit and limited the points the Internet Worm could attack. Such vulnerabilities are unacceptable in securitycritical applications such as the secure coprocessors of the Marianas network [11, 21], secStore key storage from Plan 9 [6], and self-securing storage [25]. This research focuses on safe language techniques for building OS components that cannot cause memory or IO errors. For example, an Ethernet device driver communicates with its device through IO operations. The device depends on FIFO queues to send and receive packets. A mistake in an IO operation can overflow or underflow the FIFO queues, cause memory errors, or cause configuration inconsistencies on the device. Data structures such as FIFO queues can be written safely in safe languages such as Java and ML but these languages do not allow the access to the low-level resources that an OS programmer needs. Therefore, safe OS components require a language that combines the safety of Java with the low-level control of C. My research formalizes the concurrency, locks, and system state needed by the safety-critical areas of a device driver. These formal concepts are built on top of an abstract syntax and rules that guarantees basic memory safety using linear and singleton types to implement safe memory load and store operations. I proved that the improved abstract machine retains the property of soundness, which means that all well-typed programs will be able to execute until they reach an approved end

Type‐safe concurrent resource sharing

“…The soundness proofs for λ concurrent are shown in the author's PhD thesis 8 and briefly explained in this section. A well‐typed program is one which passes all of its typing and kinding rules.…”

“…For brevity, this paper shows the formal proofs for one form of type derivation (acquire) to provide insight into the overall proofs. Full details can be found in the companion technical report 8. Relevant type derivation rules are found in Figure 8.…”

“…The Transients Erase to Values lemma states that if . Therefore, erase(e′)=〈〉.The operational semantics for untyped lock acquisition on a free lock 8 are ( L , acquire(〈〉, i))→([i↦1]L, 〈〉) where L ( i )=0.Therefore, . The operational semantics for lock acquisition on a held lock are( R, M , acquire(lock, i))→ ( R, M , acquire(lock, i)) where and M ( i )=1.Therefore, ( R, M, e )=( R ′, M ′, e ′) such that erase((R, M, e))=erase((R′, M′, e′)) such that . If erase(e) is a value, then and erase((R, M, e))=erase((R′, M′, v)).The premises are Θ;Ψ⊢( R, M, e : τ) erase(e)=u Let f be the set of expressions e where erase(e)=u..The f*Step‐Value lemma states that if Θ;Ψ⊢ f : τ then , therefore .By Preservation, e : τ and v : τ.…”

“…As erase(e)=u, erase((R, M, e))=erase((R, M, v)). If erase((R, M, e))→(L′, d′), then and erase((R′, M′, e′))=(L′, d′).Proof is by induction on the expressions.The premises are e =acquire(e 1 , e 2 ) erase((R, M, acquire(e 1 , e 2 )))→(L′, d′) Θ;Ψ⊢( R, M , acquire(e 1 , e 2 ): τ) By Inversion for lock acquisition, Θ;Ψ e ;Δ;Γ⊢ e 1 : Lock(I, τ) and Θ;Ψ e ;Δ;Γ⊢ e 2 : Int(I).By Erasure for lock acquisition, erase(e)=erase(acquire(e 1 , e 2 ))=acquire(erase(e 1 ), erase(e 2 )).If erase(e 1 )≠u 1 then the Untyped Progress lemma 8 states that if Θ;Ψ 1 ⊢( R, M, e 1 : τ) and erase(e 1 )≠u 1 then erase((R, M, e 1 ))→(L′, d 1 ′). By induction, and erase((R′, M′, e′ 1 ))=(L′, d 1 ′).…”

“…The Transients Erase to Values lemma states that if . Therefore, erase(e′)=〈〉.The operational semantics for untyped lock acquisition on a free lock 8 are ( L , acquire(〈〉, i))→([i↦1]L, 〈〉) where L ( i )=0.Therefore, . The operational semantics for lock acquisition on a held lock are( R, M , acquire(lock, i))→ ( R, M , acquire(lock, i)) where and M ( i )=1.Therefore, ( R, M, e )=( R ′, M ′, e ′) such that erase((R, M, e))=erase((R′, M′, e′)) such that .…”