16. January 2024

[dimakuv]

Agenda

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

• Dmitrii: discuss [Docs] Examples exception to the Charter #1670 and [CI-Examples] Change the license of all examples to BSD-3-clause #1657 (non-LGPL license for examples)

  • Some Intel folks are stuck on these legalities, and the discussion in [Docs] Examples exception to the Charter #1670 is going nowhere, need a bump

• Dmitrii: discuss [Python,CI-Examples] Hide loader.entrypoint manifest option #1716 and [PAL,LibOS] Use sys. for check_invalid_pointers and insecure__disable_aslr #1717 (user-facing renames/removals of manifest options)

• Dmitrii: Single-process eventfd design

  • Implemented here (in PAL): https://github.com/gramineproject/gramine-tdx/blob/intel_tdx/pal/src/host/vm-common/pal_common_eventfd.c
  • Also needs support in poll/epoll: https://github.com/gramineproject/gramine-tdx/blob/f4405d38d1a3b5e45146e25d07f589ab31d4e006/pal/src/host/vm-common/pal_common_object.c#L123-L141?plain=1
  • Q1: Only single-process implementation. Is this Ok?
  • Q2: Currently in PAL, looks like should be moved to LibOS. (Requires eventfd poll/epoll callback.) Objections?
  • Q3: keep the old untrusted passthrough implementation? I think yes, with a manifest switch and some warnings for users.
  • Beneficial in Memcached (eventfd is used to signal thread-to-thread, instead of UNIX signals or heavy-weight pipes).

• Dmitrii and Kailun: discuss the hard-coded limit on Protected Files in the LRU cache

  • Current limit (per file? I don't remember):

    gramine/common/src/protected_files/protected_files_format.h

    Line 103 in 1f72aaf

    #define MAX_PAGES_IN_CACHE 48

  • Can we make it a manifest option? How do we describe it (the trade-off) in our docs?

Dmitrii: discuss #1670 and #1657 (non-LGPL license for examples)

Conclusion: waiting on Michal to continue reviews.

Dmitrii: discuss #1716 and #1717 (user-facing renames/removals of manifest options)

Conclusion on #1716:

• No-one is against this PR. Woju is Ok. Chia-Che is Ok.

Discussions on #1717:

• Kailun: Deprecation is problematic. Isn't it more painful for users than such small incremental improvements?
• Woju: there are packages to validate schemas like our manifest syntax.
  • We can develop and embed such validation in our Gramine building tools (like gramine-manifest).
  • Then we can stick to the old names.
  • See Woju's comment below.

Dmitrii: Single-process eventfd design

Don: How to make sure this design is contained to single-process cases? Proposal: Fail by default on fork, but in manifest have an option to issue a warning/info message instead of failing.

Conclusion: the design seems fine (but Michal was absent, and he might have a strong opinion).

Dmitrii and Kailun: discuss the hard-coded limit on Protected Files in the LRU cache

We have three optimizations with caching of files:

1. Page cache for Protected Files (not to encrypt again): currently hard-coded limit, need to specify a manifest option.
2. Free list cache for allocations for Protected Files (not to allocate again): not implemented, but will need to also specify a manifest option
   • UPDATE: Kailun submitted the PR [common] Introduce pre-allocated node free list for encrypted files #1723.
3. Page cache for Trusted Files (not to SHA256 again): not implemented, but will also need a manifest option.

Conclusion: introducing the new manifest options seems fine (but Michal was absent).

[woju]

Comment after call to the discussion about #1717:

We can implement manifest linting by checking the dict that gets processed by gramine-sgx-sign and/or gramine-manifest. I know two approaches:

• Native Python module: python3-voluptuous. You construct a complex callable object that you can then call on arbitrary collection: https://alecthomas.github.io/voluptuous/; or
• JSON Schema. You write a JSON Object called "schema" to a express a set of specifications. Nominally those are expectations for another JSON Object, but you can apply those to any dict or list already loaded, very much like voluptuous
  • https://en.wikipedia.org/wiki/JSON#Metadata_and_schema
  • https://python-jsonschema.readthedocs.io/en/stable/

In practice JSON Schema is more verbose and harder to write, but also more interoperable. If we have expectation that people will apply this schema themselves using their own tooling (not only by gramine-sgx-sign), then we should write JSON Schema. If not, then using Voluptuous will be easier and faster.