Developers Club geek daily blog

2 years, 9 months ago
About safety of UEFI, part final Here also my opus about safety of UEFI has come to end. In this final part it was necessary to talk about perspective technologies and plans for the future and to communicate to readers in comments.

If it is interesting to you, than safety of firmware can help STM, SGX and PSP — I wait for you under cat.

Wishing to show rebellious spirit and carelessness on tradition, I do not give the reference to the previous parts — look for them there.

Part seventh. Technologies of the future

In spite of the fact that all technologies described further are provided officially for a long time, all the same about them I will tell as about opportunities of tomorrow, for very prosaic reason — even as UEFI from representation of some technology before its implementation can pass in such high-growth environment years (enough to remember the PFAT which has appeared in Haswell, but is not implemented by sense still).

About SGX and STM I already mentioned in the end of the third part therefore I will begin the story with PSP with which now without options all are completed new AMD APU.

AMD Platform Security Processor

Watching progress of Intel Management Engine with which the last 5 years each chipset and SoC Intel is equipped, in AMD too have decided not to lag behind progress and to build in the Soc'i something such.

Still — there is a wish to have hardware root of trust, the normal random number generator there is a wish, the cryptoaccelerator and the TPM 2.0 emulator there is a wish, generally — there is a wish for everything much, and everything not difficultly to implement it — buy IP Core from any supplier, write to it firmware and hang on it more system functions that the user of your platform even has not taken in head to disconnect that, for what so much money is paid.

As a result as IP Core have bought ARM Cortex-A5 kernel with support of the TrustZone technology, for emulation of TPM 2.0 have got the TEE code at Trustonic, have implemented the rest and have presented the turned-out SoC - inside - Soc'a in 2013 on the next UEFI Plugfest.

About safety of UEFI, part final
The original scheme PSP, about emulation of TPM of the speech then did not go yet.

This PSP provides the following for safety of UEFI: HVB subsystem, internal storage for S3 BootScript, the TPM emulator for implementation Measured Boot, random number generator and the accelerator of cryptographic operations.

Hardware Validated Boot

About this technology I already told in the first part, now I will tell in more detail. The essence its simple — PSP receives management before start of BSP and checks that contents of the second stage of its firmware and starting code have not been changed, in case of success of BSP starts with ResetVector'a and the machine is loaded as usual, and in case of failure to the user show error code on the POST coder, and BSP twists dead cycle to hard reset'a after which everything repeats again.

HVB, thus, is hardware root of trust for system, but this technology only PEI volume, check of all the rest — on conscience of authors of firmware protects.

About safety of UEFI, part final
Original scheme AMD HVB

By default HVB is disconnected on all platforms and for inclusion is necessary its rather nontrivial configuring therefore I so far and itself did not test technology in practice (though directly I work with firmwares for second generation of processors with PSP), and machines with the included HVB in the open market did not see.

Integrated TPM 2.0

The working TCG group has prepared interesting innovation for Windows 10 release: instead of the TIS interface used earlier for interaction with TPM modules it is possible to use now ACPI calls that allows vendors of processors to implement TPM not on the external chip, and directly in chipset moreover and half of implementation to make program. Such solution has shortcomings (vendor lock-in) as advantage (more difficult to replace chipset, than the TPM chip in the SSOP-28 body), and, but have implemented it at the moment and Intel (in Skylake) and AMD (in APU with PSP). The TPM 2.0 standard is supported by both solutions not entirely but only so that the system with the built-in TPM could use BitLocker and receive the certificate of Windows 10 Ready. Nevertheless, now to regiment of users of TPM unambiguously will arrive. Together with the built-in TPM there was also hardware GSCh and the cryptoaccelerator which, at desire, it is possible to use separately.

Secure S3 BootScript Storage

One more counter of PSP — the built-in NVRAM in which it is possible to store some user data safely. At the moment AMD saves S3 BootScript there that well protects system from attacks to it. Thus output time from S3 suffers a little, but excess 50-100 ms for the sake of safety can quite be suffered.

