topic I am not sure why you think in Intel® Software Guard Extensions (Intel® SGX)

Timestamp Cycle Counter (TSC)

Amr_A_ — Mon, 04 Sep 2017 19:32:28 GMT

Hi All,

I would like to ask about accessing the timestamp cycle counter (TSC) from an enclave.

Is it going through the OS or Is it a direct access to the register hardware?.

Is there any example code for using it?

Regards

Amr

Hello Amr,

Hoang_N_Intel — Tue, 12 Sep 2017 14:57:47 GMT

Hello Amr,

Here is an excerpt from the SGX manual on this question:

RDTSC and RDTSCP are legal inside an enclave for processors that support SGX2 (subject to the value of CR4.TSD).
For processors which support SGX1 but not SGX2, RDTSC and RDTSCP will cause #UD.
RDTSC and RDTSCP instructions may cause a VM exit when inside an enclave.
Software developers must take into account that the RDTSC/RDTSCP results are not immune to influences by other
software, e.g. the TSC can be manipulated by software outside the enclave.

Please refer to section of "39.6.1 Illegal Instructions" in the System Programming Guide at

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3d-part-4-manual.pdf

for more info.

Thanks,

Hoang

Hello Hoang,

Amr_A_ — Tue, 12 Sep 2017 16:00:30 GMT

Hello Hoang,

Thanks a lot for your reply. I wil take a careful look into that.

Regards

Amr

To add some more info:

Francisco_C_Intel — Tue, 12 Sep 2017 21:53:24 GMT

To add some more info:

If you want to call RDTSC, you'll need to create an OCALL and get that information (I don't believe there aren't any SGX2 processors in the market right now).

Regardless of whether you are using an SGX1 system with an OCALL or an SGX2 system without an OCALL, remember (as Hoang points out) that

"RDTSC/RDTSCP results are not immune to influences by other software, e.g. the TSC can be manipulated by software outside the enclave."

Hi Francisco

Amr_A_ — Tue, 12 Sep 2017 22:04:17 GMT

Hi Francisco

Thanks for your reply. So, RSTSC is not trusted. and what I got also that sgx_get_trusted_time API is only available during the simulation mode.

So is there any way of getting source sense of time within SGX?

Regards

Amr

I am not sure why you think

Francisco_C_Intel — Wed, 13 Sep 2017 03:27:06 GMT

I am not sure why you think trusted time is only available in simulation - you can use it in actual HW mode too.

Here's the Linux source for it:

https://github.com/01org/linux-sgx/blob/1115c195cd60d5ab2b80c12d07e21663e5aa8030/sdk/tae_service/tae_service.cpp

You'll need "trusted services" on your system (Management Engine SW)

Hi Francisco,

Amr_A_ — Wed, 13 Sep 2017 05:26:32 GMT

Hi Francisco,

First of all, I really can't thank you enough. Your replies are extremely helpful for me.

The Developer reference manual in 2016 states that "sgx_get_trusted_time" API is only available in the simulation mode. However, I see that they removed this comment in 2017 version !!. So you are right, It could be used in Hardware. Also, as a verification, I tried the SealedData example in hardware mode, as it has this API, and it looks working fine for me.

However, I see that this API is only useful in getting the relative trusted time between two calls as long as the returned nonces are constant, otherwise, it is not useful. So I do not think it gives a secure system time (Linux time), It is only helpful in getting a relative trusted time between two calls. This is what I got until now. Is that right?

Also, I tried very hard to look into the idea behind it. How can they guarantee such secure feature? Is there a dedicated hw timer or what? Do you have any idea?

Thanks again for your great support.

I am having a hard time

Francisco_C_Intel — Wed, 13 Sep 2017 20:25:20 GMT

I am having a hard time finding external documentation for the details on this. It uses the PSDA service:

https://github.com/01org/linux-sgx/tree/1115c195cd60d5ab2b80c12d07e21663e5aa8030/psw/ae/pse/pse_op

I don't think you can trust the Linux time. Is there a specific reason you need to know Linux time as opposed to time since you last called "get secure time"?

Thanks a lot Francisco for

Amr_A_ — Wed, 13 Sep 2017 20:52:09 GMT

Thanks a lot Francisco for your time and support. What I got that sgx_get_trusted_time is only useful in getting relative time. For example, if we want to get the Execution_time of "some code", we will do the following:

(Time1 , nonce1 ) = sgx_get_trusted_time().
// some code goes here
(Time2 , nonce2 ) = sgx_get_trusted_time().

if( nonce1 == nonce2)
Execution_time = Time2 - Time1
else
//no trusted execution time can be obtained

So as you see, It does not give us like UTC time or any global time. We need to build application that has trusted notion of global Time like UTC which can be the linux time. My questions can be summarized in the following:

1- Do you suggest something to do to get more information on how they made sgx_get_trusted_time ? I can't find anything useful too:(.

2.Also, Do you have on mind an idea on how we can get Trusted UTC time?

Thanks again

Amr

1. Recently posted - https:/

Francisco_C_Intel — Tue, 26 Sep 2017 17:46:18 GMT

1. Recently posted - https://software.intel.com/sites/default/files/managed/1b/a2/Intel-SGX-Platform-Services.pdf

2. I think you may need to go out to the network (or to the system) via a (trusted) secure channel or something like that. You really can't get the time from the system directly, since by design the system isn't trusted.

Hi Francisco,

Amr_A_ — Tue, 26 Sep 2017 17:49:04 GMT

Hi Francisco,

Thanks a lot for your reply and support

I recently figured out that

Fatima_A_ — Tue, 19 Dec 2017 18:49:50 GMT

I recently figured out that in the sgx_get_trusted_time API execution flow which is,

App Enclave <->AESM(untrusted)<-> PSE enclave(trusted) <-> AESM <->CSE/ME(trusted)

even if all the data is encrypted, there is a chance that a malicious Operating System can delay the packet through the IPC communication between App Enclave and AESM. If a packet can be delayed, then the encrypted time value inside the packet will no longer make sense. So my question is, Is it possible for an OS to delay the packet between AESM and App enclave? If yes, then sgx_get_trusted_time can no longer be trusted. Kindly correct me if I am wrong?