GROUP_OUT_OF_DATE - what is the most recent microcode version?

GROUP_OUT_OF_DATE - what is the most recent microcode version?

Hello,

 

I know this topic of GROUP_OUT_OF_DATE came up several times, and typically updating BIOS resolved it. Yes, I am aware of this post: https://software.intel.com/en-us/comment/1911344#comment-1911344.

I called "sgx_report_attestation_status" on the "platform information blob". I got error 0x4006 (SGX_ERROR_UPDATE_NEEDED).

Looking at the "sgx_update_info_bit_t*" I got back from "sgx_report_attestation_status"   I see: ucodeUpdate == 1; csmeFwUpdate == 0; pswUpdate == 0;

Which I assumed meant I need a microcode update (while the ME and the PSW are OK). I have a NUC machine NUC7i7BNH, and the most recent bios update is from recent November (2017). This brings me to ucode version 0x70:

Output of /proc/cpuinfo:

vendor_id : GenuineIntel

cpu family : 6

model : 142

model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz

stepping : 9

microcode : 0x70

 

I even tried manually updating the microcode version to 0x80, but I still get GROUP_OUT_OF_DATE error. I wonder if the ucode has to be updated by the BIOS for it to "count" for SGX.

 

Any hints? Can it be in any way related to my client-side certificates I am using to communicate with IAS?

Is there a new BIOS update for NUC7i7 with the spectre/meltdown patched ucode?

 

Thanks!

 

Ofir

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

As an update (issue still UNRESOLVED): 

I did dist-upgrade to my Ubuntu server 16.04.

Output of /proc/cpuinfo:

cpu family      : 6

model           : 142

model name      : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz

stepping        : 9

microcode       : 0x80

 

I rebooted, reinstalled SDK and PSW versions 2.1.1, rebooted again. I still get the same output from "sgx_report_attestation_status" saying that I need to update my microcode, even though it is at the latest version: 0x80.

 

Thanks

Hi,

I just want to report the same issue as Ofir.  I am getting the same error (GROUP_OUT_OF_DATE) on all 3 machines (2 intel server block and a lenovo laptop) on which the remote attestation were working a week ago.  Was there an announcement from Intel on some IAS changes?

Thanks.

Kind Regards,
Elephant

Good morning, I hope the week is going well for everyone.

We are working to respond to all of this. I've been on a disrupted travel schedule, here is the best background information we can provide at the current time.

Intel is forcing a Trusted Computing Base (TCB) recovery, in order to ensure that all SGX platforms are running updated microcode and platform software to mitigate the Spectre class of vulnerabilities. Our SGX Spectre analysis post/paper, which can found at the following locations:

https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status...

ftp://ftp.idfusion.net/pub/sgx/sgx-spectre-meltdown.pdf

Has background information that discusses what is going on.

There is a high probability that Intel wants to make sure that SGX capable platforms have support for Indirect Branch Restricted Speculation (IBRS) and/or the other speculation fencing primitives that have been developed. It would be logical to assume that the ENCLU[EENTER] and ENCLU[EXIT] instructions are being modified to use IBRS to implement speculation fencing between untrusted and trusted (enclave) execution domains.

The IAS development servers began generating 'GROUP_OUT_OF_DATE' enclave attestation responses on 2/6/2018 for platforms that have not been properly updated. The IAS production servers will begin reporting this condition on 3/20/2018.

The security versions for the provisioning and quoting enclaves have also been incremented as part of this response. This is being used to indicate the enclaves have been updated to implement speculative fencing remediations. So, in order for remote attestation to work, the platform must have updated firmware/microcode as well as updated binary enclaves.

Our concern, as noted by previous posts, is that the required update might be a firmware/BIOS level update, not just a userspace microcode injection update. Unless there is alternative guidance, this could mean that a lot of platforms will no longer be usable for SGX if remote attestation is a requirement. This is secondary to the well understood fact that a lot of commodity motherboard/platform manufacturers simply do not provide firmware upgrades for their platforms.

