UEFI Security Final Part

    So my opus on UEFI security has come to an end. In this final part, it remains to talk about promising technologies and plans for the future, and talk to readers in the comments.

    If you are interested in how STM , SGX and PSP can help firmware security, I ’m waiting for you under the cut.

    Wanting to show rebellious spirit and spit on traditions, I do not 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 been officially presented for a long time, I’ll still talk about them as tomorrow’s opportunities, for a very prosaic reason - even in such a fast-growing environment as UEFI, it can go from presenting some technology to its introduction years (it’s enough to recall the PFAT , which appeared in Haswell, but has not yet been properly implemented).

    I already mentioned SGX and STM at the end of the third part, so I’ll start the story with PSP, which now includes all new AMD APUs without options.

    AMD Platform Security Processor

    Watching the success of the Intel Management Engine, which each chipset and Intel SoC has been equipped with over the past 5 years, AMD also decided to keep up with the progress and build something like that in their SoCs.

    I would like to have the 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 difficult to implement all this - buy IP Core from some vendor, write the firmware for it and hang on it with more system functions so that the user of your platform doesn’t even decide to turn off something for which so much money has been paid.

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


    The original PSP circuit, about emulating TPM, wasn’t talking then.

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

    Hardware Validated Boot

    I already talked about this technology in the first part , now I’ll talk in more detail. Its essence is simple - PSP takes control before the start of BSP and checks that the contents of the second stage of its firmware and start code are not changed, if successful, BSP starts with ResetVector and the machine boots as usual, and in case of failure, the user is shown an error code on POST encoder, and BSP spins the dead cycle to hard reset, after which everything repeats again.

    HVB, therefore, is the hardware root of trust for the system, but this technology only protects the PEI volume, and checking everything else is on the conscience of the authors of the firmware.


    Original AMD HVB circuit

    By default, HVB is disabled on all platforms and its configuration requires quite non-trivial configuration, so I haven’t tested the technology myself yet (although I work directly with firmware for the second generation of processors with PSP) and I haven’t seen any machines with HVB enabled on the open market .

    Integrated TPM 2.0

    The TCG working group prepared an interesting innovation for the release of Windows 10: instead of the TIS interface used earlier, ACPI calls can now be used to interact with TPM modules, which allows processor manufacturers to implement TPM not on an external chip, but directly on the chipset, and even make half the implementation software . This solution has both advantages (replacing the chipset is more difficult than a TPM chip in the SSOP-28 package) and disadvantages (vendor lock-in), but Intel (in Skylake) and AMD (in APU with PSP) have implemented it now. . The TPM 2.0 standard is not fully supported by both solutions, but only so that a system with integrated TPM can use BitLocker and receive a Windows 10 Ready certificate. However, now a shelf of TPM users will definitely arrive.

    Secure S3 BootScript Storage

    Another PSP feature is the built-in NVRAM, in which you can safely store any user data. At the moment, AMD saves there S3 BootScript, which protects the system from attacks on it. At the same time, the exit time from S3 suffers a little, but an extra 50-100 ms for the sake of security can be endured.

    Unfortunately, AMD with open documentation on the PSP is very sad, so I can’t give useful links, I already said everything that I could tell without violating the NDA.

    Intel Software Guard Extensions

    Let's get back to Intel technology. They started talking about SGX about a year ago, but it became available to the end user only a few weeks ago when Intel turned it on for Skylake processors in the next microcode update. SGX is a new set of instructions that allow applications to create so-called "Enclaves", i.e. memory regions for code and data, hardware-protected from external access, even if this access is made 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.


    SGX working principle, one of more than 200 slides of this presentation ,she's in the form of an 80-minute video .

    Intel calls SGX the “reverse sandbox,” that is, instead of trying to isolate potentially malicious or untrusted software, using SGX, the program can isolate itself from the rest of the world. The idea is similar to ARM TrustZone, but if the ARM world is divided into the normal and trusted ones and they are executed on different cores, interacting only by calling the SMC instruction, then Intel has the same core, but the memory is divided into the usual and safe:


    Safe enclave in the middle of the usual memory.

    My attitude to this technology has not yet been formed - I just have not tried it yet, because I am not working on Skylake at the moment. Nevertheless, I try to keep up with the progress too much, so I read all that they write about SGX, for example:
    Portal about SGX on the Intel website .
    Overview lecture about SGX from the site of Darmstadt Technical University .
    NccGroup review article with tons of interesting links .
    An open source code writing platform for SGX .
    In general, the entire SGX section on firmwaresecury.com .

    Intel SMI Transfer Monitor

    The second Intel technology that I already mentioned is STM. The first mention of it dates back to 2009, and after 6 years of development, the technology was finally introduced in August 2015. Its essence is simple: instead of the SMM manager, a hypervisor is launched in SMRAM, and all SMI handlers are executed in a virtualized environment, which allows them to be prevented from malicious actions like changing data in kernel memory and the like.


    Slide from STM presentation at IDF2015.

    The technology can significantly reduce both the "attack surface" on SMM processors and the destructive consequences of hacking SMI processors. For example, by denying access to the MMIO chipset for all processors except the one used to update the firmware, you can protect it from other processors, even they are cracked by an attacker and he can execute arbitrary code in them.
    The most important advantage is unpretentiousness, for the operation of STM, only the included VT-x / AMDV and the correct settings for access levels are needed. At the moment, preliminary STM support 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 their platforms, and there will be much less fear of hacking SMM. It is clear that there is no free security, and STM introduces additional complexity into the not so simple SMM initialization process, plus SMI processing takes longer (it’s worse, in fact, it takes even more indefinite time, users of hard RTOS suffer again ), plus virtualization, an unaware platform user can turn off and STM cannot be used in such conditions. However, I poked a STM thread on MinnowBoard and can say:

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

    Conclusion


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

    In the next article, we will tame SecureBoot - we will generate our PK and KEK keys, and paranoids will be able to prohibit the downloading 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. Cod - I can, write in Russian - back and forth, beautifully laid out tables - a stone flower does not come out. I ask sincere sorry.

    Also popular now: