20. August 2024

[dimakuv]

Agenda

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

• Dmitrii & Kailun: Encrypted files recovery feature missing in Gramine
  • Client problem: Write-Ahead-Log (WAL) file cannot be opened because some part of wasn't updated (the app crashed in the middle)
  • Dmitrii's idea: truncate the suffix of the corrupted file until the file is fully readable. Probably no way to justify its security though...
  • Kailun's explanation: Intel SGX SDK has a rather complex file recovery mechanism, with a second "shadow" file: https://github.com/intel/linux-sgx/blob/c1ceb4fe146e0feb1097dee81c7e89925443e43c/sdk/protected_fs/sgx_tprotected_fs/file_init.cpp#L421-L441

Misc

Woju: after vacation, looks to stabilize our Jenkins CI

Reanimated some nodes. Will continue working on Ubuntu 24.04; CI may stop working for a couple days. What's the best time to do this?
Dmitrii suggests starting from Wednesday evening, after another Gramine meeting.

Dmitrii: new iteration of the SGX driver bug fixes

Here: https://lore.kernel.org/all/20240821100215.4119457-1-dmitrii.kuvaiskii@intel.com/

Dmitrii & Kailun: Encrypted files recovery feature missing in Gramine

Quick summary: Dmitrii's approach was to try to read the prefix of the encrypted file. But this is not even possible as we have a Merkle tree, so the whole file's root MAC would be wrong anyway (i.e. no prefix is possible). Kailun explained Intel SGX SDK's design for recovery (with a second "recovery" file that has a dump of the cached file blocks, and the main file temporarily points to this recovery file until its own contents are fully dumped).

Decision: Intel SGX SDK's recovery code must be ported to Gramine. Kailun's team can work on this, but after the v1.8 release.

TODO: Ask Michal if he is Ok with the security of the Intel SGX SDK approach.