If the previous posts are correct and the IAS development servers are reporting 'GROUP_OUT_OF_DATE' with BOTH updated userspace injected microcode and binary enclaves, there is a high probability that a vendor supplied firmware update is also required, if it will ever even be available.

On the plus side this is the way that SGX was designed to operate. The intention of this technology is to provide a root of trust to guarantee the operational integrity of enclaves running on a platform. Providing that guarantee means that platforms must be implementing appropriate mitigations for known security vulnerabilities.

On the negative side this collides rather dramatically with the notion of commodity computing platforms, which are largely abandoned after their initial release.

Commodity platforms are going to be the only game in town when it comes to security. If a technology such as SGX is going to be of utility, there must be a time frame guarantee associated with firmware that is required in order to make the platform viable from a security perspective.

All of this has the potential to provide a forum for some very interesting, and much needed, conversations.

I haven't slept in 36 hours, once I recover from that we will see if we can find the cycles to implement more testing in our lab and possibly put together a formal guidance paper on all of this.

Dr. Greg

Hi Dr. Greg,

Thanks for your effort. But we still have problems and getting group out of date error no matter what the firmware is.

I have four testbeds: (1) Intel 8086k + Gigabyte Z370 AORUS, (2) Intel Xeon E3 1280v5 + Supermicro X11SSH-F, (3) Intel Xeon E3 1280v6 + Supermicro X11SSH-F and (4) Intel Compute Stick STK2M3W64CC.

This week I've updated all bios firmware of them by flashing the most recent bios firmware provided by Gigabyte/Intel/Supermicro and I'm 100% sure that they are the latest version (released after April 2018). And I have followed the instructions provided by Intel to upgrade the microcode to the latest version 20180703.

But I'm still getting GROUP_OUT_OF_DATE error in the report.

Is there anything I could do to get an OK? or could you please provide a combination of CPU+motherboard+BIOS firmware which satisfies the security requirement and get an OK in report? I feel desperate and struggling with my testbeds and cannot figure out anything. Definitely need your help.

Thanks,

Yu

 

Quote:

Greg W. wrote:

Good morning, I hope the week is going well for everyone.

We are working to respond to all of this. I've been on a disrupted travel schedule, here is the best background information we can provide at the current time.

Intel is forcing a Trusted Computing Base (TCB) recovery, in order to ensure that all SGX platforms are running updated microcode and platform software to mitigate the Spectre class of vulnerabilities. Our SGX Spectre analysis post/paper, which can found at the following locations:

https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status...

ftp://ftp.idfusion.net/pub/sgx/sgx-spectre-meltdown.pdf

Has background information that discusses what is going on.

There is a high probability that Intel wants to make sure that SGX capable platforms have support for Indirect Branch Restricted Speculation (IBRS) and/or the other speculation fencing primitives that have been developed. It would be logical to assume that the ENCLU[EENTER] and ENCLU[EXIT] instructions are being modified to use IBRS to implement speculation fencing between untrusted and trusted (enclave) execution domains.

The IAS development servers began generating 'GROUP_OUT_OF_DATE' enclave attestation responses on 2/6/2018 for platforms that have not been properly updated. The IAS production servers will begin reporting this condition on 3/20/2018.

The security versions for the provisioning and quoting enclaves have also been incremented as part of this response. This is being used to indicate the enclaves have been updated to implement speculative fencing remediations. So, in order for remote attestation to work, the platform must have updated firmware/microcode as well as updated binary enclaves.

Our concern, as noted by previous posts, is that the required update might be a firmware/BIOS level update, not just a userspace microcode injection update. Unless there is alternative guidance, this could mean that a lot of platforms will no longer be usable for SGX if remote attestation is a requirement. This is secondary to the well understood fact that a lot of commodity motherboard/platform manufacturers simply do not provide firmware upgrades for their platforms.

If the previous posts are correct and the IAS development servers are reporting 'GROUP_OUT_OF_DATE' with BOTH updated userspace injected microcode and binary enclaves, there is a high probability that a vendor supplied firmware update is also required, if it will ever even be available.

