gramineproject / gramine

A library OS for Linux multi-process applications, with Intel SGX support
GNU Lesser General Public License v3.0
596 stars 197 forks source link

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

Open dimakuv opened 2 months ago

dimakuv commented 2 months ago

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 commented 1 month ago

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):

WRT gramine-{direct,sgx}:

WRT gramine-sgx-sign:

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

Random thoughts:

mkow commented 1 month ago

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 commented 1 month ago

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.