16. May 2023

[dimakuv]

Agenda

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

• Dmitrii: new API in RA-TLS to extract additional data (in addition to /dev/attestation/quote)? Case in point: the JSON Web Token (JWT) sent back by Microsoft Azure Attestation, see [Integrations/azure] Add RA-TLS/SecretProv libs for MAA contrib#38

  • Proposal 1: simply use envvar like RA_TLS_MAA_JWT (no need for changes in core Gramine repo)
  • Proposal 2: extend ra_tls_verify_callback_results with a pointer to such blobs (needs changes in core Gramine repo)
  • Proposal 3: new RA-TLS API (function) to extract such blobs (needs changes in core Gramine repo)
  • (this is a continuation of discussion started on 25. April 2023)

• Dmitrii: removing support for Ubuntu 18.04 completely

  • We already removed 18.04 from our Jenkins CI
  • Do we want to proactively remove support in Gramine proper? This would include:
    • subprojects (mbedTLS patch)
    • documentation
    • Gramine codebase
    • Tests/examples
    • GSC
    • ...anything else?

• Dmitrii: Syscall entry point in Gramine and XSAVE preservation problem

  • See rwlock Libos Regression test fails on Ubuntu 22.04, Almalinux, Rockylinux, CentOS 9 #1352
  • See

    gramine/libos/src/arch/x86_64/syscallas.S

    Lines 14 to 19 in 4946a0b

    	* Note that LibOS may clobber all FP/SSE/AVX/... (extended) state except the control words. We rely
    	* on the fact that applications do *not* assume that this extended state is preserved across system
    	* calls. Indeed, the extended state (bar control words) is explicitly described as *not* preserved
    	* by the System V ABI, and though syscall ABI is not the same as System V ABI, we assume that no
    	* sane application issues syscalls in a non-System-V compliant manner. See System V ABI docs
    	* (https://uclibc.org/docs/psABI-x86_64.pdf), "Register Usage" for more information.

---

Benny: documentation reorganization PRs

Benny: 1 huge PR was split into several smaller PRs: 2 PRs already merged, 1 PR pending, then 1 more PR.

Woju: side note but the "linear commit history" decision is not working that well now. Woju votes for allowing merge commits. This is offtopic anyway, this discussion could be postponed for later.

Dmitrii: new API in RA-TLS to extract additional data

[ Dmitrii describes the problem as described in #1292 ]

Mona: this assumes that Gramine already got the JWT (token) from some peer/verifier. But how do we get the JWT from the peer in the first place?

Woju: What Dmitrii describes is that the token is the authentication credential that is used after the attestation, to gain access to some other resources.

Woju: Are there similar approaches to gain access to resources? Dmitrii: the only thing I know about is Edgeless Marblerun Premain trick; but this is only at startup and not generic enough.

Woju: I'd like to put things that are not part of the hardware contract/spec not under /dev/attestation/. So Woju would keep it outside of core Gramine.

Woju: we can have a switch for RA-TLS generation of X.509 cert: that it shouldn't hard-code SGX quote path /dev/attestation/quote but it can have any path. So this path doesn't need to be under /dev/attestation/, but it can be e.g. a tmpfs file /tmp/gramine/token, populated beforehand by the app itself or by the RA-TLS variant.

Mona: with Interoperable RA-TLS, we have an extensible format of the evidence inside the X.509 cert. So we could ask the Interoperable RA-TLS committee to add new evidence types like MAA JWT tokens. Then RA-TLS would need to also get the evidence type as the input (maybe a new function argument? or something like this).

Woju: we'd like to keep the RA-TLS general code (that is developed together with core Gramine) to be generic and usable by all those different plugins and verification schemes. So looks like we don't need changes in core Gramine, but need some generic changes to RA-TLS.

Dmitrii: Please check the Interoperable RA-TLS standard: https://confidentialcomputing.io/2023/03/06/unifying-remote-attestation-protocol-implementations/.

Removing support for Ubuntu 18.04 completely

Mariusz and Scott: can be aggressive and remove all the quirks of 18.04.

[mkow]

// I couldn't join the call so I only know what's in these notes.

Woju: side note but the "linear commit history" decision is not working that well now.

How is that related to this case? I don't see any connection. In that case someone just put 10 unrelated changes inside a single commit, it doesn't matter if we merged or rebased it.

[dimakuv]

I think it wasn't related at all. But something in our conversation triggered Woju to make his claim on the inadequacy of linear commit history. Maybe @woju remembers and could explain better.

[woju]

This was in response to general comment that the docs team has trouble cleaning up the reorganisation PR. There are three problems this PR have, one is sheer size, which is just what it is, second is splitting into commits (which needs to be done anyway, because that's good practice and allows to separately review separate concerns like moving vs editing), and the last one is this one, that it needs linear history. Maintaining linear history with the simultaneous frowning upon frequent rebasing makes it yet more problematic to maintain the branch especially if it's very big.

I've also said this is to be discussed after the docs reorganisation is done, not before.

[monavij]

On fully dropping Ubuntu 18.04 support, let's announce our plan on gitter channel to reach active users and see if anyone complains.

[dimakuv]

For me "stop maintaining 18.04 starting from 1.5" sounds right, but how do you define "aggressively dropping it" exactly? What if we merge something which accidentally breaks it?

I think we won't have anything like this. IIUC, Alpine changes could break this, but I haven't seen anything that would truly break Ubuntu 18.04?

Also, the meeting notes seem to indicate that you actually agreed to fully drop 18.04 (Scott and Mariusz in favor, no notes about any objections; I'm also in favor, I guess woju is also ;) ).

Yes, this happened on Tuesday meeting (where these meeting notes are from). But on another Wednesday meeting, we had some additional feedback that 18.04 should be tried to be kept in v1.5.

[woju]

I haven't seen anything that would truly break Ubuntu 18.04?

https://reviewable.io/reviews/gramineproject/gramine/1197#-NPI6meE9RlxjzPh27si

Last time I've checked this thread, we were okay with merging a thing that will traceback gramine-sgx-sign in the face of the user on 18.04.

[dimakuv]

@woju But this PR won't cut it into v1.5? At least we didn't slate it for v1.5 (which should happen quite soon).

[mkow]

I think it will, it's almost ready and I see no reason to artificially postpone it (especially not because of 18.04).

Btw. Why do we even care about such users? If they don't care about updating their distro, then why would they care about updating Gramine? They can use the old, unsupported Gramine releases same as they use old, unsupported Ubuntu. And actually nothing will actively break for them, apt update just won't pull Gramine 1.5 and stay on v1.4.

[dimakuv]

This conversation is at a dead-end :) Let's discuss it again during the Tuesday meeting, with @monavij giving her view on the Ubuntu 18.04 support decision...