6. December 2022

[mkow]

Agenda

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

• Discuss EDMM status and plans (already done on a separate call on Monday)

[monavij]

• Request from CCC to do an annual update on Gramine in one of the upcoming CCC meetings (Dec 15th, Jan 12th, Jan 26th or Feb 9th)

[mkow]

Meeting notes:

• CCC: We'll try Feb 9th, if it works for everyone.
• Discussed how to handle support requests and whether we should change anything. No changes planned, at least for now.
• Gramine compat testing tool / documentation:
  • Mona wants us to have some answer for people asking whether their app will work under Gramine or not, and suggests writing a tool.
  • @mkow: Such a tool is infeasible to write with any decent correct-to-wrong answers ratio:
    • Syscalls are a bad measure for anything, because we often support only a part of their functionality, and apps often have fallbacks to other Linux APIs if a particular one is not available.
    • @woju/@mkow: A lot of incompatibilities result from missing magic filesystem files (e.g. some entries in procfs). Looking at syscalls completely ignores this.
    • A better metric than syscalls are the Linux features/subsystems/APIs we support or not (e.g. anonymous shared memory), but there's no trivial way to tell which ones are used by user's workload.
  • @mkow: The only feasible approach is to just try the app under Gramine.
  • What if instead of writing such a tool we documented which syscalls are supported?
    • As above, people would use this list to quickly check whether their app can run on Gramine, and get results which are false.
  • @woju: ITL already tried using syscall metric in the past and it indeed turned out to be a bad idea.
  • @mkow's note from after the call] Users like syscalls as a metric because it's the only one easily available to them. But it's really a terrible metric to decide which app will work and which won't.
  • Proposed solution: We could create a Gramine wrapper (gramine-compat-test maybe?) which runs Gramine on a workload, but without requiring any configuration from the user - it would use an emphemeral allow-all manifest and just run real (but non-SGX) Gramine on the workload. Should be easy to implement and give very good quality results.