Lecture: Haven

Shielding Applications from an Untrusted Cloud with Haven, OSDI 2014

Questions

Question

In SGX, how does the CPU protect enclaves from an adversarial OS? Specifically, imagine the following scenarios: (1) the OS tries to directly read/write the memory of an enclave; (2) the OS maps an EPC page into multiple enclaves; and (3) the OS swaps the virtual addresses of two EPC pages within the same enclave. Note that the OS has the full control of the page table. Briefly describe how SGX prevents these scenarios.

Section 5 of Intel SGX Explained describes SGX in more details. This is FYI; you don’t need to read it.

Question

Compared to POSIX (or the interface exposed by an exokernel), do you think Haven’s untrusted interface (Figure 3) is better for protecting against Iago attacks? Use one example to explain why or why not.

Question

What are the main drawbacks of Haven? Can you think of possible hardware/software changes to mitigate them?

Question

Provide a list of questions you would like to discuss in class. Feel free to provide any comments on the paper and related topics (e.g., which parts you like and which parts you find confusing).

isolated execution
- “unusual” threat model
  - deviate from the protection rings model
  - apps run on top of untrusted OS/hypervisor, with a shortcut to a trusted CPU
  - designed to be resilient to physical attacks: memory encryption against DRAM bus tapping, unclear about addresses or interactions with other parts
  - information leak: page-table bits, CR2, timing - see Foreshadow
- applications
  - mobile security
  - cloud computing
  - malware
  - proprietary algorithms
  - digital rights management (DRM)
- examples
  - earlier systems: TPM, Overshadow, TrustVisor, InkTag, ..
  - x86: Intel Software Guard Extensions (SGX), AMD Secure Encrypted Virtualization (SEV)
  - ARM: TrustZone, Komodo
  - RISCV: Sanctum, Sanctorum, Keystone
- today: Haven
SGX
- CPU (trusted), OS (untrusted), app (split)
- ISA extensions
  - a set of instructions for both the OS and enclaves
  - partition memory into EPC (enclave page cache) pages
  - maintain EPC metadata (EPCM)
  - one more CPU mode: enclave mode (ring 3)
    - EPC pages are accessible only when the CPU is in enclave mode
    - EPC metadata is modified through SGX instructions
    - enclave entry/exit
- lifecycle
  - enclave developers sign an enclave - where is the key from?
  - the OS constructs an enclave & the CPU computes a measurement hash
    - the OS allocates memory, creates threads, initializes data/code
    - example: the OS creates an empty enclave
      - the OS passes in a free EPC page to the enclave - why the CPU doesn’t search for one itself?
      - how does the CPU ensure the page is free? EPCM
  - example: the OS adds one page/thread to an enclave
    - what should the OS pass in? a free page and an existing enclave page
    - how does the CPU ensure it’s an existing enclave page? EPCM records the type of each EPC page
  - the OS is untrusted - who makes sure it creates the “right” enclave?
  - what goes into the measurement? think how git works
  - the OS “seals” the enclave
    - can the OS still add/remove pages? no change after this step (unless the enclave explicitly acks in SGX 2)
    - can the OS read/write EPC pages? no - the CPU is not in enclave mode
  - the OS enters the encalve
    - remember the OS still controls and can modify the page table at this point
    - how does the CPU know the OS is not mapping a page that doesn’t belong to this enclave? EPCM records the owner enclave of each EPC page
    - how does the CPU know the OS is mapping a page to the correct virtual address? what if the OS swaps two EPC pages? EPCM records the virtual address for each EPC page
    - when does the CPU perform these checks?
    - what instructions can the enclave use?
      - a strict approach: anything that OS/hypervisor may trap
      - SGX 2 relaxes some - trade-offs?
  - the enclave exits to the OS
    - what about exceptions, interrupts, and active enclave exits?
      - what registers should the CPU save/clear?
      - example: page faults - what about %CR2?
      - example: timer interrupts - what’s the implication as the OS controls time?
      - example: EEXIT - what should the CPU do?
  - the OS stops and reclaims the enclave
    - how does the CPU make sure the OS has freed all pages of an enclave? why?
    - what does the EPCM has to track?
  - many more complex details: attestation, eviction, concurrency
- performance implications
  - what’s the overhead of enclave entry/exit? what does the CPU have to flush/save/restore?
  - think how to implement demand paging inside an enclave - how many transitions?
  - what arch changes you would propose to make this faster? why intel didn’t do this?
- analogy: exokernel, libOS, app
  - consider the SGX instructions as an exokernel interface
  - how would an “exokernel” CPU manage resources
  - apply this to look at other designs such as AMD SEV
untrusted interface design
- SGX doesn’t address what application code should be like inside an enclave
- what should the interface be like between an enclave and the outside world
- what’s the assumption?
- why not POSIX? can it be secured?
  - example: create a file, write data, and read back
  - what invariants the enclave has to check?
- what about Haven’s interface? is library OS the right interface?