On the plus side this is the way that SGX was designed to operate. The intention of this technology is to provide a root of trust to guarantee the operational integrity of enclaves running on a platform. Providing that guarantee means that platforms must be implementing appropriate mitigations for known security vulnerabilities.

On the negative side this collides rather dramatically with the notion of commodity computing platforms, which are largely abandoned after their initial release.

Commodity platforms are going to be the only game in town when it comes to security. If a technology such as SGX is going to be of utility, there must be a time frame guarantee associated with firmware that is required in order to make the platform viable from a security perspective.

All of this has the potential to provide a forum for some very interesting, and much needed, conversations.

I haven't slept in 36 hours, once I recover from that we will see if we can find the cycles to implement more testing in our lab and possibly put together a formal guidance paper on all of this.

Dr. Greg

Good morning to Yu and the group.

We have done an independent implementation of a PSW to support our work with SGX on intelligent network endpoint devices, ie. IOT, SCADA etc. This includes all of the infrastructure needed to implement bilateral enclaveenclave attestation. As a result our tooling offers a great deal of diagnostic information regarding attestation status.

If the attestation quote status is GROUP_OUT_OF_DATE or GROUP_REVOKED the platformInfoBlob field provides information on why IAS feels the quoting platform does not have a Trusted Computing Base (TCB) which meets the minimum required security level.

One of the elements of the platform_info structure is a two byte array (sgx_tcb_evaluation_flags) which contains a bitwise encoding of the IAS service has concluded the TCB is not uptodate. There are three issues commonly reported; the CPU security version and the security versions of the quoting (QE) and sealing (PCE) enclaves. The platform_info structure also contains a structure element that encodes the recommended CPU security version (SVN) as well as the security versions of the two enclaves.

Here is an example of output of a quote generated by one of our lab machines that has not received a microcode update and is running old versions of the two enclaves:

Platform Info Report:

EPID group flags: 4

EPID group out of date.

TCB evaluation flags: 7

CPU svn out of date.

QE enclave out of date.

PCE enclave out of date.

Recommended platform status:

CPU svn: 07070101010100000000000000000000

ISV svn: 5

Of interest in the report body is the current CPU security version reported by the platform that is as follows:

cpusvn: 04040204ff0200000000000000000000

One of the platforms we work with in our development lab are the Intel ComputeSticks. I can confirm that upgrading a STK2MV64CC to the current firmware released by Intel results in IAS returning a report indicating that the CPU security version is valid. I'm running out of time now but I can get the CPUSVN off that platform if there is interest.

I'm assuming you are running the latest version of the Intel PSW/SDK so your quoting and sealing enclaves meet TCB standards?

The next question would be are you using the Intel test or production IAS services. There have been reports in this forum of having issues with certificates and the like on the test IAS services.

If you have upgraded your platforms to the most current firmware levels the only remaining issues are the security status of the enclaves. Either that or IAS is getting confused on what is being presented.

The AESM is very much a block box but if you could somehow capture the response from the REST request that comes back from IAS we could run it through out tooling and decode precisely what IAS is thinking about with respect to the platform TCB that is generating the quotes you are receiving.

Our enclaveenclave security model does a lot of attestations since we poll INED's for their platform security status that is maintained inside of an enclave. Each connection results in two attestations as the enclaves verify that the communication endpoints are secure. We use the production IAS services exclusively and we found it to be very solid, hence the question on which service you are using.

Hopefully the above information is helpful.

Have a good day.

Dr. Greg

Hey Dr. Greg, you're explanation is so much clear and we really appreciate your help.

I'm pretty much sure I'm using the up to date version of PSW (ubuntu linux desktop, v2.2), QE and PCE on my STK2MV64CC. They are the following:

libsgx_pce.signed.so, sha256:5f363cc4606495076881c3c321034114647b0420a0a5fda5c8f7b4dc260d8f07, metadata->enclave_css.body.isv_svn: 0x6

