Gramine uses hardcoded values for derivation of /dev/attestation/keys/_mrenclave

[szymek156]

You are probably aware of this
The keys mounted under /dev/attestation/keys/_mr* comes from here:
https://github.com/gramineproject/gramine/blob/2877640a06c5d14525ad1dc802860538ef4ea429/libos/src/fs/dev/attestation.c#L350

This code eventually calls this:
https://github.com/gramineproject/gramine/blob/2877640a06c5d14525ad1dc802860538ef4ea429/pal/src/host/linux-sgx/enclave_framework.c#L368

The problem is this part:

    key_request.key_name   = SGX_SEAL_KEY;
    key_request.key_policy = key_policy;

    memcpy(&key_request.cpu_svn, &g_pal_linuxsgx_state.enclave_info.cpu_svn, sizeof(sgx_cpu_svn_t));
    memcpy(&key_request.isv_svn, &g_pal_linuxsgx_state.enclave_info.isv_svn, sizeof(sgx_isv_svn_t));
    memcpy(&key_request.config_svn, &g_pal_linuxsgx_state.enclave_info.config_svn,
           sizeof(sgx_config_svn_t));

Current platform cpu_svn, config_svn are used to derive what you call _mr_encalve (and _mr_signer too by the way).

That means BIOS update will result in different cpu_svn -> different _mr_enclave -> different output of the key provider for the same data.

The solution I am aware of is to store SVN values in a plaintext file, together with HMAC, and use it as the input parameters for sgx_get_key. Look at encrypted filesystem as the implementation reference
https://github.com/intel/linux-sgx/blob/7385e10ce1106215d15f874a024ca224c7417eea/sdk/protected_fs/sgx_tprotected_fs/file_crypto.cpp#L265-L277

But to my knowledge, is impossible to call sgx_get_key from gramine directly.
The gramine issue that tackles this problem:
gramineproject/gramine#855