On Tue, Mar 02, 2021, Kai Huang wrote:

On Mon, 2021-03-01 at 12:32 +0100, Borislav Petkov wrote:

quoted

On Tue, Mar 02, 2021 at 12:28:27AM +1300, Kai Huang wrote:

quoted

I think some script can utilize /proc/cpuinfo. For instance, admin can have
automation tool/script to deploy enclave (with sgx2) apps, and that script can check
whether platform supports sgx2 or not, before it can deploy those enclave apps. Or
enclave author may just want to check /proc/cpuinfo to know whether the machine can
be used for testing sgx2 enclave or not.

This doesn't sound like a concrete use of this. So you can hide it
initially with "" until you guys have a use case. Exposing it later is
always easy vs exposing it now and then not being able to change it
anymore.

Hi Haitao, Jarkko,

Do you have more concrete use case of needing "sgx2" in /proc/cpuinfo?

The KVM use case is to query /proc/cpuinfo to see if sgx2 can be enabled in a
guest.

The counter-argument to that is we might want sgx2 in /proc/cpuinfo to mean sgx2
is enabled in hardware _and_ supported by the kernel.  Userspace can grep for
sgx in /proc/cpuinfo, and use cpuid to discover sgx2, so it's not a blocker.

That being said, adding some form of capability/versioning to SGX seems
inevitable, not sure it's worth witholding sgx2 from /proc/cpuinfo.