24. October 2023

[dimakuv]

Agenda

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

• Dmitrii: stack traces, core dumps in production Gramine deployments, see Crash dumps and/or stack traces #1617
• Dmitrii: SGX SDK's libtSeal.a -- how to use in Gramine (in particular sgx_seal_data() and sgx_seal_data_ex())
• Mona: how to get a new (experimental) PAL into the Gramine project?

Dmitrii: stack traces, core dumps in production Gramine deployments

• Michal: Secure core dump is a bad idea. One could try to save this core dump into an encrypted file, but this is complex logic (and Gramine/app is already in a bad state, so it may glitch even more, and the core dump will be useless, not saved or in the worst case unencrypted/weekly encrypted).

  • Mariusz: encryption can happen in a static buffer, with some public key that is preloaded somehow in the app for this purpose.
  • Mariusz: FreeBSD has encrypted core dumps, see freebsd/freebsd-src@480f31c. Mariusz wrote a blog post: https://oshogbo.vexillium.org/blog/74/

• Michal: Stack traces (backtraces) is also a bad idea. First, they still leak the stack info. Second, for production code that is built in release mode, in practice it's hard to reconstruct the stack trace.

• Side note from Woju: if sgx.debug = false, then this enclave kinda lies to the remote attester that it's not debuggable -- it is, in a restricted form: anyone who has the encryption key can see the state of the app coredump/stack trace upon crash. This should be at least explained in a threat model/documentation.

  • Woju: SIGSTRUCT.SWDEFINED bit can be used to mark this special "encrypted coredump" capability. But also need to make sure this field is propagated somewhere inside SGX quote (so that the remote attester can learn this feature).

Dmitrii: SGX SDK's libtSeal.a -- how to use in Gramine

Everyone agrees that this feature is useful.

Options:

1. SGX SDK team writes a more self-contained libtSeal.a, and expects framework-specific wrappers to use different crypto libs (e.g. mbedTLS). SGX SDK team writes their own wrapper (for OpenSSL or whatever they use) and Gramine team writes our own wrapper (for mbedTLS).
2. Gramine team ports this library completely. This needs analysis of complexity.

• Note from Michal: Porting a security-sensitive library is a maintenance burden for Gramine team. Better to reuse the SGX SDK's library.

• Mona: there is a workaround. The app can generate arbitrary encryption keys, and then store these keys in a single "metadata" file that is encrypted by Gramine using the _sgx_mrenclave/_sgx_mrsigner key. On startup, the app reads this file (Gramine transparently decrypts it) and gets a set of keys to use.

  • This may help in certain use cases. But sometimes the actual SGX sealing capabilities are required too. So not a panacea.

Mona: how to get a new (experimental) PAL into the Gramine project

Michal: It's ok if it's in a separate repo (under the same github.com/gramineproject/ org), with disclaimers that it's experimental and not thoroughly tested/reviewed.

Everyone agrees with a fork (under the same github.com/gramineproject/ org). The fork will have a special branch "experimental-tdx" as the main branch. This is the development branch. We periodically rebase this branch to official Gramine's master. Put a huge warning in the README -- that it is not official and experimental.