I have two qustions,
1. Is the Intel Xeon servers are still not supported with Platform Service? Does it include, absence of ME as well?
2. What could be the reason for this design decision?
If this is a repeat question, then providing a link with answers will also suffice.
Thanks in advance,
Server platforms are usually managed via the BMC (base manageability controller) and usually have a server firmware to support the standard (?) datacenter management model. Platform services are based on client hardware, not server hardware. So no, Platform Services and ME are not generally included on server platforms. Some Xeon based workstations do have ME/Platform Services, though, just as an FYI. Are there specific functions you are trying to accomplish?
Thanks for the reply. That helps.
I have one more question, if the server enclave (ring 3) wants to perform a timed calculation then from where it gets a timer/counter or to be precise what are the alternatives of get_trusted_time() or get_trusted_counter() of PSE in server environment?
Again, if I am missing any part of the documentation or any link that answers my questions then pointing me to the correct link will suffice.
In an enclave running on a server platform, there currently is no way to get a "trusted" time. Some CSPs who require trusted time are utilizing a remote/centralized trusted time source in their solutions, so that may be an option for your usage. I think it would depend on how fine grained you need the time. For counters, some use the TPM, though to be clear, there is also currently no secured path between a TPM and an enclave.
Hope this helps.
Good morning, I hope this note finds the weekend going well for everyone.
As the SGX software ecosystem begins to develop, the issues in this thread will become more important. Now that I have my head back above water, I thought a few amplifications on top of Scott's reflections may be useful to the SGX development community.
We have been working to address these types of infrastructure issues in our Secure Runtime Development Environment (SRDE). The philosophy that it adopts is that a well balanced SGX security architecture will embrace TPM technology to fill in the blanks which are architecturally precluded or absent in an SGX enclave environment. The comments in this thread about XEON server class platforms not having access to platform services and the general problems that users seem to have with getting MEI and platform services to work indicates the need for an alternative approach.
Intel has already moved forward to address this problem, one would presume because of the XEON server issues, by enabling access to the RDTSC instruction inside of enclaves as part of the SGX2 architecture. Due to time constraints around the first public demonstration of the SRDE, I have not had time to run down the architectural details, but I'm assuming that a constant TSC value is being returned inside of an enclave, perhaps Scott would be kind enough to verify that. If so, enclave authors will have a reliable source of time and a monotonicity reference on these platforms with a resolution of the reciprocal of the processor frequency.
We have verified this functionality on the SGX2 platforms that we are developing on. For an architecturally sound solution one would want to use processor affinity to keep an enclave thread that was relying on TSC accuracy on the same processor. Although, and Scott can clarify this, anything at the SGX2 level should have a microarchitecture that has constant TSC values across all the cores in a die. Given what appears to be the general elusiveness of multi-socket SGX, constant TSC values across die cores should be sufficient for the intermediate future.
On a related note, given the most recent paper from Graz, the impending availability of RDTSC inside of enclaves should have security architects factoring this into their risk and threat analysis.
RDTSC obviously suffers from the same problem inside of enclaves as it does elsewhere, ie. the notion of making things non-portable. As a result there is a solid case to be made that TPM technology will be the gold standard moving forward with respect to monotonicity, so a few reflections on that issue, based on our implementation work in the SRDE.
Given the Windows 10 requirements, anything that has SGX will also have access to a TPM, either in the form of hardware or a firmware implementation, ie. Platform Trust Technology. On desktop and similar systems, PTT can be looked at essentially as a standardized replacement for the MEI, where one has to bring one's own plumbing.
TPM2 will be the only game in town for these systems and it brings a fairly rich spectrum of support for secured timing which translates into a secured source of monotonicity. As Scott noted, one has to be cautious about verifying that an enclave is accessing a secured variant of the time source, but I believe the case can be made that there is a functionally secure path to the time source.
For those who would like to clarify their understanding of these issues I would recommend the following as a canonical reference:
Interested parties should review the TPM2_GetTime and TPM2_ReadClock primitives.
Internally, a TPM2 device maintains clock information that tracks time in milliseconds. There is a global timer available as well as a timer that records milliseconds since the last platform reset. The global timer is persisted in NVram so there is an assurance of time continuity across platform resets. There are also counters for the number of resets the platform has been exposed to as well as a restart count. In addition, there is a 'safe' flag that indicates whether or not a time value greater then the current time value has been returned by the device.
To Scott's point, the TPM2_ReadClock command returns all of this information but is not a 'trusted' source. The TPM2_GetTime command is the mechanism for accessing time information in a secured fashion. It requires that the caller submit the handle to a signing key that the TPM will use to generate a quote against the returned time and clock information data structure. A cautious security architect would obviously want to use various SGX based mechanisms at their disposal to verify that the entire construction was not being spoofed by a simulator.
Unfortunately, TPM2_GetTime is on the 'optional' command list with respect to hardware support. We have had one older SGX platform whose TPM2 device did not support the command, but that is the only instance we have run into. I believe the Intel PTT implementation supports TPM2_GetTime universally, once again that is something that Scott may be kind enough to verify for the benefit of the SGX security architecture community.
For all intents and purposes, the TPM2_GetTime is essentially command 'sugar' since TPM2 based quotes have time and clock information embedded into them and available via the TPMS_TIME_ATTEST_INFO structure returned by the TPM2_Quote command. So an enclave author can always get access to timing information by requesting a quote against one of the Platform Configuration Registers, which largely accomplishes what the TPM2_GetTime command would accomplish. As a note of caution to security architects, in the interests of privacy, the firmware, restart and reset values are 'obfuscated' if the signing key is not derived from the endorsement or platform heirarchies, but that doesn't affect the elapsed time counters which are of the most interest with respect to monotonicity.
So I believe the case can be made that all functionally useful SGX platforms have 'trusted' timing information available to them. The focus of our SRDE is to provide a 'toolbox', if you will, that has a lot of this functionality all packaged up and ready to go so that platform architects can rapidly build out SGX based security architectures, particularly for the embedded and intelligent network endpoint device space.
However, if you are good with a C compiler, all of this is pretty much straight forward.
As always, best wishes for a pleasant remainder of the weekend.