Description of the problem

SGX key derivation gets SVN fields in the request (ISVSVN, CPUSVN and CONFIGSVN). This mechanism provides backwards compatibility and anti-rollback protection as follows:

1. Each combination of SVNs generates a different key
2. If all SVNs are less or equal the values of the currently running enclave, a key is returned
3. If at least one SVN value is greater than the currently running enclave, key derivation fails

Current implementation of sgx_get_seal_key() uses the current enclave's SVNs (ISV, CPU and CONFIG) in a hardcoded manner. Consequently, Gramine does not provide backwards compatibility mechanism: if the enclave or the platform were updated, previously sealed blob will no longer be accessible.

This is problematic not only for user code, but could also break backwards compatibility of protected filesystem: if a file was written with one combinations of SVNs, it will no longer be accessible after they were changed (scenario and expected vs. actual results are below).

I think the following changes will be required:

1. Protected file format: the file's header will have to include either the entire key request or selected parameters (SVNs are required, but other fields may be needed as well)
2. Adding some more parameters to sgx_get_seal_key() may be needed (either all or some of the key request parameters). PalGetSpecialKey() may have to be modified as well, but I'm not sure if and how
3. What should happen if data is written into a file that was protected with older SVNs? Writing with the old SVNs is a security concern, because in that case potentially vulnerable enclave/platform may disclose the new data. Re-encrypting the entire file may be a significant performance impact, but it happens only once per SVN upgrade

Steps to reproduce

Setup:

1. Create two enclaves: enclave A with ISVSVN=1 and enclave B with ISVSVN=2, such that both enclave access the same protected files and both are signed with the same key
2. In both enclaves, mount the protected filesystem with MRSIGNER-based key
3. Write file X with enclave A
4. Write file Y with enclave B

Test flow:

1. Enclave A: read file X
2. Enclave A: read file Y
3. Enclave B: Read file X
4. Enclave B: Read file Y

Expected results

1. Success
2. Fail
3. Success
4. Success

Actual results

1. Success
2. Fail
3. Fail
4. Success