sgx_config_cpusvn is ignored by the simulated EGETKEY

[shamsasari]

If no CPUSVN is specified in the sgx_key_request_t structure then sgx_get_key in simulation uses a hardcoded CPUSVN rather than the "upgraded" or "downgraded" SVN from the sgx_config_cpusvn tool.

It would look like the issue is in this line: https://github.com/intel/linux-sgx/blob/4589daddd58bec7367a6a9de3fe301e6de17671a/sdk/simulation/tinst/t_instructions.cpp#L143

[lzha101]

Yes. Is there any problem here? For HW mode, if you don't specify CPUSVN in the input sgx_key_request_t, it will also not use the actual CPUSVN but just use 0 to derive the key.

[shamsasari]

So, this bug ticket was created on the assumption that the actual CPUSVN is used if it's not specified. This is the behaviour of sgx_get_key in simulation mode. So the actual bug is that simulation mode defaults to the actual CPUSVN rather than leaving it as 0, which is what that line is doing. Correct?

[lzha101]

I suppose using the default CPUSVN instead of 0 is to pass the later cpusvn check. https://github.com/intel/linux-sgx/blob/4589daddd58bec7367a6a9de3fe301e6de17671a/sdk/simulation/tinst/t_instructions.cpp#L149

This is just a simulation implementation and the derived key is just a simulation key. Using 0 or default CPUSVN for simulation key derivation doesn't impact the program execution.

[shamsasari]

But the behaviour is different from HW mode, which would be a bug if it's meant to simulate it.

[caiqs-sys]

Is the derivation process in HW mode a business secret? I can't find it in public docs, is there any docs describing the detail of the key derivation process?

[lzha101]

You can find the key derivation process in Intel SDM. See EGETKEY instruction description.