Remote attestation still returns "configuration needed" with latest bios and microcode update

[yunfeng7854]

Hi, all,

We've tested the remote attestation sample code on 2 platforms available to us: Dell Poweredge R340 (CPU: Intel(R) Xeon(R) E-2174G), and Lenovo ThinkSystem SR250 Rack Server (CPU: Intel(R) Xeon(R) E-2288G). We've updated to the latest BIOS version from the OEM, and the latest microcode patches from: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

However the remote attestation returns

---- Enclave Trust Status from Service Provider ----------------------------

Enclave Trust is TRUSTED and COMPLICATED. The client is out of date and

may not be trusted in the future depending on the service provider's policy.

A Platform Info Blob (PIB) was provided by the IAS

----------------------------------------------------------------------------

---- IAS Advisories --------------------------------------------------------

https://security-center.intel.com

INTEL-SA-00219,INTEL-SA-00289

---- ISV Enclave Trust Status ----------------------------------------------

Enclave TRUSTED and COMPLICATED - Reason: CONFIGURATION_NEEDED

A Platform Info Blob (PIB) was provided by the IAS

The microcode version is 0xca. The SGX SDK is the latest 2.9 version (as of 06/09/2020).

According to the OEM website (Lenovo):

https://datacentersupport.lenovo.com/us/en/product_security/home the INTEL-SA-00219 (CVE-2019-0117) and INTEL-SA-00289 (CVE-2019-11157) were fixed in LEN-29846 (UEFI: ISE114H) and LEN-27714 (UEFI: ISE112).

