gramine icon indicating copy to clipboard operation
gramine copied to clipboard

Files `.manifest` and `.manifest.sgx` have the same contents

Open dimakuv opened this issue 1 year ago • 3 comments

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.

dimakuv avatar Sep 02 '24 18:09 dimakuv

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?

woju avatar Sep 05 '24 09:09 woju

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.

mkow avatar Sep 05 '24 14:09 mkow

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 avatar Sep 10 '24 10:09 dimakuv