Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files .manifest and .manifest.sgx have the same contents #1990

Open
dimakuv opened this issue Sep 2, 2024 · 3 comments
Open

Files .manifest and .manifest.sgx have the same contents #1990

dimakuv opened this issue Sep 2, 2024 · 3 comments
Labels
enhancement New feature or request P: 2

Comments

@dimakuv
Copy link

dimakuv commented Sep 2, 2024

Description of the feature

After #1812, auto-generated files .manifest and .manifest.sgx have the same contents.

This is because with #1812, the lists of sgx.allowed_files and sgx.trusted_files are used by all PALs (previously they were only used by the SGX PAL). So after #1812, there are no SGX-only-specific manifest options in Gramine; all options are expanded already during the gramine-manifest step which outputs the .manifest file.

So .manifest.sgx is just an exact copy of .manifest file, and thus can be removed.

This issue was extracted from discussion https://reviewable.io/reviews/gramineproject/gramine/1812#-NsxaGCgDVTu-TjSQWHx

Why Gramine should implement it?

Having one less file to deal with more user-friendly.

@woju
Copy link
Member

woju commented Sep 5, 2024

I'm thinking how technically this should be done, to break as little stuff as possible.

Quick summary of current state of affairs (plz correct me if I'm wrong):

  • gramine-sgx-sign has --output <app>.manifest.sgx and --sigfile <app>.sig options, and currently --output is mandatory and --sigfile is optional and defaults to the stem of manifest filename + .sig.
  • gramine-sgx <app> itself accepts app name and appends .manifest.sgx automatically (gramine-direct appends .manifest, without .sgx)

WRT gramine-{direct,sgx}:

  • in the first step we can make gramine-sgx "autodetect" the file, by first looking for the file as given if present (without appending any suffixes), then .manifest.sgx file if present, and if not present, then look for .manifest;
  • in the next step we can reverse the lookup, first look into .manifest and if it doesn't parse (like if it hasn't unrolled trusted_files or so) then try .manifest.sgx.

WRT gramine-sgx-sign:

  • in the first step we make --ouptut optional (and marked as deprecated): if not given, .manifest.sgx is not created at all
  • in the second step, --output option is removed and is a hard error.

I'm not sure how those should be braided together.

Random thoughts:

  • There're still two files that are needed to start gramine(-sgx): .manifest and .sig. Can we invent a new file that will contain both? Like, prepend hex-encoded sigstruct to the manifest, with PEM-style -----BEGIN SIGSTRUCT-----/-----END SIGSTRUCT-----, and launch that?

@mkow
Copy link
Member

mkow commented Sep 5, 2024

There're still two files that are needed to start gramine(-sgx): .manifest and .sig. Can we invent a new file that will contain both? Like, prepend hex-encoded sigstruct to the manifest, with PEM-style -----BEGIN SIGSTRUCT-----/-----END SIGSTRUCT-----, and launch that?

It won't parse as TOML then, so it will be annoying to use w.r.t. syntax highlighting. Also, SIGSTRUCT depends on the exact manifest contents (it hashes it), which sounds bad for this design: we'd need to split the file somehow and be very strict and precise about what goes where. I.e. IMO annoying to both implement and use.

@dimakuv
Copy link
Author

dimakuv commented Sep 10, 2024

Also, SIGSTRUCT depends on the exact manifest contents (it hashes it), which sounds bad for this design: we'd need to split the file somehow and be very strict and precise about what goes where. I.e. IMO annoying to both implement and use.

+100 here. It's better to keep manifest and SIGSTRUCT as two independent files, where the latter's MRENCLAVE value depends on the former's contents.

One more reason to keep these files separate: Intel SGX is probably the only HW TEE technology that requires something like SIGSTRUCT. Intel TDX and AMD SEV do not require such a file -- they fully rely on remote attestation (and don't have file sealing, for which this SIGSTRUCT requirement was originally implemented in SGX). So, SIGSTRUCT would become useless in e.g. gramine-tdx. Moreover, the whole gramine-sgx-sign tool would become useless for Intel TDX and/or AMD SEV.

@dimakuv dimakuv added enhancement New feature or request P: 2 labels Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request P: 2
Projects
None yet
Development

No branches or pull requests

3 participants