class: center, middle # SCONE ### Secure Linux containers with Intel SGX --- class: middle # Agenda 1. Why build SCONE? 2. Architectural designs 3. Problems and solutions 4. Evaluation 5. Conclusion ??? - Walk through why we would want to build SCONE, which problems it tackles and threat model - Then we will have a look at potential architectural designs - Afterwards, we will have a look at the different problems that arise with the use of SGX and the threat model - The problems have been solved, so we want to have a look at their solutions - Using these solutions, evaluation data has been gathered, so we want to show it - Finally, I want to wrap up with the conclusion --- class: middle # Why build SCONE? - Microservices and containers - Problems of today - Threat model and SGX ??? - Today's applications and system architectures are moving towards microservices and containers. - They provide better performance than VM's, arguably not providing the same level of security - With the model of today, users must implicitly trust the cloud provider because applications implicitly trusts the operating system and everything below it. - This is a problem, as it increases both the TCB and the number of persons to be trusted (sysadmins and the bunch) - Tying this into the threat model, we have a threat model where we assume an adversary has full, root access to operating system, hypervisor or other software, as well as physical access. - This is where Intel SGX come into play, as it allow the creation of secure enclaves, which allow us to trust no code, as not even the operating system in ring 0 has access to the memory, or is able to alter the control flow. --- class: middle # Potential designs - Library OS - Minimal TCB - Untrusted system calls ??? - Earlier approaches, such as Haven has tried to cram an entire library OS into SGX, but this increases the TCB immensly, as well as inducing great performance overhead. - At the other end of the spectrum, we could minimize the TCB and by that account, we have the problem of defending the entrire interface provided by libc. - SCONE lies somewhere in the middle, not providing an entrire library OS, but still trusting libc, which is achieved by providing a shielding layer and not trusting system calls. --- class: middle # Problems - Performance overhead - System calls - Memory access ??? - Using Intel SGX, there is a significant performance overhead induced, which must be tackled. - It is necessary to quantify the overhead to gain knowlegde about what to expect. - Both system calls and memory access is expensive, and is crucial, which is why we benchmark them. ---  ??? - We can see that the enclave adds an overhead of an order of magnitude. - Performant system calls are paramount to the secure containers. ---  ??? - As long as the data fit into the L3 cache, there is very little overhead, but as soon as there are L3 misses, the overhead is up to 12x. - And with page faults, evicting pages from the EPC, the overhead is three orders of magnitude. --- class: middle # Solutions - Shielding - Threading - System calls ??? - Many, if not most popular services are built under the assumption that the underlying OS can be trused. - So files are stored in the clear - Communication does not always use TLS - Output to stdout/err directly - We want to shield the application from problems, so we provide multiple shields - Shields focus on preventing low-level attacks (OS kernel crontrolling pointers and buffer sizes) - Also ensuring the confidentiality and integrity of the application data passed throug the OS. - Three shields are made; transparent encryption of files, transparent encryption of communication with TLS, and transparent encryption of console streams. - SCONE supports an M:N threading model, using a scheduler within the enclave, in particular to make system calls more performant - Due to SGX limitations, SCONE implements asynchronous system calls, which in conjunction with the threading model and scheduler will reduce blocking time. --- class: middle # Evaluation - Setup - Application benchmarks - File system and system calls ??? - Different applications are tested, with standard glibc, SCONE with asynchronous system calls and SCONE with synchronous system calls - Both latency and CPU utilization has been tested - Furthermore, SCONE implements an ephemeral file system with the file system shield - Finally, we will see the number of system calls we are able to execute with the SCONE-sync and SCONE-async --- class: center, middle # Application Benchmarks ---  ---  ---  ---  ---  ---  ---  ---  --- class: center, middle # File System ---  ---  --- class: center, middle # System Calls ---  --- class: middle # Conclusion - Why SCONE? - Problems and solutions - Results ??? - We want SCONE because we currently trust too much in a system, and we could see something like SCONE allowing personal data to be stored and computed on where it earlier was impossible due to legislation. - Three major issues arose, I/O, tackled by the shield system, threading and system call performance, which are solved using asynchronous system calls and an internal scheduler - Finally, we see that using their benchmarks, they are able to retain relatively good performance, while ensuring the integrity and confidentiality of the container. --- # Performance overview  ??? Finally wrapping it up, with the normalized performance