27. June 2023

[dimakuv]

Agenda

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

• Woju: situation around RHEL
• Anees: Alpine Linux glibc/musl discussion
  • Dmitrii: Created three proposals:
    • [Meson] Allow building with -Dglibc=disabled #1400 (assumes OS distro)
    • [Meson,CI-Examples] Don't create symlinks in Gramine runtime dir #1417 (unfortunately breaking changes)
    • [meson,tools] Introduce epid Meson option #1420 (introduce -Depid=enabled, fixes Alpine by disabling SGX attestation)

Misc

Dmitrii and Michal discussed file locking internal structs: POSIX uses struct flock to represent both requests (commands) and the lock state on the file. This is confusing. We decided to fix it later (after the flock PR), but rather soon.

Woju: situation around RHEL

RHEL distro is not free. However, RHEL source code for packages is open source, and was re-packaged in CentOS (this is called "downstream"). CentOS was nixed by RedHat couple years ago.

Two alternative distros replace CentOS: RockyLinux and AlmaLinux. They used the RHEL sources for packages, so these distros recompiled them and claimed binary compatibility with RHEL.

[ Digression: it's unclear what's the difference between Fedora and CentOS Stream now. ]

Last week git.centos.org was rewired to have sources from CentOS Stream (which is less stable and typically not recommended for production) instead of RHEL. Suddenly this repo is based on the upstream (CentOS Stream) and not downstream (RHEL) distro.

Woju: now I don't know what to say about RHEL support. We technically cannot claim compatibility with RHEL.

Woju: I don't know what AlmaLinux and RockyLinux plan to do. They have a fighting chance to stay RHEL compatible, e.g. by tracking RHEL bugzilla and applying the same patches, etc.

Woju: if we want to claim 100% compatibility with RHEL, then this could be the RHEL responsibility to maintain Gramine as an official RHEL package.

Anees: Alpine Linux glibc/musl discussion

Three proposals from Dmitrii:

1. [Meson] Allow building with -Dglibc=disabled #1400 (assumes OS distro)
2. [Meson,CI-Examples] Don't create symlinks in Gramine runtime dir #1417 (unfortunately breaking changes)
3. [meson,tools] Introduce epid Meson option #1420 (introduce -Depid=enabled, fixes Alpine by disabling SGX attestation)

Woju: all 3 proposals are problematic. We have three libcs in the system: Gramine-SGX itself is linked against system libc (because of the protobuf dependency). The other two libcs are inside Gramine: glibc and musl. MbedTLS, RA-TLS and SecretProv libs run inside Gramine; they are built against the system libc; there are also symlinks of these built-libs-against-system-libc into the "runtime/" directories with in-Gramine libcs.

Woju: what we're trying to do is an "OS distro" inside of Gramine. And the correct solution is to split our single package into multiple packages: one set of packages for Glibc, and one set of packages for Musl. What Dmitrii was doing is fighting Meson, which is a build system tailored for a single libc, and such efforts are doomed to be full of brittle hacks.

Michal: using multiple packages will make life of Gramine developers very hard. I would rather force Meson to allow building against different libcs.

Michal: the stuff that runs inside Gramine should be completely independent from the host. Think of Gramine as like a VM.

Decision for short term: We only allow one libc while building Gramine -- the system libc. I.e., it will not be possible to do -Dglibc=enabled -Dmusl=enabled. And this libc will be the same as the system libc.

This will require changes to meson.build but also changes to e.g. our testing infra:

• https://github.com/gramineproject/gramine/blob/master/libos/test/regression/meson.build#L211
• https://github.com/gramineproject/gramine/blob/master/libos/test/regression/tests.toml (this file is chosen when testing against Glibc)
• https://github.com/gramineproject/gramine/blob/master/libos/test/regression/tests_musl.toml (this file is chosen when testing against Musl)

UPDATE: Woju submitted a PR on this: #1427.

[woju]

• @woju: situation around RHEL (TLDR we might need to stop claiming support for RHEL proper, instead we can probably support AlmaLinux):
  • https://www.redhat.com/en/blog/furthering-evolution-centos-stream
  • https://lwn.net/Articles/935592/
  • https://news.ycombinator.com/item?id=36420259

[woju]

Rocky Linux meeting notes: https://etherpad.opendev.org/p/resf-rocky-linux-git-c.o-changes

[woju]

• AlmaLinux blogpost: https://almalinux.org/blog/impact-of-rhel-changes/
• Rocky Linux blogpost: https://rockylinux.org/news/brave-new-world-path-forward/

[mkow]

Red Hat stance on this: https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes.
From my side I don't see anything bad in their move and it seems we can still support RHEL without any problems, because it's still free for open source devs (see the link I pasted).

[aneessahib]

Can we conclude on the Alpine Linux /glibc/musl discussion