libsgx_qe.signed.so, sha256:dd09f9a9b6fedfcd988992067caa93627ad81167d8ae93b853644270a628013e, metadata->enclave_css.body.isv_svn: 0x7

CPU microcode version is dumped from `dmesg | grep microcode`   microcode: sig=0x406e3, pf=0x80, revision=0xc2

And I double confirmed the response from IAS report REST api says GROUP_OUT_OF_DATE.

And I found platformInfoBlob in the REST api and here are three of them I generated from the compute stick:

1502006504000100000505020401800000000000000000000007000006000000020000000000000AE066584E3E99C34056C7C566112BDCC13D4867E806A7FD7A79B10BF532ED07D5696FD4C5A45AD38A8FADBD43EDAA23114CBB3A5B397519DF84CBA644A7F2A8B3BD

1502006504000100000505020401800000000000000000000007000006000000020000000000000AE0D553EE5D73D166CE0173499FDA3FF48E8C3C13302E5A541231C3F77830E5DB0DB627BECE23F6453F671F299D1B09C6B871792F701D562CBDDFB0979FE8D93906

1502006504000100000505020401800000000000000000000007000006000000020000000000000AE06088795DD5A3F336ED6507799853FDF7A386AD88F2B0863A2DB1A56660B406BB1FE2B46FEB555D88C86A8C2E4B8D946BEA591DBD87D5A0CEC749B72AA86D710B

These Hexstrings are all 210 bytes long. The IAS specification says that this is base16 encoded. So the decoded platformInfo should be 105 bytes.

I looked through the SDK APIs and find that it should be decoded by sgx_report_attestation_status. However, the sgx_platform_info_t is only 101 bytes, not 105! I tried to send the first 101 bytes to sgx_report_attestation_status but it always returns SGX_ERROR_INVALID_PARAMETER.

Updated: Found the correct demonstration at the official intel sgx remote attestation sample here. I remove the 4-byte TSV header and now sgx_report_attestation_status works perfectly. The only thing matters is the second parameter: attestation_status. If I pass 0 to it, ucodeUpdate will equal to 0. If I pass anything other than 0, ucodeUpdate will equal to 1. 

This does not make sense. Whether or not the attestation succeed cannot affect the truth of ucodeUpdate. What's more, the microcode is upgraded to the latest version and I've got something like yours from the official sgx-ra sample which indicates that our CPU_SVN are the same!

---- Enclave Report Details ------------------------------------------------

cpu_svn     = 0707ffffff0100000000000000000000
misc_select = 00000000
attributes  = 07000000000000000700000000000000
mr_enclave  = e5907c86e38f81ac092dcf470c69c79080b89c9e3a09c9f946625a41d83c83df
mr_signer   = bd71c6380ef77c5417e8b2d1ce2d4b6504b9f418e5049342440cfff2443d95bd
isv_prod_id = 0000
isv_svn     = 0100
report_data = f26f74388c1861996e12e76025b7affb0026588d5a7fb7190d98010b34b858930000000000000000000000000000000000000000000000000000000000000000

Thank you very much!

Best,

Yu

Quote:

Greg W. wrote:

Good morning to Yu and the group.

We have done an independent implementation of a PSW to support our work with SGX on intelligent network endpoint devices, ie. IOT, SCADA etc. This includes all of the infrastructure needed to implement bilateral enclave<->enclave attestation. As a result our tooling offers a great deal of diagnostic information regarding attestation status.

If the attestation quote status is GROUP_OUT_OF_DATE or GROUP_REVOKED the platformInfoBlob field provides information on why IAS feels the quoting platform does not have a Trusted Computing Base (TCB) which meets the minimum required security level.

One of the elements of the platform_info structure is a two byte array (sgx_tcb_evaluation_flags) which contains a bitwise encoding of the IAS service has concluded the TCB is not uptodate. There are three issues commonly reported; the CPU security version and the security versions of the quoting (QE) and sealing (PCE) enclaves. The platform_info structure also contains a structure element that encodes the recommended CPU security version (SVN) as well as the security versions of the two enclaves.

