Unable to read encrypted files after a kernel upgrade.

[kvinwang]

Description of the problem

Gramine encrypted files cannot be opened after a kernel upgrade.

I originally posted this issue as a discussion thread #1503. However, after digging further, I believe it is worth opening an issue here.

Steps to reproduce

1. Install Rust toolchain
2. git clone https://github.com/kvinwang/gramine-encrypted-files-demo && cd gramine-encrypted-files-demo
3. make SGX=1
4. ./run.sh
   It would show the following logs:
   
5. reboot the system and load another version of kernel
6. ./run.sh again
   It now show the same egetkey result but failed to read the encrypted files as below:
   

Expected results

Encrypted files should be read successfully.

Actual results

Permission Denied

Gramine commit hash

ede508c

[kvinwang]

The reason might be the cpu_svn changed between the two version of kernel.
If so, is it possible that gramine record the cpu_svn of a encrypted file and use it to get the unsealing key while decrypt the file?

[kailun-qin]

@kvinwang Thanks for the report! Pls see my comments below.

The reason might be the cpu_svn changed between the two version of kernel.

I saw in the corresponding discussion - "Some of the machine have a linux kernel update during the reboot, some haven't.", so this seems to happen for reboots even w/o kernel updates. Then why would CPUSVN change if it's a plain/normal reboot (w/o kernel update)? Can we first make sure that it's the change of the CPUSVN that caused your reported issue.

In your reproduction test, the printed SGX sealing keys were directly from EGETKEY (w/ CPUSVN hardcoded), instead would you pls show the keys that Gramine actually used for encrypted fs by reading them from /dev/attestation/keys/_sgx_mrenclave and /dev/attestation/keys/_sgx_mrsigner?

If so, is it possible that gramine record the cpu_svn of a encrypted file and use it to get the unsealing key while decrypt the file?

Yes, this is doable where we could extend metadata_plain_t w/ CPUSVN (and ISVSVN probably)

gramine/common/src/protected_files/protected_files_format.h

Lines 31 to 37 in 9ef75eb

	typedef struct _metadata_plain {
	uint64_t file_id;
	uint8_t major_version;
	uint8_t minor_version;
	pf_keyid_t metadata_key_id;
	pf_mac_t metadata_gmac; /* GCM mac */
	} metadata_plain_t;

and restore them in key_request for getting SGX sealing keys.

[dimakuv]

This is a duplicate of #855. Please see there, we have lots of discussions in that thread.

So, I think we have three users (user bases) that hit this problem of CPUSVN. I will raise this issue in one of the Gramine meetings, and I'll probably write a PoC, so that we at least have something concrete to discuss.

[kvinwang]

Can we first make sure that it's the change of the CPUSVN that caused your reported issue.

We finally comfirmed that all our cases was due to intel-microcode update which further changed the CPUSVN.

As this issue is duplicate of #855, let closing this one and continue there.