27. February

[dimakuv]

Agenda

(please write your proposed agenda items in comments under this discussion)

• Dmitrii/Kailun: discuss design and implementation steps for [LibOS,Pal,common,tools] Improved protected files performance #1681

  • @mwkmwkmwk has some design ideas which need to be clarified
  • @dimakuv wants a prerequisite: move Trusted Files into LibOS and untangle current SGX-PAL-code mess
  • For discussion, need:
    • person representing Intel China (@yao-ji or @kailun-qin) -- both @kailun-qin and @yao-ji will participate.
    • person representing ITL (@mwkmwkmwk or @mkow)

• Dmitrii: Gramine-TDX presentation, plus deep dive into the GitHub repo: https://github.com/gramineproject/gramine-tdx

Misc: introductions

• Yao (@yao-ji) is from the Intel SGX validation team. Submitted PR [LibOS,Pal,common,tools] Improved protected files performance #1681; similar to Intel SGX SDK's Protected FS.

• Bobby (@BobbyAtFortanix) works for Fortanix. Had a fork of Graphene from 2016. Now are merging their patches back to Gramine.

• Marcelina (@mwkmwkmwk) works for ITL, a new developer / reviewer for Gramine.

Design and implementation steps for 1681

• mwk: we still need read/write callbacks where we'll encapsulate the SGX-specific copies.

  • The SGX-specific callbacks can't be in LibOS or in common code, so it should be in PAL.

• mwk: mmaped-backed untrusted-memory file logic will become more complex than Trusted Files, because Protected/Encrypted Files are not read-only but read-write and truncation.

  • mwk suggests to go with a series of building blocks. Only a small subset of those will be used for Trusted Files.

• mwk: how does file extension during ftruncate() work?

  • This must be encapsulated in SGX PAL, in the write callback (since the write callback can figure it out via offset).
  • We already have ocall_mmap_untrusted() and ocall_munmap_untrusted(), but mwk thinks we also need ocall_mremap_untrusted() for performance reasons.
    • host syscall mremap() must be called + host syscall ftruncate() must also be called; so the ocall should actually do two things.
  • Reallocation should be with some over-approximation (2x growth heuristic), for perf reasons.

• Dmitrii: Common Protected Files code must have the temporary buffer to encrypt/decrypt, and this temporary buffer is given to the cb_read()/cb_write() (ending up in PalStreamRead()/PalStreamWrite()).

• mwk: because we'll have memory-mapped files, we will need host-level msync(). The app wants to fsync(), this ends up in file_flush(), so we need msync() on the untrusted memory region.

• Dmitrii: now we change the "traditional File I/O" backend for Encrypted Files with the "Memory I/O" backend, with a completely different set of syscalls: memory loads instead of read(), memory stores instead of write(), mremap() instead of ftruncate(), msync() instead of fsync().

• Yao: needs to understand msync vs fsync more now.

• Kailun: this improvement got very big, and we may not have this improvement in time for the next release.

• Yao: for decryption (from untrusted memory to trusted memory), can we skip the temporary buffer? The rationale: the input is definitely not changed, so the attacker cannot steal any intermediate info.

  • mwk: no, we can't do it due to TOCTOU attacks (what if the decrypting logic in mbedTLS can touch the same bytes twice, and attacker has a window of maliciously modifying them).