Here is an example of output of a quote generated by one of our lab machines that has not received a microcode update and is running old versions of the two enclaves:

Platform Info Report:

EPID group flags: 4

EPID group out of date.

TCB evaluation flags: 7

CPU svn out of date.

QE enclave out of date.

PCE enclave out of date.

Recommended platform status:

CPU svn: 07070101010100000000000000000000

ISV svn: 5

Of interest in the report body is the current CPU security version reported by the platform that is as follows:

cpusvn: 04040204ff0200000000000000000000

One of the platforms we work with in our development lab are the Intel ComputeSticks. I can confirm that upgrading a STK2MV64CC to the current firmware released by Intel results in IAS returning a report indicating that the CPU security version is valid. I'm running out of time now but I can get the CPUSVN off that platform if there is interest.

I'm assuming you are running the latest version of the Intel PSW/SDK so your quoting and sealing enclaves meet TCB standards?

The next question would be are you using the Intel test or production IAS services. There have been reports in this forum of having issues with certificates and the like on the test IAS services.

If you have upgraded your platforms to the most current firmware levels the only remaining issues are the security status of the enclaves. Either that or IAS is getting confused on what is being presented.

The AESM is very much a block box but if you could somehow capture the response from the REST request that comes back from IAS we could run it through out tooling and decode precisely what IAS is thinking about with respect to the platform TCB that is generating the quotes you are receiving.

Our enclave<->enclave security model does a lot of attestations since we poll INED's for their platform security status that is maintained inside of an enclave. Each connection results in two attestations as the enclaves verify that the communication endpoints are secure. We use the production IAS services exclusively and we found it to be very solid, hence the question on which service you are using.

Hopefully the above information is helpful.

Have a good day.

Dr. Greg

Hi Yu, I hope this note finds your day going well.

Thanks for forwarding along the diagnostic information.  It was helpful in better understanding the issue that you are running into.  At this point in time the most important information that would help clarify what is going on is whether you are using the test or production instances of IAS to generate the reports for the Compute Stick quotes?

We ran the Base16 encoded platformInfoBlobs from your ComputeStick quotes through our PIB decoding tool.  The IAS instance you are using is saying the same thing in all three instances, that security version of the CPU that generated the quotes was not consistent with the currently specified Trusted Computing Base (TCB) for the platform.

I'm attaching the output from the following command to this post:

./sgx-decode-pib -b 1502006504000100000505020401800000000000000000000007000006000000020000000000000AE066584E3E99C34056C7C566112BDCC13D4867E806A7FD7A79B10BF532ED07D5696FD4C5A45AD38A8FADBD43EDAA23114CBB3A5B397519DF84CBA644A7F2A8B3BD

As you can see in the output IAS indicates the CPU security version is out of date and recommends that the correct CPUSVN is as follows:

05050204018000000000000000000000

If I interpret your posting correctly the CPUSVN in your report is as follows:

0707ffffff0100000000000000000000

While the 128 bit field encoding is, to our knowledge, unspecified.  It has been our experience that the first couple of digits are linear with respect to higher, ie. more recent versions, of platform firmware.  That suggests that your ComputeStick is running something more recent then what the IAS is recommending as the correct CPUSVN TCB.

I'm attaching the output from a utility that we have in our PSW/SDK which generates an enclave report on the local host and submits that to IAS for verification.  I ran the utility on one of our STK2MV64CC ComputeSticks which is running the most current firmware as of early June.  As you can see in the log output production IAS indicates the CPUSVN TCB for the process is correct.  It is notable that your CPUSVN is roughly consistent with ours, at least in the leading digits which seems to roughly correlate with firmware version.

All of this takes us back to why we are asking about which IAS instance you are attesting against.  As I've noted previously our PSW/SDK follows a model where attestations are done by the enclaves themselves.  So the log is actually generated from inside of the enclave that generated the report.  Obviously we have OCALL's which implement the EPID loading and QE interactions since they cannot be done from inside of an enclave.  The OCALL's that execute the REST exchange with IAS are directed to the production IAS services.

