lsds
Enclave configuration defaults
When the enclave configuration is read from EEID, we may decide not to require all settings to be specified in the EEID, so that the enclave will fill in the missing settings with defaults. We do not currently have a decision on whether we want this filling-in of details inside of the enclave, or on the outside, by the launcher, such that the EEID config is always fully specified.
There are good reasons for either, but we need to decide on one of them.
Pro full specification: simplified parsing, easier to review for security, easier to predict. Pro partial specification: smaller config, more user-readable.
Personally, I prefer a complete specification of all options because it greatly simplifies code security reviews and there is no guess-work as to which default value a particular enclave uses, but your views may differ.
CC @prp @letmaik
There are actually three options:
Full specification (EEID = full specification) Partial specification & host-filled (EEID = full specification) Partial specification & enclave-filled (EEID = partial specification)
Right?
Yes, that's right. My main concern is the EEID config, but the things passed to the host/launcher may also be partial (as it is today).
-
I believe that we need to have defaults inside the enclave because an SKR policy that doesn't mention a particular app_config value needs to (implicitly) endorse the default value through the specified MRENCLAVE.
-
If the app_config as part of the EEID isn't complete, an SKR policy can only refer to the values mentioned. The problem with making the app_config in the EEID complete is that we would have to handle the case when that app_config overrides default values, which must then be accepted explicitly by the SKR policy.
This probably requires a longer discussion.
Yes, this definitely requires more discussion!
An SKR policy can always refer to values that weren't mentioned, but it would mean that the SKR service needs to know those defaults, so it can fill them in too (or similarly, the attestation service would have to fill them in before it goes to the SKR service). I think that would turn into a bit of a mess when different versions of all services use different defaults.
If we (the launcher and similar) fills them in, then at least everything downstream won't have to know those defaults.
(Another thought, but probably not the right thing to do: what I did in my current experiments (out of laziness) is to initialize everything to 0/null/memory containing only zeroes. That would make guessing easy, and it wouldn't change between versions, but the default settings would likely be useless for some of the settings.)
From our offline discussion, the current consensus is that the sgx-lkl-cfg tool would fill in defaults during canonicalization, while the launcher would not modify this JSON blob any further. Inside the enclave, any missing fields have to be filled in with default values (this may happen when updating SGX-LKL introduces new fields and the app/config/policy wasn't re-deployed). The general idea is to make runtime parameters as predictable as possible from a user perspective.
As part of triaging, it was decided to leave this as a p1 for now until it is determined if this is a security risk or not. If there is no risk, this should be revisited and lowered in priority.