Unfortunately, at AMD with open documentation for PSP it is very sad therefore I cannot give useful links, everything that could tell without violation of NDA — has already told.

Intel Software Guard Extensions

Let's return to the Intel technologies now. Have started speaking about SGX about a year ago, but it became available to the ultimate user all a few weeks ago when Intel has included it for Skylake processors in the next updating of microcode. SGX — is new set of the instructions allowing applications to create so-called "enclaves", i.e. the regions of memory for code and data which are hardware protected from access from the outside even if this access is made from more kernel modes of execution like ring 0 and SMM.

Technology rather difficult for understanding and use (nearly 200 Programming Reference pages), but potentially very powerful therefore Intel has started being engaged in its advance.

About safety of UEFI, part final
Schematic circuit of work of SGX, one of more than 200 slides of this presentation, it in the form of 80-minute video.

Intel calls SGX "the return sandbox", t.a instead of trying to isolate potentially harmful or not entrusted software, by means of the SGX program can isolate itself from all other world. The idea is similar to ARM TrustZone but if at ARM the world shares on normal and entrusted and they are executed on different kernels, interacting only through call of the instruction of SMC, at Intel kernel same, but memory shares normal and safe:

About safety of UEFI, part final
Safe enclave in the middle of conventional memory.

My attitude towards this technology for the present was not created — I simply did not try it yet since I do not work on Skylake at present. Nevertheless, I try not to lag behind progress too strongly therefore I read edge of ear everything that write about SGX, for example:
Portal about SGX on the site Intel.
Survey lecture about SGX from the site of Technical University of Darmstadt.
NccGroup review with heap of interesting links.
Open platform for writing of the code for SGX.
And in general, all section about SGX on

Intel SMI Transfer Monitor

The second Intel technology which I already mentioned — STM. The first references of it are dated 2009, and after 6 years of development the technology at last has been provided in August, 2015. Essence its simple: instead of the manager SMM in SMRAM the hypervisor is started, and all processors of SMI are executed in the virtualized environment that allows to prohibit them harmful actions like change of data in kernel memory and to that similar.

About safety of UEFI, part final
Slide from presentation of STM on IDF2015.

The technology allows to reduce considerably as "attack surface" on processors of SMM, and destructiveness of effects of cracking of processors of SMI. For example, having prohibited access to chipset MMIO for all processors, except used for updating of firmware, it is possible to protect it from other processors, way even they are cracked attacking and it has opportunity to execute in them any code.
The most important advantage — unpretentiousness, for work of STM only the included VT-x/AMDV and the correct settings of the permission access levels are necessary. At the moment preliminary support of STM is implemented in EDK2 only for test payment of MinnowBoard Max, but in the closest half a year-years of IBV adapt it for the platforms, and it will be possible to be afraid of cracking of SMM much less. It is clear that free safety does not happen, and STM enters additional complexity to so not the simplest process of initialization of SMM, plus processing of SMI takes more time (more terribly, actually, that it borrows even more than an indefinitely, users of rigid OSRV again suffer), plus the ignorant user of platform can disconnect virtualization and STM will not manage to be used in such conditions. Nevertheless, I potykat in STM branch on MinnowBoard and I can tell: rather IBV will implement it — the better.

Additional information for persons interested:
Vincent Zimmer's post with the announcement of STM.
Portal about STM on the site Intel, with useful links.


Well here this cycle of articles has also come to end, I hope to the reader it was interesting.
Technologies develop quickly and if tomorrow there is any disruptive technology (or will find the gaping hole in existing) — I will try to write about them.

In the following article we will subdue SecureBoot — we will generate the key of PK and KEK, and paranoids will be able to prohibit loading of any things which are not signed with their keys. Thanks for attention.

P.S. Promised the final table in the last part, but could not in it. To Kodit — I can, write in Russian — to and fro, it is beautiful to mark tables — there is no stone flower. I ask sincere to parton.

This article is a translation of the original post at
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here:

We believe that the knowledge, which is available at the most popular Russian IT blog, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus