On Tue, Apr 07, 2020 at 04:20:39AM -0500, Dr. Greg wrote: > This patch introduces the ability of the platform owner to > implement cryptographically controlled enclave initialization > policy. This functionality provides the platform owner with the > ability to use the identity modulus signature of an enclave > signer (SHA256 hash of the modulus of the signing key) to gate > access to enclave initialization, rather then simply relying > on discretionary access controls that are applied to the SGX > relevant device driver nodes. > > The following policy functionality is introduced in this commit: > > 1.) Control over which keys are allowed to initialize an > enclave. > > 2.) Control over which keys are allowed to implement launch > enclaves. > > 3.) Control over which keys are allowed to initialize enclaves > that have access to the PROVISION_KEY attribute. > > For each policy type a plurality of key signatures are allowed. > > Absent an intent by the platform owner/administrator to use > cryptographic initialization policies, this functionality does > not change the standard behavior of the driver, which is to > allow any enclave presented to the driver to be initialized. > > Cryptographic initialization policy is accessed through the > following three pseudo-files that are implemented by this patch: > > /sys/kernel/security/signing_keys > > /sys/kernel/security/launch_keys > > /sys/kernel/security/provisioning_keys > > Policy keys are registered with the driver by writing the identity > modulus signature to these files in simple hexadecimal format, ie: > > 0000000000000000000000000000000000000000000000000000000000000000 > > The current list of policy keys can be displayed by reading the > contents of the pseudo-files. > > In addition to a key signature, the following keywords are > accepted as valid entries for a policy file: > > clear > > lock > > The 'clear' keyword causes all existing entries in a policy list > to be deleted. > > The 'lock' keyword causes any further modifications or access to > a policy list to be denied. > > All of the policy code is implemented in a single file, policy.c, > with minimal impact to the driver at large. Since the calculation > of the identity modulus signature needed to program a launch control > register is effectively a policy decision, the code to compute the > signature was moved from the ioctl.c file to the policy.c file. > > In order to support a plurality of launch keys the code that > loops over initialization attempts was pushed downward into a new > function that is named as follows: > > sgx_try_init() > > Primarily to avoid excessive indentation that would otherwise be > needed in the sgx_encl_init() function. > > Signed-off-by: Dr. Greg Wettstein <greg@xxxxxxxxxxxx> Sorry, would have responded earlier but forgot to check the folder where fdm pulls mailing list email's. For shorter latency I recommend CC'ing. This comes down to the fact that we are not doing anything that would prevent doing something similar post upstreaming (e.g. add a new ioctl for token version of EINIT or whatever) but is not something that we want to include right now. It is an additional feature (like other features e.g. virtualization) /Jarkko
