Filetype PDF | Posted on 03 Feb 2023 | 2 years ago
Authentication
digital resources
95x Filetype PDF File size 1.71 MB Source: dingelish.com
Session 10B: TEE II CCS ’19, November 11–15, 2019, London, United Kingdom
TowardsMemorySafeEnclaveProgrammingwithRust-SGX
HuiboWang†1,PeiWang∗,YuDing∗,MingshenSun∗,YimingJing∗,RanDuan∗,LongLi∗,
Yulong Zhang∗, Tao Wei∗, Zhiqiang Lin‡
†The University of Texas at Dallas
∗Baidu X-Lab
‡The Ohio State University
ABSTRACT 11ś15, 2019, London, United Kingdom. ACM, New York, NY, USA, 18 pages.
Intel Software Guard eXtension (SGX), a hardware supported https://doi.org/10.1145/3319535.3354241
trustedexecutionenvironment(TEE),isdesignedtoprotectsecurity
critical applications. However, it does not terminate traditional 1 INTRODUCTION
memorycorruption vulnerabilities for the software running inside Software developed with type unsafe languages such as C/C++ is
enclave, since enclave software is still developed with type unsafe subject to memory corruption, such as buffer overflow, integer
languages such as C/C++. This paper presents Rust-SGX, an overflow, double free, and use after free. Memory corruption
efficient and layered approachtoexterminatingmemorycorruption attacks have been one of the most severe cyber threats for over
for software running inside SGX enclaves. The key idea is to enable 40 years. Numerous such attacks have occurred, including Morris
the development of enclave programs with an efficient memory Worm[1],stacksmashing[26],return-into-libc[35],returnoriented
safe system language Rust with a Rust-SGX SDK by solving the programming(ROP)[29](anditsvariants such as BROP [10] and
key challenges of how to (1) make the SGX software memory safe JIT-ROP[31]),jumporientedprogramming(JOP)[11],calloriented
and (2) meanwhile run as efficiently as with the SDK provided programming (COP) [27], and even data-oriented programming
byIntel. We therefore propose to build Rust-SGX atop Intel SGX (DOP)[16]. It is likely that these attacks will continue to remain a
SDK,andtameunsafecomponentswithformallyprovenmemory major cyber threat for years to come.
safety. We have implemented Rust-SGX and tested with a series of Several years ago, Intel introduced Software Guard eXtensions
benchmarkprograms. Our evaluation results show that Rust-SGX (SGX)initsSkylakeCPU,whichprovidesapplicationprogrammers
imposes little extra overhead (less than 5% with respect to the SGX the capability to execute code in a secure enclave, namely an
specific features and services compared to software developed by isolated trusted execution environment (TEE) [24]. In particular,
Intel SGX SDK), and meanwhile have stronger memory safety. SGXisolates sensitive code and data from the operating systems,
CCSCONCEPTS hypervisors, BIOS, and other applications. It guarantees confiden-
· Security and privacy → Formal methods and theory of tiality and integrity of enclave programs even when the systems
security; Systems security; software such as operating systems, hypervisors, and BIOS are
compromised. However, SGX hardware does not guarantee any
KEYWORDS memorysafetyfor the software running inside enclave, since they
are still developed with memory unsafe languages such as C/C++
SGX,RustProgrammingLanguage,MemorySafety,TypeSystem or assembly today.
Soundness As a result, SGX programs still face the traditional memory
ACMReferenceFormat: corruption vulnerabilities as does traditional software. This can
†1 ∗ ∗ ∗ ∗ seriously undermine the security guarantee provided by SGX, and
HuiboWang ,PeiWang ,YuDing ,MingshenSun ,YimingJing ,Ran allowattackerstoviolatetheintegrityandconfidentialityofenclave
∗ ∗ ∗ ∗ ‡
Duan , Long Li , Yulong Zhang , Tao Wei , Zhiqiang Lin . 2019. Towards programs.Forinstance,whentheenclavecodeisimplementedwith
MemorySafeEnclaveProgrammingwithRust-SGX.In2019ACMSIGSAC memorycorruptionvulnerabilities,ithasbeenshownthatattackers
Conference on Computer and Communications Security (CCS ’19), November can leverage return-oriented programming (ROP) [29] to perform
1Thebulkofthis work was done while the first author was interning at Baidu X-Lab. memoryhijacking to leak secrets [9, 21]. Although randomization-
Permission to make digital or hard copies of all or part of this work for personal or basedapproaches[28]havebeenproposedtomitigatesuchattacks,
classroom use is granted without fee provided that copies are not made or distributed Biondoetal. [9] have also pointed out that SGX runtime inherently
for profit or commercial advantage and that copies bear this notice and the full citation contains memory regions whose addresses are fixed, and it is
onthefirst page. Copyrights for components of this work owned by others than ACM therefore difficult to completely eradicate such threats.
mustbehonored.Abstractingwithcreditispermitted.Tocopyotherwise,orrepublish, Overthepastdecades, a large number of defense mechanisms
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org. have been proposed to defeat memory corruption attacks, such as
CCS’19, November 11ś15, 2019, London, United Kingdom StackCanaries[13],DataExecutionPrevention(DEP)[34],Address
©2019Association for Computing Machinery. Space Layout Randomization (ASLR) [18], Control Flow Integrity
ACMISBN978-1-4503-6747-9/19/11...$15.00 (CFI) [6], so on and so forth. However, they all are imperfect for
https://doi.org/10.1145/3319535.3354241
2333
Session 10B: TEE II CCS ’19, November 11–15, 2019, London, United Kingdom
various reasons such as the performance cost outweighing the with Rust-SGX has indicated that programming with Rust-SGX is
potential protection, incompatibility with legacy systems, relying productive, efficient, and reliable.
on changes in the compiler tool chain, or requiring the access Contributions. To summarize, we make the following contribu-
of program source-code. It is thus imperative to look for other tions in this paper:
alternatives to secure SGX enclaves programs. • We present Rust-SGX, a practical and layered approach
Since SGX is a brand new platform, where not as many legacy to exterminating memory corruptions for SGX enclave
applications need support, it provides a perfect opportunity of programs.
using efficient memory safe system languages to develop enclave • Weproposetheuseoftypesafetyandformalprooftohandle
programs instead of relying on traditional defenses such as ASLR theunsafecomponentswhendealingwithalayeredmemory
or CFI. Today, there are a variety of programming languages safety model.
with memory safe features including Rust, Go, Swift, JavaScript, • We have implemented Rust-SGX and evaluated it with a
Java, Python, and Solidity. Enabling the use of these programming number of benchmark programs. Our evaluation results
languages for SGX program development would be an appealing showthatRust-SGXfullypreserves the SGX functionality
approach to terminate the memory corruptions inside enclave. andmeanwhiledoesnotimposeanysignificantperformance
However, there are still enormous challenges when enabling overhead.
a memory safe language for enclave software development. In
particular, memory safe programming languages often contain Roadmap. The rest of this paper is organized as follows. In
memory-unsafe components, such as Java’s JVM, Python’s C ğ2, we provide necessary background related to Intel SGX and
libraries, Swift’s Object-C runtime, JavaScript’s garbage collection Rust programming language. ğ3 describes the objectives, threat
(GC) engine, Go’s assembly code, and Rust’s unsafe features. modelandscope,challenges and architecture of Rust-SGX. Next,
Second, not all components inside the enclave can be developed we present how we perform secure binding between Rust and
with memory safe languages, such as the SGX feature specific C/C++ (ğ4), formalize and prove the memory safety (ğ5), with
instructions (e.g., remote attestation) and also the performance implementation (ğ6), evaluation (ğ7), and applications (ğ8) of Rust-
critical cryptography operations, as they may have to be written in SGX,respectively. In ğ9, we discuss the limitations and future work,
assembly languages. followed by related work in ğ10. Finally, ğ11 concludes the paper.
Therefore, it is impractical to have every component inside SGX
enclave to be memory safe. Practical memory safety inside enclave 2 BACKGROUND
needs to be contained and layered. Rust-SGX, a new memory 2.1 Intel SGX
safe SGX SDK proposed in this work, is designed based on this Intel SGX is designed to provide applications the capability of
observation. More specifically, we leverage Intel SGX SDK as the executing code in a secure enclave while protecting secrets with
foundation that provides a set of full fledged SGX development their own execution environment [3, 24]. With SGX, application
APIs, and add a Rust layer on top of it. With Rust-SGX, enclave programmers can directly control the security of their applications
programmerscandeveloptheir programs in pure Rust, and Rust- without relying on any underlying system software such as the
SGX will bridge the gap between the Rust world and Intel SGX OSorhypervisor. Such a design significantly reduces the trusted
interfaces. Compared to the enclave programs developed by Intel computing base (TCB) to the smallest possible code (i.e., only the
SGX SDK, the enclave programs developed with Rust-SGX are code executed inside the enclave is trusted), and prevents various
significantly more secure at the application layer thanks to the software attacks even when the system software is compromised.
memory-safe Rust language. Whereas at the library layer, they TouseSGX,theapplications typically need to be implemented
have equivalent security properties due to the same dependency with two components: a trusted component and an untrusted
onIntel SGX SDK. component. The trusted component is executed inside the enclave,
EnablingRustatopIntelSGXSDKisnon-trivial.Akeychallenge whereas the untrusted component is executed outside. When data
wemustsolveistomakesuretheforeignfunctioninterface (FFI) needs to be passed between trusted and untrusted components, it
between memory-safe and memory-unsafe languages (i.e., Rust has to be copied from and to the enclave because enclave memory
andC/C++)issecure.Rust-SGXaddressesthisissueviaformalized cannot be read directly outside of the enclave. Intel provides a
modelingandproofofthememorysafetyoftheFFI.Atahighlevel, mechanismtocreatebridge functions by using its corresponding
our formalization is inspired by both CCured [25] and the safe Java SGXSDK.Abridgefunctionattheenclaveentrypointdispatches
Native Interfaces (JNI) by Tan el al. [32], and we extend them to calls to the corresponding functions inside the enclave. This allows
secure the critical boundary code bridging the safe Rust world and anenclavetorunonlycertainfunctionsspecifiedbythedevelopers.
unsafe C/C++ world. These functions are called ECALLs, and they are called from the
WehaveimplementedRust-SGX,andtesteditwithanumberof untrusted component. There are also corresponding functions that
benchmarkprograms. Our evaluation results show that Rust-SGX resideintheuntrustedcomponentcalledOCALLs,whichareinvoked
SDKonlyimposesimperceptible or modest overhead (less than 5% inside the enclave to request services from the outside world.
with respect to the SGX services compared to software developed
by Intel SGX SDK). Rust-SGX has been released as an open source 2.2 TheRustProgrammingLanguage
project. It has been widely employed by the community to develop
memory-safe SGXenclaves since 2017. The community adoption Rust [23] is a systems programming language, allowing developers
to have efficient implementation for systems software. It supports
2334
Session 10B: TEE II CCS ’19, November 11–15, 2019, London, United Kingdom
both functional and imperative-procedural programming. Rust is abuse the łunsafež feature mentioned in ğ2.2 to produce Rust
designed to be memory safe with zero-cost abstraction. Its unique programs with exploitable memory bugs. To have a completely
type system can statically guarantee the absence of uninitialized secure development process, the enclave code should be audited
variables, dangling pointers, race conditions, and other memory (manually or automatically with machine checks) before being
safety bugs. Meanwhile, Rust does not rely on any automated deployed. Rust programs, by their nature, are significantly easier to
garbage collection to reclaim memory resources, and instead most audit than those written in memory unsafe languages, even with
Rustobjectshavestaticallyknownlifetimeandtherestaremanaged the presence of łunsafež code blocks. Nevertheless, how to audit
through smart pointers. Rust does not allow null pointers, and the the enclave code is also not within the scope of this work.
data structures have to be acyclic.
AnimportantconceptinRusttogainstaticallyverifiablememory 3.2 Challenges
safety is the memory ownership [23]. The basic rules of memory Atahighlevel,therearetwodirectionstobuildmemorysafeRust-
ownership dictate that each memory object has a single owner SGX. The first one is to build it from scratch without relying on
variable at each program point. When the owner variable goes out anything, and the second is a layered approach in which Rust-SGX
of scope, the value is automatically deallocated. Other variables is built atop an existing full-fledged SDK (e.g., Intel SGX SDK).
can temporarily łborrowž the object from its owner, but they have To build Rust-SGX from scratch sounds very appealing. It
to return it before the owner reaches the end of its lifetime. An unfortunately faces erroneous challenges. First, SGX enclave
object can be borrowed unlimited number of times when it is in an programs heavily involve cryptographic computations (abstracted
immutable state, whereas mutable borrows are exclusive. In this as APIs), e.g., when communicating with outside enclave, the
way, Rust ensures that no memory objects are both mutable and messages needed to be encrypted or signed. It is challenging to
aliased at the same time, eliminating memory errors. implement these cryptography APIs directly using Rust without
However,Rustdoesprovideamechanismtoallowprogrammers usingassemblycode,especiallyforperformancereasons.Ingeneral,
to write code that bypasses its memory safety checks. This is a cryptography algorithms get much better speedups from being
necessary compromise when Rust needs to interact with other written in assembly than most other programming languages. One
languagesormanipulatethehardwaredirectly,sincethetypesafety notable example is the Intel’s native AES-NI hardware implementa-
ofRustisnotapplicabletocodeacrosstheseirregularprogramming tion of the cipher, which can be directly invoked by the assembly
boundary. An łunsafež keyword is introduced to mark unchecked code.
code for the convenience of additional security auditing. Second, now that Rust itself contains unsafe Rust and also
3 OVERVIEW Rust-SGXinevitably has to include assembly code for the efficient
3.1 Objectives, Threat model, and Scope cryptographic API implementations, we will not be able to develop
Rust-SGXpurelywithRust.Ontheotherhand,thereisalreadyfull-
Thekeyobjective of Rust-SGX is to remove memory corruption fledgedIntelSGXSDKavailablethatcontainsnotonlyperformance
vulnerabilities inside SGX enclave by enabling the enclave software efficient implementations for cryptography APIs, but also strong
development with memory safe languages. Not all memory safe supportofSGXfunctionalitysuchassealingandremoteattestation.
languages (e.g., Python) are of our interest, and instead we have There is no need to re-implement them in another language if we
particular interest in the more efficient memory safe system can still achieve the same performance. Therefore, we decide to
languages. That is why we focus on Rust. However, we must ensure build Rust-SGX atop Intel SGX SDK. This also leads to the second
that our design and implementation will impose no significant challenge we must solve: namely how to guarantee programs
performance overhead when enabling Rust with SGX enclave developedwithRust-SGXstillhasefficientperformance,compared
programming. to the enclave programs developed with traditional SGX SDKs.
Rust-SGX shares the same threat model as does Intel SGX; Third,withtheintegrationofIntelSGXSDKandalsotheoriginal
namely, only the software running inside the enclave is trusted, unsafe Rust, we must provide a safety guarantee in spite of these
and the rest (e.g., operating systems and hypervisors) is untrusted. unsafe components. With a layered approach, a practical way is
Theparticular attacks Rust-SGX aims to defeat are those memory to ensure the interfaces between layers are secure. For instance,
corruptions that exploit the insecure memory operations inside whenproviding APIs for Rust SGX programmers, we must ensure
enclave programs. We do not provide any additional mechanisms that the foreign function interface (FFI) is secure. That is, all the
to defeat various side channel attacks (e.g., page [36], cache [15]) arguments and side effects of FFI function must be interposed and
againstenclaveprograms,whichisorthogonaltothememorysafety verified.
problem we aim to solve. Finally, there are also a number of engineering challenges
In this work, we only focus on enabling application layer of implementing Rust-SGX, especially due to the discrepancies
memory safety. The memory safety of the lower layer software between the program execution model in enclave programs and
such as the core SGX libraries (e.g., the cryptographic function traditional Rust programs. For instance, static data can be easily
implementations and SGX core service routines) are not within initialized in Rust, but there is no such mechanisms in SGX enclave.
our scope. Note that Rust-SGX only provides enclave developers Also, unlike Rust thread, SGX thread does not have constructors
with the support for building memory safe SGX applications; nor destructors. In addition, Rust mutex is different compared to
however,it does not enforce strict adherence to all rules of memory SGXpthreadmutex,andwemustproperlyimplementRustmutex
safe programming. For example, application developers can still with SGX enclaves.
2335
Session 10B: TEE II CCS ’19, November 11–15, 2019, London, United Kingdom
developed a scheme to safely call C functions inside a Java runtime
Enclave Enclave Enclave environment via Java Native Interfaces (JNI). We face a similar
Application Application Application situation in the design of Rust-SGX. Although the safety of Java
and Rust is enforced via different mechanisms, the details are
Rust-SGX Trusted APIs/Libs independent of the approach of Tan et al. Therefore, we have to
modify and extend their techniques to securely binding the Rust
Trusted Runtime, Services
(sgx_trts,sgx_tservice,sgx
Standard Support Libs language with the underlying Intel SGX SDK through carefully
_tseal,...)
(sgx_tstd,sgx_tdh,...) designed foreign function interfaces (FFI).
Rust World Thecoreideais to regulate the behavior of unsafe C/C++ code
via a safe memory management scheme and an advanced type
Securely Binding Between C/C++ and Rust system (with certain run-time checks) that supports safe pointer
C/C++ World operations. In general, such a memory management scheme and
type system can restrict the expressiveness of the unsafe language
Trusted Runtime, Services
Standard Support Libs
(libsgx_trts.a, andaffect programmer’s productivity. For Rust-SGX, however, this
(libsgx_tstdc.a,
libsgx_tservice.a,...) is much less of a concern, since we only need to safely wrap a fixed
libsgx_tcxx.a,...) set of C/C++ APIs that are guaranteed to be stable by Intel. After a
Intel SGX Trusted APIs/Libs thorough review of Intel SGX SDK, we found that the semantics of
theC/C++APIsareverysuitabletotheaforementionedsafetyregu-
Figure 1: Overview of Rust-SGX. lation. In the rest of this section, we show that it is feasible to design
a memory safe interpolation scheme between the Rust language
andIntel SGX SDK, with the safety properties formally proved.
3.3 Architecture It is worth mentioning that our purpose is not to provide a
Anoverviewof Rust-SGXispresentedinFigure1.Therearethree general memory safe Rust foreign function interface to C/C++, but
layers inside Rust-SGX: (1) the bottom layer that is the Intel SGX tosecurelyconnectRustwiththeC/C++interfaceofIntelSGXSDK.
SDK(whichisimplementedinC/C++andalsoassembly),(2)the Therefore, we are allowed to exclude a considerable proportion of
middle layer that is the Rust and Foreign function Interfaces (FFI) C/C++semantics from our consideration. Many problems that are
forC/C++,and(3)thetoplayerthatistheRustSGXSDK.Rust-SGX difficult to address for a general solution can be solved through
provides memory safety by using Rust’s memory safe properties, enumeration and a reasonable amount of manual checks, since the
andmeanwhileensuringtheinterfaceofinteractingwiththelower Intel SGX SDK only provides a finite set of C/C++ data structures
Intel SGX SDK is memory safe. andAPIsthatarenotextensible by enclave developers.
Notethat we cannot prove nor verify the memory safety of Intel
SGXSDKduetoitslargecodebaseandheavyuseofC/C++,but 4.1 Safe MemoryManagement
if we can ensure the interaction between Rust world and C/C++ Bymanuallyauditing the semantics of all Intel SGX APIs, which
world is secure and prove the Rust world can not be escaped, then are clearly documented by an Intel-provided manual, we found that
we can still ensure the memory safety of the Rust world. This theseC/C++functionsareabletoensurehigh-degreeofsegregation
is similar to the issues in which type safe language such as Java betweentheheapsmanagedbytheRustworldandtheC/C++world.
interactswiththeJavanativeinterface(JNI).However,therearestill In particular, the C/C++ APIs never free, or hold references to, the
substantial differences, e.g., Rust and Java are totally independent memoryobjectsmanagedbycallers. Therefore, calling Intel APIs
from language aspect, and meanwhile SGX SDK itself has a variety preserves the safety invariant of the Rust heap without the need
of data types. We must build a proper mapping between the Rust of additional regulation.
world and SGX world. The details of how we achieve this mapping However, the Intel APIs do expose some objects allocated
is presented in the next section. on their private heap to the outside Rust world. One example
4 SECUREBINDINGBETWEENRUSTAND is sgx_sha256_init. This C/C++ API returns an allocated and
initialized SHA context state, which can later be reclaimed by the
C/C++ Intel SDK through a pairing API, i.e., sgx_sha256_close. This
Asourlayereddesignof Rust-SGXconsistsofcodewritteninboth opens a loophole that allows the Rust code to corrupt the C/C++
C/C++ and Rust, it naturally raises the question of how we can heap, which thus must be mitigated in the design of Rust-SGX.
securely bind the two worlds together. Since the memory safety of TherearetwopotentialproblemswhenaccessingC/C++heapvia
C/C++andRustrelies on different security invariants, an arbitrary Rustcodeifthebindingisinappropriatelydesigned.Thefirstisthat
combinationofthetwoworldscannotbeguaranteedtobememory the Rust code may be able to manipulate the internal states of these
safe. Therefore, we must add additional enforcement of how the objects which are supposed to be hidden. We demonstrate that this
twoworldsinteract with each other to assure that the two different concern can be resolved by introducing type safety enforcement,
language constructs are securely bound. which will be explained in ğ4.2. The second problem is directly
Note that previous research has investigated how to achieve relatedtothememorymanagement,i.e.,theRustcodemaycontinue
memory safety in the context of the manner in which a safe to operate on a C/C++ heap object after it has been freed, leading
language interacts with an unsafe one. In particular, Tan et al. [32] to memory errors such as use after free or double free. To deal
2336
no reviews yet
Please Login to review.
