4. October 2022

[dimakuv]

Agenda

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

• TBD

(There were no agenda items, so Ying Liu discussed her issues with enabling enclave-cc in Gramine.)

Missing syscalls required for enclave-cc in Rust

Ying Liu is working on the enclave-cc project, enabling/porting it to Gramine. Original code is written in Rust.

There are several syscalls missing:

• utimensat (change file timestamps with nanosecond precision)
• symlink (make a new name -- symbolic link -- for a file)
• linkat (make a new name -- hard link -- for a file)

utimensat

BorysWoju: we should be fine with utimensat() implemented with low precision, not nanosecond one. That's because this is already happenning in current file systems -- they do not support nanoseconds and store timestamps with less precision anyway. So Gramine won't "break" anything by having lower precision.

Chia-Che: We should implement the whole family of utime/utimes/utimensat/... We should think about the security issues of implementing this family of syscalls.

Benny: the time is not trusted in SGX. So all the syscalls that relate to timestamps, these are basically not trusted. We should make it explicit to users?

• There was no proposal how to make it explicit exactly...

symlink and linkat

Chia-Che: regarding symlink and linkat, does the customer need to create the corresponding symlink on the host (outside of Gramine environment)?

• Ying: yes. The first independent Gramine enclave creates the file/directory hierarchy on the host, including soft and hard links, and then the second independent Gramine enclave consumes this hierarchy from the host.

Borys: We were thinking of implementing soft/hard links as just in-memory states, nothing on the host. But this doesn't satisfy Ying's use case: the links must be stored on the host FS, so that the first enclave creates the link and the second enclave "finds" this link and uses it.

• Borys: this is a big change and quite complicated. This wasn't in our plans.

UNIX Domain Sockets (UDSes) between unrelated Gramine instances

• Tried to hack it for gramine-direct and make it work: there is an instance_id that is used in the UDS name: /gramine/<instance_id>/pipename.
  • (This is an unrelated step to the "how to share the symmetric encryption key between two Gramine-SGX instances". The step Ying is probing is "how to connect two UDS sockets" in gramine-direct.)
• Ying says that when removing <instance_id> from the UDS (actually, any pipe) path generation, something breaks in the IPC helper thread.
  • Borys doubts that the IPC helper thread should be affected. Borys speculates that Ying may have confused two IDs: the "vmid" and the "instance id". The former is used in LibOS, the latter is used in PAL; they are not related in any way. Ying must check again.