If you look at the ISVSVN recommendation in your platform information report, ie. the quoting enclave security version, the instance of IAS you are using recommends 7.  If you look at the attachment that contains the debug output from our test attestation you will see that we receive a recommendation of 5.  There might be a possibility that Intel would recommend an alternate QE SVN depending on processor type but that seems highly unlikely given how they have set all of this up.

If we interpret your previous posts correctly you are seeing attestation failures across multiple platforms that you claim have all been upgraded to the latest firmware versions.  If whatever IAS instance you are using has its CPUSVN database out of kilter that would explain why you are seeing this issue across multiple platforms.  It would also explain why you are getting back a CPUSVN recommendation that seems entirely inconsistent with reality.

Intel sent out an SGX notification letter in late May indicating that a TCB upgrade would be conducted in order to address issues with their IPP cryptography and to reflect firmware upgrade requirements to address CVE-2018-3639 (Speculative Store Bypass).  Their policy seems to be to roll the TCB upgrade to their test IAS instance before their production IAS instance. If you are running against test and we are running against production that would further suggest why you are seeing issues and we are not.

So it would be extremely useful to the SGX community at large if you could confirm your IAS instance type.  It wouldn't be an unreasonable assumption, from a DEVOPS perspective, if they were to roll test to production in which case, in which case things would get ugly very quickly in SGX land..... :-)

Hopefully all of the above makes sense and is of further assistance, we will look forward to your response.

Have a good day.

Dr. Greg

Apologies for not doing a complete grammar/spelling review on my post, too tired... :-)

Attachments: 

AttachmentSize
Downloadapplication/octet-stream pib.log412 bytes
Downloadapplication/octet-stream test-attestation.log7.44 KB

Hi Dr. Greg,

Thanks so much for your time! We really appreciate your help and we're getting closer to the truth! Here are some facts which may be helpful:

(1) We are using the test-as server.

