11. July 2022

[dimakuv]

Agenda

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

• What to do about our website redesign (and how to avoid Wordpress).
• Enrico Borello from Leonardo Cyber Security would like to have a MS Teams meeting (see mailing list).
• Testing Gramine docker images: https://hub.docker.com/r/gramineproject/gramine
• Tracking dynamic PAL memory in LibOS [RFC] PAL memory bookkeeping #741
• [ ] Support for Ubuntu 22.04; need also Intel SGX SDK/PSW packages to support 22.04

Opens

The Gramine Contributor meeting (aka Gramine core meeting) will most probably be moved to Tuesdays, same time (7am PST, 4pm CET). Rationale: Mondays are frequently skipped due to holidays, days off, etc.

What to do about our website redesign

• Michał reiterated his stance that the Gramine web-site doesn't need to have a complex and bloated backend like Wordpress. In general, the Gramine web-site must be written and running on something simple, robust and minimal so that the Gramine team can manage it ourselves (i.e., no complex dynamic engine like Wordpress).
• Eric suggested that he could bring the question about website maintainance in one of the CCC meetings. He noted that the Linux Foundation does not provide support for website maintainance.
• Mona mentioned that at the very least, the current Gramine web-site should be verified for typos, stale links, and incorrect information.

The general consensus seems to be that we still keep the old web-site, maintain it and clean it up (fix broken links, typos, etc.).

Testing Gramine docker images

Borys published a beta version of the base Gramine Docker image: https://hub.docker.com/r/gramineproject/gramine. It is an absolutely minimal distribution of Gramine -- contains only Gramine binaries on top of Ubuntu 20.04. This image can be used as a playground for new users to quickly try Gramine, or may be also used as a base image for production-ready solutions.

• Dmitrii tested this image, it works. Some comments follow:

  • Had to install several missing packages (apt install make gcc git), just to be able to compile and run a HelloWorld example under Gramine-SGX.
  • Had to install the Apport package (apt install apport), for the Python example.
  • All tested examples work fine, including the SGX remote attestation examples (ra-tls-mbedtls and ra-tls-secret-prov).
  • Ran this image like this: docker run --device /dev/sgx_enclave -v /var/run/aesmd/aesm.socket:/var/run/aesmd/aesm.socket --security-opt seccomp=unconfined -it --entrypoint /bin/bash gramineproject/gramine

• Dmitrii asked if we want to add a HelloWorld binary in this Docker image?

  • Rationale: this would make the steps to quickly check that Gramine works as expected trivial: start the Docker container and run gramine-sgx helloworld.
  • Borys and Michał strongly oppose. They do not want the minimal Gramine image to have some redundant/unused files just for the sake of quick testing. This is especially true if this Gramine image will be used as a base for production Docker images.
  • Borys and Michał instead prefer to describe all the required steps to build and run Helloworld in the README. Or in a Dockerfile that will generate a new image based on this Gramine image.
  • Decision: do not add the HelloWorld binary (or anything similar) to the Gramine image. Keep it minimal, and instead give instructions in the README/Dockerfile.

• Mona asked how to advertise this Gramine image.

  • Borys suggests to only offer this Gramine image when users explicitly ask for it. Rationale: the Gramine image has a fixed version of Gramine inside (currently v1.2), so the users will be tempted to never update and just keep using this image (that invariably will get stale with time). Instead, we should force users to update Gramine as soon as possible -- it is a security-related software after all, and requires frequent updates.
  • We will update our ReadTheDocs:
    • Rename the "GSC" page to "Container integration".
    • Change this page to contain two things: a link to GSC (as before), plus a link to the Gramine image on DockerHub.
    • TODO(Dmitrii). UPDATE: Done in [Docs] Change "GSC" page to "Container integration" #749

• Dmitrii suggested to install all SGX-software-infrastructure packages inside this Gramine image. This includes AESM packages, for both DCAP and EPID attestation schemes.

  • This way, there will be no need to expose the host's AESM socket to the Docker container (i.e., no need for -v /var/run/aesmd/aesm.socket:/var/run/aesmd/aesm.socket during docker run).
  • All SGX-software-infrastructure packages are known to run correctly inside the Docker environment, so there is no show-stopper.
  • The Gramine image must only need a Linux kernel supporting SGX -- which is any Linux kernel v5.11 or higher. The users should not be expected to install additional SGX stuff on their host.
  • TODO(Borys): update the Gramine image to contain all SGX packages.

• TODO(Dmitrii, Borys): write a README and put it on DockerHub.

Vijay's EDMM design and PAL memory

Vijay and Borys discussed the implementation of the VMA logic. The proposal is to remove all VMA tracking from the PAL layer and instead use upcalls into the LibOS layer. So the LibOS becomes a single point of memory management in Gramine, as opposed to the current scheme where PAL is pre-allocated some small chunk of memory for its own memory management, and the rest is given to LibOS. See the proposal here: #741

This "All VMA tracking in LibOS" proposal is a pre-requisite for most of the Vijay's EDMM work. Assuming we remove all tracking of VMAs from PAL, the initial version of EDMM support will not conflict with it (though it depends on it, in logical sense).

(Dmitrii didn't understand the discussion exactly, so this retelling may be slightly incorrect. If the text above is incorrect, Vijay and Borys will comment on it. Borys: updated the comment above.)

Misc

• Scott mentioned that support for Ubuntu 22.04 in Intel SGX SDK/PSW packages will arrive in the 4. quarter (Q4) of 2022.

• Borys asked how does GSC remove the intermediate layer/image that contains the signing key.

  • GSC has a trick for it.
  • However, is it possible that this intermediate layer (before the FROM keyword) still contains the signing key and still exists in the layering of the final "graminized" Docker image? In this case, docker push will also send this intermediate layer with the signing key, breaking all confidentiality guarantees of the key.
  • TODO(Dmitrii): must check the metadata and layering of an example GSC Docker image and report the results. UPDATE: Done, see comment below.

[dimakuv]

TODO(Dmitrii): must check the metadata and layering of an example GSC Docker image and report the results.

Done.

1. The signing key is not in any trace of the GSC image, so we're good. The trick of FROM works.
2. I analyzed the layers via docker history --no-trunc gsc-ubuntu18.04-bash.
3. I analyzed the contents via dive gsc-ubuntu18.04-bash.

[mkow]

Michał reiterated his stance that the Gramine web-site doesn't need to have a complex and bloated backend like Wordpress

It's not only about this, but about Wordpress being huge and complex software written in PHP.

[dimakuv]

I deliberately removed that part about PHP, not to offend anyone :)

[mkow]

How is it offending? It's a broken technology, especially in terms of security.

[mkow]

Also, that omission actually changed my argument - if it was written in another technology then it wouldn't be as bad as it is now and I might have agreed to using it.

[dimakuv]

It's a broken technology, especially in terms of security.

Well, many people find this statement offending :)

[mkow]

Well, many people find this statement offending :)

[citation needed]

Also, I'm not offending anyone, I'm offending a badly designed technology (which is objectively broken in terms of security).