Perhaps, a TCB recovery is needed for the advisories (https://software.intel.com/sites/default/files/managed/01/7b/Intel-SGX-Trusted-Computing-Base-Recovery.pdf)? Is there any instructions on how to perform the TCB recovery?

Thanks

[Junli_S_Intel]

Maybe you need disable Hyper-Threading and Internal Graphic in your BIOS setting.

[yunfeng7854]

JUNLI S. (Intel) wrote:

Maybe you need disable Hyper-Threading and Internal Graphic in your BIOS setting.

Thank you for the prompt reply. HT is already disabled for the test. We tried to disable internal graphic, and it did not seem working either.

I was thinking it might be caused by the potential leakage of SGX private keys (such as attestation keys used by QE), so it may require a TCB recovery to renew the attestation key.

Best,

Wenhao

[JesusG_Intel]

Hello Yunfeng7854, 

This may be due to Plundervolt (SA-00289). This article may shed some light. If your BIOS does not have the mitigations you will have to work with your OEM.

Regards,

[MiltonVines]

thanks

[yunfeng7854]

Garcia, Jesus L (Intel) wrote:

Hello Yunfeng7854, 

This may be due to Plundervolt (SA-00289). This article may shed some light. If your BIOS does not have the mitigations you will have to work with your OEM.

Regards,

Thank you for your reply. According to the OEM website (https://datacentersupport.lenovo.com/us/en/product_security/home) for BIOS update, SA-00289 (cve-11157) was fixed in the latest BIOS already. So it is really strange to see the RA result with the latest BIOS update.

Best,

Wenhao

[JesusG_Intel]

Hello yunfeng,

Please double check with your OEMs to ensure your installed BIOS addresses these vulnerabilities - INTEL-SA-00219 and INTEL-SA-00289.

Regards,

[Dr__Greg]

Hi Yungfeng, I hope your week has gone well, similar salutations to everyone else reading this thread.

I've watched this thread stumble around for a bit, but haven't had the cycles to respond.  Hopefully these reflections will assist you in debugging these issues.

I'm assuming, based on what you posted in the first thread, that you are using the Intel sample attestation server and client code that is on GitHub.  Are you in control of the server side of the code as well as the client side or are you depending on a service provider to implement the server side of the code?  In either case, you should verify that you are running the most up to date version of the code on both the client and server side of the connection.

In addition, it would be helpful to know if the service provider code is interrogating the production or test version of the Intel Attestation Service (IAS).

In advance, I apologize for the nominal unfamiliarity I have with the Intel service provider sample code, I directed the independent implementation of the entire attestation and EPID provisioning stack, but in that system, the enclaves themselves conduct the entire attestation process, there is no service provider involved.  This did leave us with a high degree of familiarity with respect to how all of this works, so hopefully, we can translate this knowledge into the issues you are confronting.

Based on the output that you provided, it appears as if you are running the client in verbose mode.  The client also has the ability to run in debug mode, which is enabled by the quintessential '-d' command-line argument.  It would be of further assistance if you were to reproduce your testing with that option enabled.

In your output, the client is indicating that a Platform Information Blob (PIB) was returned by the mother ship, ie. IAS.  Enabling the debug option will cause the Platform Information Blob (PIB), that was returned to the server side of the code by IAS, to be printed out in ASCII hexadecimal format on the client.  Decoding that PIB will tell you exactly what IAS is thinking about with respect to the Trusted Computing Base (TCB) of the endpoint that the enclave is initialized on.

Embedded in the PIB will be the CPU security version (CPUSVN) that IAS feels the platform should be at.  That can be compared directly to what the quoting stack is coming up with to determine whether or not the microcode/firmware level of the platform is in question.  By default, regardless of verbose/debug status, the client will print out what IAS considers to be deficient with respect to the endpoint TCB, since nothing is getting printed out, the implication is that IAS considers the platform to be in compliance with the currently recommended TCB for the group that the platform is a member of.

I am a bit distant from all this now, but I believe that Intel documents all of these issues in Version 6 of the 'Attestation Services for Intel Software Guard Extensions: API documentation' document that documents version 4 of the IAS protocol that allows the service to properly attest all vulnerabilities through the Load Value Injection defect.  A quick review of that document indicates that CONFIGURATION_NEEDED, which it appears IAS is returning in your case, refers to a situation where the platform is in TCB compliance but action is needed on the platform to meet the full security potential of the endpoint.

I don't have all of the CVE's immediately in front of me, but CONFIGURATION_NEEDED was added when it was demonstrated that hyper-threading was simply a bridge too far for SGX to work against to provide its intended guarantee that anything going on inside of an enclave was immune from the platform itself.  The original intent of CONFIGURATION_NEEDED was to inform the endpoint owner of the need to turn off hyper-threading in order to protect SGX.

I remember this very distinctly since we were working with ComputeSticks at the time and our code was reporting an undefined attribute bit in the PIB.  When we tracked this down to the need to turn off hyper-threading we found out that the ComputeStick BIOS didn't provide that as an option.  One of the many things that one runs into when you start worrying about security at this level, and something that the industry was probably not capable of addressing, which is one of the significant challenges for SGX as a technology, but I digress.

The purpose of the 'IAS Advisory' information that is returned with the attestation report is to provide a method for the Service Provider to detail to the client what needs to be done in order to bring the platform into security compliance.  Your server/client is reporting issues secondary to SA-00219 and SA-00289.  The former advisory indicates that having a graphics adapter enabled is also a bridge too far for SGX to compete against with respect to security challenges, while the second vulnerability is due to the fact that platform power management is also a bridge too far.... :-(

Let us address these two vulnerabilities in reverse.  The SA-00289 vulnerability is mitigated, according to Intel documentation, by a microcode update.  Since IAS is not reporting a TCB deficiency, one would assume that your platforms are at a firmware/microcode level sufficient to address this issue, otherwise the IAS would be returning GROUP_OUT_OF_DATE and the attestation client would be reporting this fact and the reason for it.

SA-00219 addresses the issue that it is remarkably easy to determine what data resides in the first two DWORD's of a cacheline, despite the best and valiant efforts of the SGX hardware.

One of the mitigations for SA-00219 is to turn off the on-board graphics adapter, so CONFIGURATION_NEEDED may be returned to indicate that as an option.  I'm currently sitting in a rather remote region of West -Central Minnesota, with only modem speed access to the INTERNET, so verifying that fact is a bit challenging, perhaps Jesus, who undoubtedly has far better INTERNET access, could verify that for us.

SA-00219 is also mitigated by recent versions of the SDK that use customized memory allocators that avoid using the first and second DWORD's of cache lines.  I'm assuming that you are using platform enclaves (PCE, QE, PVE) that have been compiled with a recent SDK which has those mitigations in place, otherwise IAS would be reporting a defect in the TCB of the platform, secondary to deficient ISVSVN's values in the enclave signature, which it is not.

In either case you indicate that you have turned off both the graphics adapter and hyper-threading, yet the problem persists, which suggests something more nefarious is going on.  At the risk of being presumptuous and indicting, I think the case can be made that Jesus should prevail upon the IAS developers to better understand why CONFIGURATION_NEEDED would be returned in light of the above analysis and findings.

It may be something as simple as the fact that IAS implements a rule that returns CONFIGURATION_NEEDED if the hardware group is one that has a vulnerable on-board graphics adapter, regardless of whether or not the platform enclaves are reporting, via their ISVSVN values, that mitigations are in place.

I noted, at the outset, that it was important to know whether the server side of the service provider code was running against the production or development versions of IAS.  The two services, by design, have somewhat different opinions about the TCB status of endpoints.  If you have control of the server side, and have IAS credentials for both dev and production, it would be a worthwhile experiment to change what the server is aimed at to see if it would impact the results you are getting.

Hopefully all of the above will be useful background to assist with resolution of this issue.  Happy Hour is currently dawning in the glacial moraine country of West-Central Minnesota so I am going to indulge myself in that and then grill a hunk of salmon for my Dad, my dog and myself.

Best wishes for a pleasant weekend to everyone.

Dr. Greg

[yunfeng7854]

Dr. Greg wrote:

Hi Yungfeng, I hope your week has gone well, similar salutations to everyone else reading this thread.

I've watched this thread stumble around for a bit, but haven't had the cycles to respond.  Hopefully these reflections will assist you in debugging these issues.

I'm assuming, based on what you posted in the first thread, that you are using the Intel sample attestation server and client code that is on GitHub.  Are you in control of the server side of the code as well as the client side or are you depending on a service provider to implement the server side of the code?  In either case, you should verify that you are running the most up to date version of the code on both the client and server side of the connection.

Thank you Dr. Greg. Wish you a happy weekend and holiday.

As suggested, we did the followings:

(1) using the latest ra sample code (please note that the latest commit data is about 1 year ago).

(2) using production verison of IAS. Specifically we built the enclave in release mode (disabling the debug option in config.xml, and the application loads the enclave file with debug option disabled), and signed the enclave file using 2-step signing with the keys for production enclave. Then we connected with the trusted IAS service for production enclave (i.e., as.sgx.trustedservices.intel.com).

Unfortunately, similar results are returned. I am attaching the PIB here for your information.

Client Output:

---- Enclave Trust Status from Service Provider ----------------------------
Enclave Trust is TRUSTED and COMPLICATED. The client is out of date and
may not be trusted in the future depending on the service provider's  policy.
A Platform Info Blob (PIB) was provided by the IAS
+++ PIB: 00000800000e0e02040180060000000000000000000b00000b000000020000000000000bca2ccfae33bb3c52f603e5207ffd14d55812eba9c5e6df6da4228ab440d8c4a252872592425fee2d861ab6f02e10271c7bcf2d48a6c9c055cf75c8499b1d4d43de
+++ sgx_report_attestation_status ret = 0x0000

Server Output:

---- IAS Report - JSON - Optional Fields -----------------------------------
platformInfoBlob  = 1502006500000800000E0E02040180060000000000000000000B00000B000000020000000000000BCA57FC8288C6F065C096262A6ABE1402401CCB2A4FD72277BC78E10B8772450BFCC5DBC4574619A1DE305A2BBAF3175E1C17FABAA6C14D39480635AD27AAD37708
revocationReason  =
pseManifestStatus =
pseManifestHash   =
nonce             =
epidPseudonym     =
----------------------------------------------------------------------------

Decoding the PIB with a simple tool https://github.com/dingelish/sgx-decode-pib-rs

 ./sgx-decode-pib 1502006500000800000E0E02040180060000000000000000000B00000B000000020000000000000BCA57FC8288C6F065C096262A6ABE1402401CCB2A4FD72277BC78E10B8772450BFCC5DBC4574619A1DE305A2BBAF3175E1C17FABAA6C14D39480635AD27AAD37708
Simple SGX platform information blob decoder
Platform info is:
 sgx_epid_group_fags = 00

 sgx_tcb_evaluation_flags = 0008
  PLATFORM_CONFIGURATION_NEEDED

 pse_evaluation_flags = 0000

 latest_equivalent_tcb_psvn: 0E0E02040180060000000000000000000B00

 latest_pse_isvsvn: 000B

 latest_psda_svn: 00000002

 xeid: 00000000

 gid: 00000BCA

 signature:
  gy: 57FC8288C6F065C096262A6ABE1402401CCB2A4FD72277BC78E10B8772450BFC
  gy: C5DBC4574619A1DE305A2BBAF3175E1C17FABAA6C14D39480635AD27AAD37708

Best wishes,

Wenhao

[Dr__Greg]

Hi Wenhao, I hope your weekend is going well.

My apologies for the delayed response. I was going to reply mid-week but wasn't able to, secondary to Intel's revamp of the site.

We ran the PIB through our tooling and it confirms your findings. Production IAS is indicating that the system has a firmware/microcode level consistent with what is expected for the platform and the platform certification enclave is at an acceptable security version (ISVSVN = 11).

Based on revision 6, the most recent version of the Attestation Service for Intel Software Guard Extensions: API Documentation, a status of CONFIGURATION_NEEDED indicates the following:

The EPID signature of the ISV enclave QUOTE has been verified correctly, but additional configuration of SGX platform may be needed (for further details see Advisory ID's).

Your advisories are for SA-00219 and SA-00289, which means configuration changes needed are related to those advisories. You stated that you had hyper-threading disabled which would have covered the original rationale for the CONFIGURATION_NEEDED status return.

You also indicated that you had disabled on-board graphics, but this did not change the status.  If you were not running platform enclaves that had the cache line avoidance mitigations in place the attestation report would have indicated GROUP_OUT_OF_DATE. The fact that you turned off on-board graphics, and this had no effect on the attestation, would suggest that IAS understands the fact that you have appropriate software mitigations in place. It would be helpful if Jesus could confirm that having software mitigations in place is sufficient to cancel a positive CONFIGURATION_NEEDED response for SA-00219.

That leaves SA-00289, aka Plundervolt, the mitigation for which is to install updated firmware. If you did not have current firmware in place, IAS would have reported GROUP_OUT_OF_DATE.

I spent a little time scrounging around and found a PDF from Intel that talked about this vulnerability, but for the life of me I can't find it right now. In any event, the PDF made the following comment:

Firmware must disable ability for privileged software to modify voltage configuration.

There is no detail beyond that, but by inference, I would assume that the platform vendor can make a decision as to how to implement the recommended firmware upgrade. I would presume that the platform vendor can make a decision as to whether or not the firmware should allow software running at ring 0 privilege levels to make changes to the voltage configuration. I'm assuming that in the case of  your platforms, the vendors decided to preserve the ability of the OS (ring 0) to make these changes.

Which would certainly make sense with respect to the issues surrounding the economies of security. Removing the ability of the platform to modify the processor voltage level may make the platform secure but at the expense of power management. Given that the vast majority of the deployers of these platforms are more concerned by energy consumption issues then security, it would make sense for the
platform vendors to favor the former rather then latter. Which of course begs the question of how SGX can be generically relevant, but that is the topic for another time and venue.

If all of this is the case, your platforms will never be able to return a 'clean', ie 'OK', attestation report.

I see that Jesus has indicated that he is trying to get a response to your issue. I assume he is polling the IAS backend team in Poland. You seem to have facility with C so it may be helpful if you could modify the RA sample code to output the transaction ID and timestamp that IAS returns with the attestation report.
I believe the IAS team can use that to find the exact IAS transaction, which they can in turn use to determine why the CONFIGURATION_NEEDED status response was returned.

The transaction id and timestamp are in the 'id' and 'timestamp' elements of the JSON array that is returned in the body of the response to the REST query that the RA server code executes. I believe that if you are able to modify the RA server code to output those values it would be of assistance to Jesus in determining why we are seeing this phenomenon.

These issues are emblematic of the challenge that SGX posed to the IT community, that it has demonstrated no really good response to. The issues you encountered. and the amount of equipment we have in the lab that is no longer usable, because there are no firmware upgrades, indicate how unprepared we are as an industryto maintain, long term, platforms that are in a quantifiable security state.

But enough philosophy, hopefully the above suggestions will help in quantifying the rationale for the issues you are seeing.

It is another Saturday evening here in the Upper Midwest so I will retire from this conversation to my snifter of single-malt Scotch.

Have a good week.

Dr. Greg

[JesusG_Intel]

Hello yunfeng, we are trying to find out more information for you. Please stay tuned.

[JesusG_Intel]

Hello Yunfeng,

There are a couple of things you can try.

1. There is a BIOS option that can control the bit - Overclocking Lock). For our customer reference board, It’s under BIOS menu “advance ->power & performance -> CPU - Power Management Control -> CPU Lock configuration -> overclocking lock”. Lenovo’s default is set to disable. This default setting may be due to overclocking feature. Can you enable the lock on your platform to mitigate SA-00289?
2. You are still using MCU 0xca but the latest MCU is 0xd6. In Lenovo’s latest BIOS release note, M22906ED_000000D6 is listed: https://download.lenovo.com/servers/mig/2020/06/11/22070/lnvgy_fw_uefi_ise116e-2.11_anyos_32-64.chg

[yunfeng7854]

Thank you for your reply, Jesus

As suggested, we (1) set the BIOS options to disable dynamic frequency/overclocking (2) upgraded the microcode to the latest one (0xd6). The remote attestation result is shown below  (INTEL-SA-00219 and INTEL-SA-00289 still exist).

./run-server:

---- IAS Advisories --------------------------------------------------------
https://security-center.intel.com

INTEL-SA-00219,INTEL-SA-00289

----------------------------------------------------------------------------

---- IAS Report - JSON - Required Fields -----------------------------------
version               = 3
id:                   = 77053096353068878976970717124476535333
timestamp             = 2020-07-03T06:30:31.189371
isvEnclaveQuoteStatus = CONFIGURATION_NEEDED
isvEnclaveQuoteBody   = AgABAMoLAAALAAoAAAAAAH1K1LbwilycRJOw/q2X2tYAAAAAAAAAAAAAAAAAAAAAEBAFBQGAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAHAAAAAAAAAC06xhwTSkFJ9r/dGQBaADj4RmDYyTTbWvb44l9ADt/9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9ccY4Dvd8VBfostHOLUtlBLn0GOUEk0JEDP/yRD2VvQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQgnMNL+PczdHmby3WrCbONTF9iDDuoSiNnVlfq+zkVQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

---- IAS Report - JSON - Optional Fields -----------------------------------
platformInfoBlob  = 1502006500000800000F0F02040180060000000000000000000B00000B000000020000000000000BCAC631EE13E99F51AF293FDA1FD33342C8EBE7DBAFD6FD156D50ADFE5365E953E75B78DCF878449457582A2C8B30581526667A64509558B194708A2A40E368FA1C
revocationReason  =
pseManifestStatus =
pseManifestHash   =
nonce             =
epidPseudonym     = f/tDqq8zOe1UpjvzG7YXYNH/Kxnne6UNZAZ3VA1Y0a0RM3HDrbIM2GxSwt5gurqEJxJAxDQled4PEJu9R7RPffQ+T3BDuGXrzLjdXTPZR8GynNMf/wCmiyfohKBDbIzWvKTjRPVpMs+z8C4PU34IpiMXuG6VTFjKdmbpxMsuyOw=
----------------------------------------------------------------------------
+++ Verifying report version against API version

---- ISV Enclave Trust Status ----------------------------------------------
Enclave TRUSTED and COMPLICATED - Reason: CONFIGURATION_NEEDED
A Platform Info Blob (PIB) was provided by the IAS

./run-client

---- Enclave Trust Status from Service Provider ----------------------------
Enclave Trust is TRUSTED and COMPLICATED. The client is out of date and
may not be trusted in the future depending on the service provider's  policy.
A Platform Info Blob (PIB) was provided by the IAS
+++ PIB: 00000800000f0f02040180060000000000000000000b00000b000000020000000000000bcac631ee13e99f51af293fda1fd33342c8ebe7dbafd6fd156d50adfe5365e953e75b78dcf878449457582a2c8b30581526667a64509558b194708a2a40e368fa1c
+++ sgx_report_attestation_status ret = 0x0000

Best,

Wenhao

[JesusG_Intel]

Thanks for the information, Wenhao. I have relayed your response to our engineering team. Keep in mind that the platform OEM's implementation of the fixes will determine if you can get a clean attestation report. There may not be anything you can do about it. I'll let you know what I hear back from engineering.

[JesusG_Intel]

Hello Wenhao, please ENABLE the overclocking lock bit. "Disable" is the default from the vendor.

[yunfeng7854]

Thanks, Jesus

It seems that our platform does not support the "overclocking lock bit", and we disabled the frequency scaling related options for testing.

Best,

Wenhao

[JesusG_Intel]

Hello Wenhao,

Unfortunately there is nothing more you can do at this point. As stated before, it is up to the vendor's implementation.

Regards,

[JesusG_Intel]

Hello Wenhao,

I heard back from engineering and they would like to do some more troubleshooting. Can you provide the CPU info for each of your affected platforms?

• Linux: type lscpu.
• Windows: take screenshot of System Information with full Processor line showing and BIOS Version/Date.

[yunfeng7854]

Dear Jesus,

Sorry for the late reply. The CPU information is listed below.

Lenovo platform:

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  1
Core(s) per socket:  8
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               158
Model name:          Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
Stepping:            13
CPU MHz:             999.879
CPU max MHz:         3700.0000
CPU min MHz:         800.0000
BogoMIPS:            7399.70
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            16384K
NUMA node0 CPU(s):   0-7
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cm                                                                                                             ov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb                                                                                                              rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop                                                                                                             _tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3                                                                                                              sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_time                                                                                                             r aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_si                                                                                                             ngle ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fs                                                                                                             gsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushop                                                                                                             t intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp                                                                                                             _act_window hwp_epp md_clear flush_l1d arch_capabilities

Dell platform

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               158
Model name:          Intel(R) Xeon(R) E-2174G CPU @ 3.80GHz
Stepping:            10
CPU MHz:             4492.094
CPU max MHz:         4700.0000
CPU min MHz:         800.0000
BogoMIPS:            7584.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            8192K
NUMA node0 CPU(s):   0-3
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_act_window hwp_epp md_clear flush_l1d

Best,

Wenhao

[JesusG_Intel]

Thank you, Yunfeng. We have sent your CPU info to engineering for further investigation.

[JamesColleen]

Strange, I would have thought enabling the overclocking bit would have done the trick...