6. September 2022

[dimakuv]

Agenda

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

• No agenda, discussed random things

/etc/ emulation and Gramine release date

First there was an update on /etc/ emulation plus some discussions from Dmitrii, Borys, Michal, Mona:

• Dmitrii, Borys, Michal did a quick recap of discussions and ideas from RFC: Sanitization of /etc/ files #689
• Some additional details can be found in the now-closed first-attempt PR First iteration of etc passthrough #850
• There is a new iteration of this work, with /etc/resolv.conf emulation: [LibOS,PAL] Introduce etc emulation (currently only 'resolv.conf') #889

The release date was supposed to be in mid-August. We hoped to include /etc/ emulation in this release. But as it stands, it will take at least 2 more weeks to finish.

/etc/ emulation tasks:

1. in-Gramine hostname must be initialized from host uname() syscall (no need to emulate /etc/hostname)
2. /etc/resolv.conf file (WIP: [LibOS,PAL] Introduce etc emulation (currently only 'resolv.conf') #889)
3. /etc/hosts file (maybe not, since it seems enough to have hard-coded contents that work for all reasonable platforms)

Borys notices this about Glibc's resolver:

• resolver uses /etc/resolv.conf -- without this file, nothing will work;
• at the same time, resolver wants to use /etc/hosts but won't fail with a hard error (but may fail in other, more subtle ways).
• So it looks like Gramine needs to expose /etc/hosts file, but maybe simply via fs.mounts + sgx.trusted_files options.

For the upcoming release, we can focus only on requirements from MS Azure VMs. Which means only /etc/resolv.conf should be enough.

Michal notices this about /etc/resolv.conf -- the parser is in the untrusted part, so this is not that critical during review. The real critical part is the representation in structs of the parsed contents. So maybe 2 weeks is enough for implementation + reviews.

We'll discuss whether we include this in the release v1.3 or not in another Gramine meeting.

Sankar's problems with MariaDB

We have an official Docker image with MariaDB. The entrypoint script additionally spawns a client that initializes the server (e.g., sets some initial password). There seems to be some Gramine-related problem with this client child process.

Interestingly, the Gramine version before the Big Sockets Rewrite worked fine.

Borys will set it up and repro. Borys thinks that MariaDB fails because it tries to set RECVTIMEOUT on a UNIX Domain Socket (UDS), and this particular functionality is not implemented in Gramine (since UDSes are emulated as pipes). Hard problem to solve if we want to preserve original semantics.

In general, Sankar thinks that we should have "curated Gramine-tailored Docker images", where we maintain a Dockerfile/Docker image that uses the original app Docker image as the base and tweaks it to be Gramine-usable (e.g., by replacing the ENTRYPOINT script/app).