6. February 2024

[dimakuv]

Agenda

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

• Dmitrii and Mona: optional section in the GitHub Issues template for people who would like to share additional information (motivation and user stories)

  • Example from Kubernetes Enhancement Proposals: https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md
  • Example from Debian popcon: https://askubuntu.com/questions/57808/what-is-the-popularity-contest-package-for and https://popcon.debian.org/

• Mona: Allow to use older CPUs again (disallowed due to sgx.use_exinfo requirement to fix the security vulnerability)

  • Some customers complain and have to stay on v1.5.
  • Michal and Mona agree that we can implement a new manifest option sgx.insecure__allow_no_exinfo at least for some time (until old CPUs fade away). This way older CPUs can be still used for debugging purposes.
  • Related issue: Workloads requiring memfault handling are failing on Old Intel CPUs which does not have exinfo support #1587
  • UPDATE: proposed fix: [Pal/Linux-SGX] Add sgx.insecure__allow_memfaults_without_exinfo manifest option #1744

• Dmitrii: Gramine release v1.6.1 with dependencies' updates

  • We already merged an update to Curl that had a couple vulnerabilities (not affecting us directly, but better be on the safe side)
  • We now have mbedTLS vulnerabilities
    https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-01-1/ -- should affect Gramine (or more specifically, RA-TLS libs)
  • https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-01-2/ -- should affect Gramine (or more specifically, RA-TLS libs)
  • There is a new glibc release that fixes vulnerabilities: https://lists.gnu.org/archive/html/info-gnu/2024-01/msg00017.html
  • Plus we have a couple other things that some clients are waiting for.
    • In particular this: [Pal/Linux-SGX] Add sgx.insecure__allow_memfaults_without_exinfo manifest option #1744
    • [common] Introduce pre-allocated node free list for encrypted files #1723, which is also waited by some clients.

• Kailun: OpenSSF Best Practices Badge

  • Kailun started working on this process for Gramine

• Dmitrii: new memory allocator for Gramine?

  • See discussions in [common] Introduce pre-allocated node free list for encrypted files #1723
  • Crux: we have a very old slab memory allocator in Gramine, it doesn't have any optimizations, so we introduce micro-optimizations in specific parts of the codebase (like PR above)
  • Q: how do we proceed?

Misc: New web-site

Woju: Linux Foundation (LF) folks mentioned the Hugo framework that will be hosted on GitHub Pages. This is more desirable for us, as it uses static pages (and not WordPress).

• Michal: if we have something on GitHub Pages, it will be easier to take over if someone/LF leaves or is unresponsible (typo: unresponsive).
• Woju: Hugo is the rendering framework, GitHub Pages is the hosting site.
• Don: what is meant by "maintenance", as LF means it?
  • "Maintenance" means creating content after the original web site design and contents is filled.

Conclusion: everyone seems to agree to prefer Hugo + GitHub Pages instead of WordPress, even at the cost of maintaining ourselves.

Mona: optional section in the GitHub Issues template for people who would like to share additional information

Mona wants to ask people how they use Gramine, where they come from (university, startup, hobby project, etc.).

• Currently we don't ask.
• What is the GitHub / Open Source etiquette?
  • Michal: we already have the "Rationale" in GitHub Issues, Feature Request sub-type (but this is not "social" but rather "technical").
  • Woju: the answer in these GitHub Issues will be technical, not community-based or social. GitHub is not a good venue to ask such questions (only technical ones).
  • Woju: ideally there should be other community communication means. Some kind of promotion, maybe an online mini-summit. Gramine needs to build a community, where such social questions can be asked.
  • Woju: GitHub Discussions are also not good, as they are supposed to be technical, and such questions are again off-topic.
  • Woju: projects typically have a Community Manager. This person should at least point to appropriate docs. So it should be someone very familiar with Gramine.
  • TODO: Mona will write a message on Gitter channel. DONE.
  • TODO: Woju to greet people on the Gitter channel, when they start writing (not when joining, that's too intrusive).
  • TODO: Dmitrii will create a template for GitHub Discussions, to say that "optionally, you can introduce yourself on our Gitter".

Dmitrii: small Gramine release v1.6.1 ?

• Kailun: votes yes.
• Mona: votes yes.
• Woju: should this be release v1.6.1 ot v1.7? This is important for people who pinned their OS repos to "1.6".
  • Dmitrii: there are no big features, so we can do v1.6.1.
• Dmitrii: updating Glibc, mbedTLS. No Sphinx update.
• Michal: votes yes.
• Mona, Michal, Kailun: agree on adding [Pal/Linux-SGX] Add sgx.insecure__allow_memfaults_without_exinfo manifest option #1744 too.
• Kailun: also wants [common] Introduce pre-allocated node free list for encrypted files #1723.
  • After discussions: actually can ignore this PR.

Kailun: OpenSSF Best Practice Badge

Kailun started this badge acquiring process. There are 3 levels of the badge: basic ("passing"), silver, and gold. For certification, sections must be filled with short answers. It is a self-certification. Status: completed the "basic" level.

• Do we want to proceed with other levels? Silver or Gold.
• In our README, we can point to this badge.
• Decision: go with Silver, if there are no big roadblocks.

Dmitrii: new memory allocator for Gramine?

• Michal: try to add a new SLAB_LEVEL to cover 4KB-sized objects. The current allocator already has a free list design.
• Don: The allocator is not optimized for page-aligned objects, because it itself has some metadata, so there will be significant (?) memory waste.
• Don: need to quickly implement and measure performance.
  • DONE by Kailun here: [common] Add encrypted-file-node-size slab into slab allocator #1763
  • However, this seems too ad-hoc, see discussions here: [common] Introduce pre-allocated node free list for encrypted files #1723 (review)
• Chia-Che: for long-term, we need to investigate different allocators and their trade-offs.

[mkow]

Michal: if we have something on GitHub Pages, it will be easier to take over if someone/LF leaves or is unresponsible.

I meant unresponsive, not unresponsible ;)

[dimakuv]

My bad, fixed it.