The CPUID instruction is also illegal inside the enclave. Thus software that retrieves CPUID information must do so outside the enclave. Therefore, this information cannot be assured from a security viewpoint and should be used carefully.
An enclave writer may write a custom untrusted function for gathering host system state, which may include CPUID values, system environment variables, and additional application attributes. The results from a specific CPUID leaf could then be preserved inside the enclave (via a specific ECall) to avoid the overhead associated with performing an OCall to execute the CPUID instruction outside an enclave. The key point is that this information is gathered in the untrusted domain and thus the application enclave should design and validate for the scenario in which unexpected or inconsistent data is provided.
One additional consideration is the use of third party libraries which are dependent on the CPUID instruction and have not been modified for Intel SGX compatibility. In this case, the ISV must write a custom exception handler to catch the #UD fault caused by CPUID. In creating the custom exception handler, the ISV should:
- Determine which CPUID leafs are required by the third party library.
- Provide an initialization routine to gather the CPUID data needed by the third party library and cache it inside the enclave.
- Write a custom exception handler for a #UD fault on a CPUID instruction and provide the results for the leaf requested in the failing CPUID instruction. The exception handler must also advance the Instruction Pointer to bypass the CPUID instruction. OCalls are not permitted in exception handlers and thus CPUID data must be obtained during initialization.