(2) We use Compute Stick STK2M3W64CC (the m3 stick instead of m5) with bios version v0057 (Intel says it's the latest one to the public) released on 5/16/2018, before the disclosure of CVE-2018-3639.

(3) We use linux-sgx-sdk v2.2 on ubuntu 16.04 desktop.

So here are my understandings, and please correct me if I'm wrong:

(1) the CPU microcode update of CVE-2018-3639 is required by the test-as IAS service. However, the corresponding BIOS/microcode update hasn't been released.

(2) the production IAS service does not require this update. So our platform "should" work well on the production IAS service (but we don't have access to production service).

Thanks again!

Best,

Yu

Quote:

Greg W. wrote:

Hi Yu, I hope this note finds your day going well.

Thanks for forwarding along the diagnostic information.  It was helpful in better understanding the issue that you are running into.  At this point in time the most important information that would help clarify what is going on is whether you are using the test or production instances of IAS to generate the reports for the Compute Stick quotes?

We ran the Base16 encoded platformInfoBlobs from your ComputeStick quotes through our PIB decoding tool.  The IAS instance you are using is saying the same thing in all three instances, that security version of the CPU that generated the quotes was not consistent with the currently specified Trusted Computing Base (TCB) for the platform.

I'm attaching the output from the following command to this post:

./sgx-decode-pib -b 1502006504000100000505020401800000000000000000000007000006000000020000000000000AE066584E3E99C34056C7C566112BDCC13D4867E806A7FD7A79B10BF532ED07D5696FD4C5A45AD38A8FADBD43EDAA23114CBB3A5B397519DF84CBA644A7F2A8B3BD

As you can see in the output IAS indicates the CPU security version is out of date and recommends that the correct CPUSVN is as follows:

05050204018000000000000000000000

If I interpret your posting correctly the CPUSVN in your report is as follows:

0707ffffff0100000000000000000000

While the 128 bit field encoding is, to our knowledge, unspecified.  It has been our experience that the first couple of digits are linear with respect to higher, ie. more recent versions, of platform firmware.  That suggests that your ComputeStick is running something more recent then what the IAS is recommending as the correct CPUSVN TCB.

I'm attaching the output from a utility that we have in our PSW/SDK which generates an enclave report on the local host and submits that to IAS for verification.  I ran the utility on one of our STK2MV64CC ComputeSticks which is running the most current firmware as of early June.  As you can see in the log output production IAS indicates the CPUSVN TCB for the process is correct.  It is notable that your CPUSVN is roughly consistent with ours, at least in the leading digits which seems to roughly correlate with firmware version.

All of this takes us back to why we are asking about which IAS instance you are attesting against.  As I've noted previously our PSW/SDK follows a model where attestations are done by the enclaves themselves.  So the log is actually generated from inside of the enclave that generated the report.  Obviously we have OCALL's which implement the EPID loading and QE interactions since they cannot be done from inside of an enclave.  The OCALL's that execute the REST exchange with IAS are directed to the production IAS services.

If you look at the ISVSVN recommendation in your platform information report, ie. the quoting enclave security version, the instance of IAS you are using recommends 7.  If you look at the attachment that contains the debug output from our test attestation you will see that we receive a recommendation of 5.  There might be a possibility that Intel would recommend an alternate QE SVN depending on processor type but that seems highly unlikely given how they have set all of this up.

If we interpret your previous posts correctly you are seeing attestation failures across multiple platforms that you claim have all been upgraded to the latest firmware versions.  If whatever IAS instance you are using has its CPUSVN database out of kilter that would explain why you are seeing this issue across multiple platforms.  It would also explain why you are getting back a CPUSVN recommendation that seems entirely inconsistent with reality.

Intel sent out an SGX notification letter in late May indicating that a TCB upgrade would be conducted in order to address issues with their IPP cryptography and to reflect firmware upgrade requirements to address CVE-2018-3639 (Speculative Store Bypass).  Their policy seems to be to roll the TCB upgrade to their test IAS instance before their production IAS instance. If you are running against test and we are running against production that would further suggest why you are seeing issues and we are not.

So it would be extremely useful to the SGX community at large if you could confirm your IAS instance type.  It wouldn't be an unreasonable assumption, from a DEVOPS perspective, if they were to roll test to production in which case, in which case things would get ugly very quickly in SGX land..... :-)

Hopefully all of the above makes sense and is of further assistance, we will look forward to your response.

Have a good day.

Dr. Greg

Apologies for not doing a complete grammar/spelling review on my post, too tired... :-)

Hi Yu, I hope your day is going well.

Thanks for taking time to provide the feedback that you are using the test iAS instance.  We had anticipated that would be the case based on the results we are seeing.

If it would be possible, could you run an attestation report on quotes generated from two other different systems and capture the Base16 encoded Platform Information Report from the REST message, that will help confirm what we believe is happening.

With respect to the two questions you pose:

> (1) the CPU microcode update of CVE-2018-3639 is required by the test-as IAS service. However, the corresponding BIOS/microcode update hasn't been released.

> (2) the production IAS service does not require this update. So our platform "should" work well on the production IAS service (but we don't >have access to production service).

Based on the platform information reports from the ComputeStick, it doesn't appear the test IAS instance is returning a CPUSVN recommendation that makes any sense.  This suggests the test instance may be using at least a partially faulty CPU TCB database.  That is why it would be helpful to check the platform information reports generated by other hardware.

So I suspect your solution will work against the production IAS instance but to verify that we need to prove that the test IAS instance isn't working properly.  If our theories are correct and Intel is testing their planned TCB upgrade on the test IAS instance we need to figure out what is going wrong in order to prevent these possible anomalies from propagating to the production instance.

Hopefully all of the above is useful information.

We will look forward to any further feedback you have time to provide.

Dr. Greg

Leave a Comment

Please sign in to add a comment. Not a member? Join today