SIGMA S2 integrity error when calling sgx_create_pse_session()

[madsen__frederik]

Hello

Whenever I call sgx_create_pse_session() I get the error code 0x400a (SGX_ERROR_BUSY).

However, I don't think the problem is actually that the PSE is busy, since when I check the aesm service log, this is the output:

aesm_service[603]: [ADMIN]Platform Services initialization failed due to DAL error
aesm_service[603]: [ADMIN]Platform Services initializing
aesm_service[603]: [ADMIN]EPID Provisioning initiated
aesm_service[603]: [ADMIN]EPID Provisioning successful
aesm_service[603]: PCH EPID RL retrieval failure
aesm_service[603]: DAL SIGMA error
aesm_service[603]: SIGMA S2 integrity error

This seems to me to be an error related to EPID Provisioning.

The funny thing is that I could call sgx_create_pse_session() successfully about 5 months ago.  I took a break from sgx programming, and when I tried to run the same app, the problem materialized.

The fact that I was previously able to successfully call sgx_create_pse_session() should mean that my CPU was already provisioned, right? Therefore I think it has something to do with the protocol which verifies my EPID.

The DAL SIGMA error has lead me down a path of Intel ME drivers, as I believe DAL refers to Intel Dynamic Application Loader. I have installed the latest of the Intel Management Engine Components drivers, and even gone as far as dual-booting a Linux distro to verify that the problem persists across operating systems and different drivers (I usually run Windows 10). The log above is from Linux, but the log on Windows is very similar.

Have any of you experienced something similar, or do you have an idea on how to fix this?

Thanks in advance :)

[Carlyle__Alan]

I'm have the same happening on my Inspiron 5567 Windows 10 Pro (OS Build: 10.0.16299 N/A Build 16299​, BIOS: Dell Inc. 1.2.4, Processor: Intel64 Family 6 Model 142).

Well it hasn't corrected this problem I found other problems I had may have been caused by having a poor mix of Dell and Intel diver versions. I had a the Intel Management Engine ahead of the version currently supplied by Dell for my machine. After rolling back to the preferred versions and repairing a failing Dell service my other problems stopped appearing in the Event Log (which I hope means they are fixed).

Yet this AESM Service​ DAL warning (not error) has stuck around. Not much to go on in the event message, though another warning event just prior was "AESMService: White List update failed due to network error​". This doesn't bother me much as I was not connected to the network when the machine started so of course any network connection would fail. 

​As an aside;
Why are we getting so many drivers and applications that assume the network must be connected and panic when it isn't? Wouldn't it be simple to just check if they require the network, and possibly internet, and if it isn't there wait patiently and calmly until it is. The worst offenders seem to just keep hammering await all confused they aren't getting anywhere, kind of like Sheldon knocking on Penny's door. (Apologies for the excusive anthropomorphism). You would thing it would make sense to code services that require the network (and internet) to check its there before doing anything and if not setting up an event listener for when it does become available. The even message posted need only be a simple and nice info one of; 'Waiting for network (and internet) to be connected. Will start my work when available.', rather than a panic it can't resolve a DNS address followed by errors that it didn't get the data it wanted fast enough, then going into a critical meltdown (tantrum) it was treated so rudely, well basically a Sheldon.