Lecture: SGX
administrivia
- demos this Thursday, in class, ~15min each, camera crew, test your laptop
- final project report due next Monday
overview
- virtualization in this course: CPU, memory, I/O
- user/kernel & containers
- guest/host
- other usages
- repurposing VMM instructions for OSes: Dune, Hyperkernel
- client architecture: Embassies
- side channels: Meltdown
- goal: isolated execution environments
- applications: security
- tenants in cloud settings
- content protection in client settings
- what exactly does this mean
- is memory isolation enough - OS/hypervisor already provide that
- shared data may leak information, too
- noninterference from last lecture
- assume no shared pages
- informally
- user processes shouldn’t be able to interfere with each another
- guest virtual machines shouldn’t be able to interfere with each another
- more formally
- secrecy: others shouldn’t be able to infer the behavior of a given environment
- integrity: others shouldn’t be able to influence the behavior of a given environment
- non-goal: liveness
- only safety
- OS/hypervisor can do DoS attacks
- other goals
- how to read tech docs
- consider non-tech issues: business model, compatibility, etc.
- how to implement isolated execution environments
- one approach: carefully design & implement your OS/hypervisor
- challenges
- implementation may have bugs
- complexity: lines of code of the Linux kernel?
- OS interface is too wide
- idea
- separate out a minimal reference monitor (RM) for isolation
- untrusted OS/hypervisor on top of the RM
SGX
- architecture
- environments (“enclaves”) / OS & hypervisor / RM
- hardware (microcode) RM implementation
- Intel SGX
- CPU implements the RM
- more on other proposals in the end
- threat model
- RM is trusted
- OS & hypervisor can be compromised
- other enclaves can collude (with each other and with OS & hypervisor)
- assume no side channels (timing, cache, etc.)
- end-to-end security: no need to trust anything between app and CPU!
- multiple goals
- memory encryption (defense against physical attacks), attestation, etc.
- we focus on isolation today
- strawman: put an entire OS into the CPU
- too complex
- how to achieve isolation on top of the OS without trusting it
- idea: make untrusted OS construct enclaves
- an enclave shares the page table with a process
- why is this safe?
- what are the consequences?
- use special instructions
- CPU has to define what means to be enclaves - compared to processes
- special memory region: Enclave Page Cache (EPC)
- ECREATE: create an enclave
- EADD: add threads & pages
- with va->pa mapping - will be used later
- “seal” after construction
- how to check it’s constructed as intended?
- attestation: hash operations/content and sign
- EEXTEND & EINIT
- what’s the key for signing?
- idea: make sure untrusted OS cannot make changes to sealed enclaves
- enclave execution is restricted
- cannot invoke syscalls and many other instructions (e.g., cpuid)
- any exception/fault will cause an exit
- enclaves can actively invoke EEXIT (compared to syscall/vmcall)
- what if the OS tries to change the page table
- can OS directly write to an enclave - no, CPU not in enclave mode
- can OS swap pages between two enclaves - no, ownership is recorded in EPCM
- can OS swap pages within an enclave - no, va->pa mapping is recorded in EPCM
- what about interrupts & exceptions
- need to save registers - what & who & where
- how to hide register values
- how to restore registers
- what about DMA: protected by memory controller
- more complex issues
- page eviction
- multithreading
- attacks & security issues
- very complex spec: see Chapter 40 (SGX Instruction References) of Intel SDM
- bugs in enclave code
- channels: page fault, timing
- other proposals
- SGX2: dynamic memory management, library OS support
- AMD’s Secure Encrypted Virtualization (SEV)
- separate memory encryption engine
- TrustZone
- demos