About UEFI security, part final

That came to an end my safety opus UEFI. In this final part, it remains to talk about promising technologies and future plans, and chat with readers in the comments.

If you are interested in what security firmware can help STM , SGX and PSP - waiting for you under the cut.

Wanting to show rebellious spirit and spit on traditions, I don’t give references to the previous parts - look for them there yourself.

Part Seven. Technologies of the future

Despite the fact that all the technologies described below have already been formally presented for a long time, I will still talk about them as about the possibilities of tomorrow, for a very prosaic reason - even in such a rapidly developing environment as UEFI, from the presentation of some technology to its implementation years (it suffices to recall the PFAT , which appeared in Haswell, but not yet properly implemented).
')
I already mentioned SGX and STM at the end of the third part, so I’ll start the story with the PSP, which now includes all new AMD APUs without options.

AMD Platform Security Processor

Watching the success of the Intel Management Engine, which has been equipped with every chipset and Intel's SoC for the last 5 years, AMD also decided to keep up with the progress and embed it in their SoCs and something.

I would like to - I want to have a hardware root of trust, I want a normal random number generator, I want a crypto accelerator and TPM 2.0 emulator, in general, I want a lot of things, and it’s not hard to implement it - buy an IP Core from a supplier, write the firmware to it and add more system functions to it so that the user of your platform doesn’t even think to disconnect something for which so much money has been paid.

As a result, we purchased the ARM Cortex-A5 core with the TrustZone technology support as an IP Core, purchased TEE code for TPM 2.0 emulation from Trustonic, and implemented the rest ourselves and presented the resulting SoC-inside-SoC in 2013 at the next UEFI Plugfest.


The original PSP scheme, about TPM emulation, was not yet in circulation.

For UEFI security, this very PSP provides the following: HVB subsystem, internal storage for S3 BootScript, TPM emulator for implementing Measured Boot, random number generator, and cryptographic accelerator.

Hardware Validated Boot

I have already talked about this technology in the first part , now I will tell you in more detail. Its essence is simple - the PSP receives control before starting the BSP and checks that the contents of the second stage of its firmware and start code are not changed, if successful, the BSP starts with ResetVector and the machine boots as usual, and in case of failure the user is shown an error code on POST-coder, and BSP turns the dead loop to hard reset'a, after which everything repeats again.

HVB, therefore, is a hardware root of trust for the system, but this technology is protected only by PEI-volume, while checking the rest is on the conscience of the firmware authors.


Original AMD HVB circuit

By default, HVB is disabled on all platforms and its configuration is rather nontrivial, so I haven’t experienced the technology myself (although I’m working directly with firmware for the second generation of PSP processors), and I haven’t seen HVB machines on the open market .

Integrated TPM 2.0

For the release of Windows 10, the TCG working group prepared an interesting innovation: instead of using the TIS interface previously used to interact with TPM modules, you can now use ACPI calls, which allows processor manufacturers to implement TPM not on an external chip, but directly in the chipset, and even half of the implementation . This solution has both advantages (it is more difficult to replace the chipset than the TPM chip in the SSOP-28 package), as well as disadvantages (vendor lock-in), but Intel (in Skylake) and AMD (in the PSP APU) have also implemented it . The TPM 2.0 standard is supported by both solutions not entirely, but only so that a system with a built-in TPM can use BitLocker and get a Windows 10 Ready certificate. However, now the TPM users shelf will definitely arrive. Together with the built-in TPM, a hardware RNG and a crypto accelerator also appeared, which, if desired, can be used separately.

Secure S3 BootScript Storage

Another PSP feature is NVRAM integrated in which some user data can be safely stored. At the moment, AMD keeps back S3 BootScript, which protects the system from attacks on it. At the same time, the exit time from S3 suffers a little, but the extra 50-100 ms for the sake of security can be tolerated.

Unfortunately, AMD is very sad with open PSP documentation, so I cannot give useful links, I could tell everything I could tell without violating the NDA.

Intel Software Guard Extensions

Now back to the Intel technology. They started talking about SGX about a year ago, but it became available to the end user just a few weeks ago, when Intel turned it on for Skylake processors in the next microcode update. SGX is a new set of instructions allowing applications to create so-called. "Enclaves", i.e. memory regions for code and data that are hardware protected from outside access, even if this access is from more privileged execution modes like ring 0 and SMM.

The technology is quite complicated to understand and use ( almost 200 pages of the Programming Reference ), but potentially very powerful, so Intel began to promote it.


Schematic diagram of the work of SGX, one of more than 200 slides here of this presentation , it is also in the form of an 80-minute video .

Intel calls SGX a “reverse sandbox”; that is, instead of trying to isolate potentially malicious or untrusted software, the SGX program can isolate itself from the rest of the world. The idea is similar to the ARM TrustZone, but if the ARM world is divided into normal and trusted and they run on different cores, interacting only through the SMC instruction call, then the Intel core is the same, but the memory is normal and secure:


Secure enclave in the midst of conventional memory.

My attitude to this technology has not yet been formed - I just have not tried it yet, because I'm not working on Skylake at the moment. Nevertheless, I try to keep up with progress too much, so I read with the edge of my head everything that is written about SGX, for example:
SGX portal on Intel website .
Review lecture on SGX from the site of Darmstadt Technical University .
Review article NccGroup with a bunch of interesting links .
An open platform for writing your own code for SGX .
And in general, the whole section about SGX on firmwaresecury.com .

Intel SMI Transfer Monitor

The second Intel technology I mentioned is STM. The first mentions of it are dated 2009, and after 6 years of development, the technology was finally introduced in August 2015. Its essence is simple: instead of the SMM controller, an hypervisor is started in SMRAM, and all SMI handlers are executed in a virtualized environment, which allows them to prevent malicious actions like changing data in kernel memory and the like.


Slide from STM presentation on IDF2015.

The technology can significantly reduce both the "attack surface" on SMM handlers and the destructive effects of hacking SMI handlers. For example, by prohibiting access to the MMIO chipset for all handlers except the one used for updating the firmware, you can protect it from other handlers, the way even they are hacked by an attacker and he has the ability to execute arbitrary code in them.
The most important advantage is unpretentiousness; for STM operation, only the VT-x / AMDV included and the correct access level settings are needed. At the moment, preliminary support for STM is implemented in EDK2 only for the MinnowBoard Max test board, but in the next six months or a year IBV will adapt it for its platforms, and it will be possible to fear much less hacking of SMM. It is clear that free security does not happen, and the STM introduces additional complexity into the not so simple SMM initialization process, plus the SMI processing takes more time (more terrible, in fact, that it takes even more indefinite time, again hard users of RTOS suffer ), plus virtualization, the unknowable user of the platform can disable and STM will not work in such conditions. Nevertheless, I poked at STM with a branch on MinnowBoard and I can say: the sooner IBV implements it, the better.

Additional information for those who wish:
Post Vincent Zimmer with the announcement of STM .
Portal about STM on the Intel site, with useful links .

Conclusion

Well, this cycle of articles has come to the end, I hope the reader was interested.
Technologies are developing rapidly, and if some breakthrough technology emerges tomorrow (or if they find a gaping hole in the existing ones), I will try to write about them.

In the next article we will tame SecureBoot - we will generate our own PK key and KEK, and paranoids will be able to prohibit the download of any things that are not signed by their keys. Thanks for attention.

PS He promised in the last part of the final table, but could not in it. Coding - I can, write in Russian - back and forth, beautifully mark the table - there is no stone flower. I ask a sincere sorry.