23. April 2024

[dimakuv]

Agenda

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

• Woju/Jinen: Release and gramine-manifest-check tool #1726
• Michael Steiner (@g2flyer): Discuss [common] Encrypted Files: keep root hash for whole runtime of Gramine instance #1835
• Dmitrii: EDMM bug(s) in the SGX driver
  • Related to [LibOS,PAL/Linux-SGX] Add EDMM lazy allocation support #1513

Woju/Jinen: Release and #1726

Mona: at the other meeting (a week ago?), it was considered not yet fully reviewed so it was decided to move out to v1.8 (next-next release). However, this was not communicated to Woju and not updated in the open source roadmap of Gramine.

Jinen: there are two validation parts: first is testing applications from master branch, second is testing packaging (with light testing of applications). So the tool was not properly validated.

• Shama: we didn't do a proper validation cycle on this tool. Given time constraints, it seems unreasonable to include a not-so-important tool in the release.
• Jinen: ideally we want to test this tool on all applications that we have. Also, want to test this tool on negative scenarios.

Woju: what goes into the release and what not, is supposed to be decided (or clearly communicated) in the open-source meeting.

Mona: we can add this PR in the release, but it will not fail but only issue warnings.

• TODO(Woju): tweak the PR to change from errors to warnings. Michal and Dmitrii will review and merge. The new packages will be rc3.
• UPDATE: This was already done, PR was modified and merged.

Mona: we need to sync properly between the two groups, especially close to release dates.

• Mona, Dmitrii and Michal must pay special attention to any discrepancies between the plans/release items/deadlines.

Michael Steiner Discuss #1835

[ Michael Steiner shows a presentation ]

• Gramine's Protected/Encrypted Files provide basic rollback protection -- for a single file and only during the open and until close

• Propose phased approach:

  1. Single-process enclave-lifetime rollback protection (fork is allowed, but each protected file is accessed only by a single process)
  2. Extensions to multi-process (current limitations already prevent concurrent file access anyway, so we only need to solve the case of open-to-close windows not overlapping)
  3. persistent rollback protection (not Gramine problem to solve, but a third-party service)

• Phase 1 implementation:

  • struct libos_encrypted_volume which is a generalization of current encryption_key, associated with a FS mount point
  • this struct contains the map <filename, {last-seen-root-hash, file-status}>
  • during non-create open(), consult map if we've seen that file: if we did then root-hashes must match
    • on success update the map
  • during close(), map is updated with root-hash
  • during rename() and delete(): corresponding update to the map

• Michal: what will be the default mode for this? Currently for us it's like "non-strict" -- P2 can open the file created (and closed) by P1, even though it allows a rollback attack. If we choose the default to be "strict", then P2 will fail, and it is backwards incompatible.

• Michael continues presentation: multi-process will involve maintaining the struct in the process leader, and children always consult and update the leader via IPC. This is similar to file locking.

  • Michal: there is a current bug of the process leader exiting while child processes are still running; would be good to fix that before doing this new thing.

Dmitrii: EDMM bug(s) in the SGX driver

Dmitrii gave a quick explanation on two bugs found in EDMM flows of the SGX driver, and the current status -- both bugs are acknowledged by kernel devs, and the proposed fixes seem ok.

[mkow]

• Michal: what will be the default mode for this? Currently for us it's like "non-strict" -- P2 can open the file created (and closed) by P1, even though it allows a rollback attack. If we choose the default to be "strict", then P2 will fail, and it is backwards incompatible.

Small correction: I think what I said (or at least meant) was this: Currently for us it's like "non-strict" -- P2 can open the file created (and closed) by P1, and the "strict" mode will disallow this, even though there was no attack from the host. So, it's oversensitive and is not backwards compatible.

That "even though it allows a rollback attack" doesn't make much sense, right now we allow a multitude of replay attacks (but we limit them to a whole-file only).