AMD Secure Technology (или ранее называвшуюся Platform Security Proccessor — PSP).
AMD Secure Technology (или ранее называвшуюся Platform Security Proccessor — PSP).
К омпания AMD, также встраивает в свои процессоры ( аналогичную MЕ ) систему AMD Secure Technology (раньше называвшуюся PSP ), начиная с 2013 года.
Вскоре после исправления уязвимости SA-00086, производители материнских плат для процессоров AMD стали поставлять обновления BIOS, позволяющие отключить AMD Secure Technology, эту схожую с Intel ME подсистему.
Компания AMD постоянно старается улучшить работу своих процессоров Ryzen с помощью выпуска регулярных выпусков обновления протокола AGESA. Новая версия AGESA приносит не только поддержку материнским платам с Socket AM4 будущих процессоров AMD, но также добавляет возможность отключить встроенный Secure Processor, также известный, как «процессор для обеспечения безопасности платформы» или просто PSP.
AMD Secure Processor является аналогом Intel Management Engine. Этот встроенный процессор безопасности AMD был тоже подвергнут критике, как один из возможных векторов атаки, которые невозможно обнаружить на уровне операционной системы. Процессор PSP использует технологию ARM TrustZone для хранения конфиденциальных данных, и позволяет получить удалённый доступ к системе авторизированным администраторам.
В свете недавно выявленных уязвимостей в Intel Management Engine, компания AMD, похоже, решила добавить в новую версию AGESA возможность отключения Secure Processor пользователем через BIOS. Некоторые пользователи Reddit обнаружили, что при обновлении BIOS в нём появилась настройка, позволяющая включить или отключить PSP.
С ростом количества мобильных устройств и облачных служб компьютерная среда претерпевает постоянные изменения. Растет и число угроз конфиденциальности и безопасности — они приобретают все более разнообразный и изощренный характер. Только антивирусной программы уже недостаточно для надежной защиты. Теперь необходимо надежное аппаратное решение. Встроенная система безопасности на базе технологии AMD Secure защищает непосредственно процессор. Работая совместно с обширной сетью поставщиков платформ, AMD старается обеспечить максимальной защитой всю свою продукцию.
Появилась система безопасности, встроенная в аппаратное обеспечение — AMD предлагает технологию AMD Secure Processor1 в некоторых гибридных процессорах AMD. Технология ARM® TrustZone® с системным подходом к безопасности исполняет роль защитного «слоя» на оборудовании, создавая безопасную среду за счет разделения центрального процессора на два виртуальных «мира». Важные задачи выполняются в «безопасном мире» AMD Secure Processor, а другие задачи — в обычном режиме. Это помогает обеспечить надежное хранение и обработку важных данных и проверенных приложений. Кроме того, это помогает защитить целостность и конфиденциальность таких ключевых ресурсов, как пользовательский интерфейс и материалы поставщиков услуг. Но AMD тоже отклонила запросы на открытый исходный код, который работает на PSP.
PSP похож на Intel Management Engine для процессоров Intel. Еще в сентябре 2017 года исследователь безопасности Google Сфир Коэн сообщил об уязвимости AMD в подсистеме PSP, которая может позволить злоумышленнику получить доступ к паролям, сертификатам и другой конфиденциальной информации.
В марте 2018 года израильская компания по информационной безопасности, связанная с PSP, объявила о нескольких предполагаемых серьезных недостатках в процессорах AMD Zen с архитектурой AMD ( EPYC , Ryzen , Ryzen Pro и Ryzen Mobile), которые могли позволить вредоносным программам работать и получать доступ к конфиденциальным данным.
AMD объявила об обновлениях прошивки для устранения этих недостатков, их обоснованность с технической точки зрения была подтверждена независимыми экспертами по безопасности, которые рассмотрели раскрытия.
AMD так описывает технологию защиты: «Secure Processor (ранее — процессор для обеспечения безопасности платформы, PSP) является выделенным процессором с технологией ARM TrustZone, а также программной защищённой средой Trusted Execution Environment (TEE), призванной обеспечить работу доверенных приложений сторонних разработчиков. AMD Secure Processor — технология на базе аппаратных средств, которая обеспечивает безопасную загрузку с уровня BIOS до среды TEE. Доверенные приложения сторонних разработчиков могут задействовать стандартные программные интерфейсы, чтобы воспользоваться защищённой средой TEE (функции защиты TEE работают не во всех приложениях).
Новые уязвимости можно быдо разделить на четыре основные категории. Все они по сути позволяют злоумышленникам нацелиться на самый защищённый сегмент процессора, который имеет решающее значение для хранения конфиденциальной информации на устройстве. Определить вредоносный код, хранящийся в Secure Processor, почти невозможно. Зловред может располагаться там годами и не быть обнаруженным — информировали независимые эксперты по безопасности.
Некоторые пользователи компьютеров и ноутбуков, построенных на платформе AMD, при открытии диспетчера устройств могут обнаружить там некое устройство с названием AMD PSP 3.0 Device, требующее установки драйвера. Код у него PCI\VEN_1022&DEV_1456.
Далеко не каждый знает что это за устройство и где взять для него драйвер.
Аббревиатура PSP в данном случае расшифровывается как Platform Security Processor. Это отдельный процессор для защиты программного обеспечения компании AMD. Используется в работе антивирусов, а также защищает некоторые компоненты операционной системы от вредоносного воздействия. Является аналогом Intel Management Engine и также требует установки драйвера. Он входит в состав комплекта драйверов для чипсета.
Сам драйвер нужно скачивать с официального сайта поддержки производителя материнской платы или ноутбука, определив конкретную модель. Обычно он располагается в разделе «Чипсет» (Chipset).
Что такое AMD PSP и как он работает в вашем процессоре
Нет не то AMD выпустила консоль PSP. Это аббревиатуры AMD Платформа Безопасность процессор , также известная как AMD Secure Technology, и это безопасная среда выполнения, которую AMD интегрировала в свои процессоры. С 2013 , как только Intel делает со своей системой CSE. В этой статье мы расскажем вам почему эта система есть и как это работает в вашем процессоре AMD, и почему это важно перед лицом участившихся уязвимости .
По мере развития технологий становится все легче находить уязвимости и, следовательно, все труднее защищаться от них, особенно когда мы говорим о процессорах, «мозге» ПК. По этой причине и в попытке минимизировать риски и избежать проблем AMD создала собственную среду безопасности под названием AMD PSP или AMD Secure Technology, которая была интегрирована во все процессоры AMD и APU с 2013 года.
Что такое AMD PSP (процессор безопасности платформы)?
Как мы уже объясняли, PSP — это не аббревиатура от PlayStation Portable (который также, но не относится к AMD), но, в данном случае, процессор безопасности платформы, который также официально известен как Технология AMD Secure or Технология AMD Secure , Это механизм, интегрированный на аппаратном уровне в свои процессоры, который обеспечивает безопасную среду при выполнении любого типа приложения, чтобы предотвратить выполнение вредоносного программного обеспечения, которое может повредить оборудование или вызвать утечки информации .
Как мы уже упоминали ранее, эта технология работает аналогично Intel CSE, но имеет огромное различие, а именно в случае AMD он работает на аппаратном уровне а не уровень программного обеспечения. Согласно определению AMD, «Создается безопасная среда, которая разделяет ЦП в два «виртуальных мира», позволяющих выполнять самые деликатные задачи на этом защищенном процессоре, в то время как остальные выполняются в «мировом» стандарте. Это помогает обеспечить безопасное хранение и обработку конфиденциальных данных и надежных приложений, а также защитить целостность и конфиденциальность ключевых ресурсов. «
По сути, AMD PSP — это встроенная в процессор подсистема защищенной среды выполнения. Он отвечает за создание, мониторинг и поддержание среды безопасности, и в его обязанности входит управление последовательностью загрузки ПК, запуск механизмов, связанных с безопасностью, и мониторинг системы на предмет любых подозрительных действий или событий, а также принятие соответствующих мер реагирования на них.
Этот маленький процессор внутри процессора имеет свой собственный ROM и SRAM Память изолированы от остальных системы, чтобы избежать любого типа атаки или утечки информации, содержащейся в нем. Кроме того, согласно AMD, он имеет встроенный сопроцессор для шифрования данных в соответствии с алгоритмами всех видов (они перечислены на рисунке выше).
Это предотвращает все уязвимости?
Точно нет. Фактически, в сентябре 2017 года аналитик безопасности Google сообщил об уязвимости в самой системе AMD PSP, в результате которой злоумышленник может получить доступ к паролям, сертификатам и другой конфиденциальной системной информации с помощью собственной системы безопасности AMD. Хорошая часть заключается в том, что AMD быстро исправила эту проблему простым обновлением прошивки.
В марте 2018 года израильская охранная компания допросила архитектуру AMD Zen (используемую в процессорах Ryzen, EPYC, Ryzen Pro и Ryzen Mobile), которая утверждала, что им удалось «внедрить» вредоносное ПО в саму систему AMD. PSP, это снова было исправлено AMD через обновление прошивки.
Короче говоря, это система, которая помогает повысить безопасность и избежать уязвимостей, но она не является надежной. Хорошая часть состоит в том, что, как мы видели в двух предыдущих примерах, AMD достаточно легко решает любой тип проблемы, поскольку преимуществом является то, что эта безопасная среда работает на аппаратном уровне.
A quick overview
The PSP consists of five major components. The BootROM (aka. the «On-Chip Bootloader»), the Initial Program Loader/IPL (aka. the «Off-Chip Bootloader»), the AMD Generic Encapsulated Software Architecture (AGESA) bootloader, the secure OS, and the Cryptographic Co-Processor (CCP).
The BootROM’s primary responsibility is to verify and load the Initial Program Loader (IPL) from the SPI flash. This is done through AMD’s hidden «PSP firmware filesystem», which consists of a Firmware Entry Table (FET) at various potential fixed offsets in the flash [6]. The FET then contains the offsets of the PSP and BIOS directory tables, which in turn contain entries for all the necessary firmware and data blobs. These «files» can be compressed, signed, and encrypted. As a general rule, all firmware-related files will be compressed and signed at a minimum, and later iterations also encrypted.
The IPL acts as the bootloader kernel and runs in EL1 (which is equivalent to ring0 on an x86 CPU). It mainly handles debugging functionality for AMDs internal use (diagnostics mode), setting up page tables and other things required for userspace, and providing system calls (svcs) for userspace to do sensitive actions (like loading and verifying firmware from flash or doing crypto operations) [7]. In this way, the IPL or off-chip loader is the «kernel» of the bootloader until everything is initialized and the secure OS is executed.
After the bootloader is initialized, the AGESA bootloader (or «ABL») is the first piece of code to run in userspace (EL0, equivalent to ring3 on x86). It consists of the ABL0 firmware, which then loads and executes ABL1-7. What these ABL stages do is out-of-scope for this post, but mostly they’re responsible for training the DRAM, loading the System Management Unit (SMU) for power management and sensory functionality, setting up the BIOS, and performing other steps necessary for x86 to run.
Once ABL is finished, the only thing left is to launch into the secure OS or TEE kernel. This replaces the entirety of SRAM and overwrites the IPL. This is the operating system that x86 will talk to over MMIO to facilitate access to things like the CCP, SEV API, and (f)TPM.
Binding all of this together is the Crypto Co-Processor (CCPv5). The CCP is an on-die proprietary Intellectual Property (IP) block that can perform AES, SHA, RSA, ECC, true RNG, and zlib inflate operations. It is also used as a DMA copy engine via passthrough, which is how the BootROM and IPL load data from the flash. While this is considered part of the PSP, it’s actually somewhat isolated, and certain data can be locked in the CCP and be made unreadable even to the PSP itself. The CCP is its own beast and deserves a dedicated blog post, which will be published soon.
MMIO Madness
The PSP is doing some low-level operations and has to talk to various devices to do tasks. While the SPI flash and CCP are prime among them, there are also things like the chipset (aka. «Fusion Controller Hub» or FCH), on-die One-Time-Programmable (OTP) fuses, timers, interrupt controllers, dedicated TPM (if one is present) and others. All of this has to fit into the 32-bit address space provided by the Cortex-A5. At the heart of all of this is Memory-Mapped I/O (MMIO).
Here’s what the address space looks like for the 1_0.8.0.84 AGESA capsule.
As you can see, SRAM is just one small part of the address space. You’ll often see references to «SMN» and «Syshub» in this writeup as well as in PSP code. SMN stands for the «System Management Network», and like the PSP itself, it’s barely documented. At its core though, it’s a network for talking to other devices on or connected to the System-on-Chip (SoC). These slots are initialized and configured via the MMIO region, which will map SMN/SYSHUB addresses to Advanced eXtensible Interface (AXI) addresses for the PSP.
AXI is an on-die interconnect bus protocol for communicating with internal IP blocks, and was developed by ARM. It makes sense we’re seeing it here, as the PSP needs to communicate with various IP blocks including timers, Memory Management Units (MMUs), and various others.
Where SMN is used for interacting with SoC devices, Syshub is used for getting views into x86 DRAM and the FCH/chipset. It also maps to AXI addresses.
Syshub / X86 slots
Let’s look at how this works more closely. There are two notable functions here, MapSysHub (which is used in most places such as the above) and MapSysHubFchMMIO , which is used for things like secure RTC and postcode writes:
These functions invoke the same internal function but with slightly different arguments.
Mapping
We can assume map arguments one and two hold the Syshub address/handle, the third argument is some kind of type, and the fourth is an unknown set of flags. Below is my reversing of the internal function (some things cut for brevity).
Here we can see that there’s a total of 15 slots. Slots 0-7 can be used for non-mmio (DRAM) access, whereas slots 8-14 are reserved for MMIO to the FCH. There’s also some code to keep track of which slots are free and the flags attached. Since the PSP is a single-threaded unicore environment, there’s no locking for these accesses (though memory barriers are used).
The physical address you want to access is encoded as a «frame number». It’s similar to physical page frame numbers (PFNs) if you’re familiar with that concept, but instead of a page number that you get by dividing by the page size, this frame number is the physical address / 64MB (the Syshub slot size).
When these registers in the MMIO space are written to, the AXI controller will see it and map the requested Syshub address to the X86 memory slots, which are 64MB ( 0x4000000 ) in size. In AXI, the slot base is at 0x04000000 . This gives a final address range of 0x04000000 to 0x40000000 , which is a massive portion of the address space.
Below is a diagram of the process of what’s going on here.
Unmapping
Unmapping is trivial and simply involves writing zero to the relevant MMIO registers. The only thing it seems to worry about is a bad actor in the PSP userspace using a syscall to unmap a security-critical region.
POST codes
As an example of where Syshub is used, it’s ultimately how POST codes are written to the chipset via the LPC bus. Port 0x80 is accessible from physical address 0xfffdfc000080 .
You may notice the POST codes are 32-bits wide, which you might find puzzling as most postcode displays that motherboards and card readers have only show 8 bits / 2 digits. There are two possibilities here:
- The chipset and motherboard vendor filter and/or translate these POST codes to 8-bit POST codes.
- Only the trailing 8 bits are shown, and the upper 24 bits are truncated. This would somewhat make sense as the lowest 8 bits are the most significant, and the upper bits are mostly used for prefixing which phase the boot is in. For example, IPL POST codes are prefixed with 0xee00. , and ABL POST codes are prefixed with 0xea00. .
A full list of the PSP and ABL POST codes can be found publicly documented [5] [6].
SMN Slots
SMN slots work in a similar way to the Syshub slots, though they’re much smaller. For this, we’ll look at ReadFuseBits() , which maps the data encoded into on-die fuses. In this specific case, it’s called by the InitSecureUnlock routine, which will check if the ‘secure unlock’ mode is disabled via fuses. Presumably this secure unlock is related to debugging and the secure unlock fuses are blown on retail CPUs, thus only allowing engineering-binned CPUs to access it on the stock firmware.
The ReadFuseBits function is fairly simple:
Mapping
We’re back in 32-bit land, so only one 32-bit arg is supplied for the SMN address. Since this type of memory is less complicated, fewer MMIO registers are involved.
At first glance it looks like there are 64 slots, however, it’s not quite that simple. For example, if slot is 1, the index to MMIO is (0x20 — 0x1) >> 1 << 2 == 0x3C . Slot 2 also resolves to 0x3C . Slot 3 then resolves to 0x38 , the same for slot 4, and so on. In practice, we have 16 MMIO slots. Judging from this code and some work by PSPReverse researchers, it seems each MMIO slot can control two SMN slots. This gives the ability to have 32 SMN slots mapped at any point in time.
As opposed to Syshub’s 40MB slots, SMN’s are relatively small at only 1MB ( 0x100000 ). The AXI slot base is 0x1000000 , which gives the SMN slot range as 0x1000000 to 0x3000000 , which goes up to the MMIO region boundary.
Unmapping
Just like Syshub, unmapping is simply reversing this process and zeroing the MMIO registers. In the interest of not reiterating to death, I’m going to skip it.
Memory Layout (SRAM)
With SMN and syshub discussed, that covers most of the non-SRAM address space. There are a few other devices like timers and such mapped into MMIO as well as the CCP, but as I mentioned earlier this deserves its own focus and won’t be covered here.
This leaves us with SRAM, which is likely more familiar territory for most. You can consider this as the «RAM» of the PSP (it can’t use DRAM as it hasn’t been initialized yet!).
IPL Page Tables
One of the first things the IPL or off-chip bootloader does is initialize page tables via the Translation Table Base Control Register (TTBCR) and Translation Table Base Registers (TTBR), and set up the Domain Access Control Register (DACR).
It sets up a boundary size of 4KB on TTBR0 and disables the Translation Lookaside Buffer (TLB) on TTBR1. The page table itself is at SRAM address 0x14000 in this particular version. By looking at setup_page_tables() , we can figure out how the memory is laid out.
We can see that for the most part, virtual addresses are 1:1 with physical addresses. Interestingly, while the IPL has write-protected pages for code, the user pages are mapped as read/write for code as well as data. I’m not sure why this is, it’s possible these entries are changed later via syscall handling. Regardless we can see the privilege separation and address ranges:
- 0x00000 — 0x15000 are privileged pages, with the first 14 pages being reserved for code and the last 7 for data.
- 0x15000 — 0x3D000 are user pages, all of which are (at least initially) read/write.
- 0x50000 — 0x52000 are some kind of shared virtual mapping that userspace has a read-only window into.
PSPReverse discovered the BootROM is mapped at high address ranges ( 0xFFFF0000 ) and doesn’t get mapped into SRAM, leaving the IPL to be loaded at SRAM address 0x0 . The last page of SRAM (the amount of which varies depending on the chip) is reserved for the BootROM service page, which contains various information such as the AMD public RSA key, the number of CCXs (Core Complex), number of cores per CCD (Core Chiplet Die), and other hardware info.
Putting this all together, we have a rough SRAM layout as follows:
AGESA (ABL) Loading
By looking for postcode writes and some helpful strings, we can find where the PSP switches into user mode and executes AGESA. Here’s a snippet of HLIL from the function I’ve dubbed ExecAGESA() :
In the above screenshot, g_abl0_addr is initialized to 0x15000 earlier in the boot process. jump_to_abl0() does a switch to user mode and jumps to the ABL0 entry point which is immediately after the PSP file header at 0x15100 (for more info on the PSP file header, see the Coreboot documentation linked at the bottom of the post and PSPTool) [6].
From this point, we’ve exited supervisor mode (EL1) and we’re running in user mode (EL0). ABL0 acts as the userspace bootloader and bootstraps the loading and execution of ABL1-7 via syscalls.
ABL0 will always remain mapped and active while ABL1-7 are running, so it also needs its own space. ABL1-7 are loaded to 0x16100 with the entry point at 0x16200 . The first argument to the entry point is the stack address, which is set to 0x2f900 .
There are a few other interesting things of note here. For one thing, which ABLs get run depends on the boot mode (which it gets via syscall). If the system is in a sleep state (S3/S0i3), only ABL4 or ABL7 as a fallback needs to run. From any other state (ie. cold-boot from S5), multiple stages need to be run, in order of 1 -> 5 -> 2 -> 6 -> 3 . I must admit that I expected the ABL stages would be run in ascending order, but it seems not. I believe this order also depends on the chip and isn’t fixed across all AMD microarchitectures.
Precisely what each stage does would require reversing the AGESA code and is out-of-scope here. I will say however that ABL4 and 7 seem to be for re-setting clock speeds via the System Management Unit (SMU) and performing memory tests. Stuff like DRAM training doesn’t take place.
Conclusion and Takeaways
The PSP is an essential piece of technology in AMD CPUs, and many are blissfully unaware of its existence. It’s not something most people need to care about for using their PCs or writing software. However, because of the undocumented nature and encryption being utilized on the firmware, it’s also been scare mongered about as some kind of super backdoor. Without a doubt, the PSP has extremely powerful capabilities, with the ability to talk to any device sitting on the SMN and virtually arbitrary access to DRAM.
A compromised PSP can be an intriguing target. Access to basically all memory and the ability to DMA over everything with the CCP can be incredibly useful, especially if you’re trying to bypass something like secure virtualization (SEV) and virtualization-based security (VBS). Keys and other secrets can also be leaked or exfiltrated via something like PSPReverse’s SP glitch attack [8].
The technology involved though is what interested me the most, and there are other things I want to talk about that just can’t fit into this already long post. So keep a lookout for follow-ups!
О безопасности UEFI, часть заключительная
Вот и подошел к концу мой опус о безопасности UEFI. В этой заключительной части осталось поговорить о перспективных технологиях и планах на будущее, да пообщаться с читателями в комментариях.
Если вам интересно, чем безопасности прошивки могут помочь STM , SGX и PSP — жду вас под катом.
Желая показать бунтарский дух и наплевательство на традиции, ссылки на предыдущие части не даю — сами ищите их там.
Часть седьмая. Технологии будущего
Несмотря на то, что все описываемые далее технологии уже давно представлены официально, рассказывать о них я все равно буду как о возможностях завтрашнего дня, по весьма прозаической причине — даже в такой быстроразвивающейся среде как UEFI от представления какой-то технологии до ее внедрения могут пройти годы (достаточно вспомнить PFAT , появившуюся еще в Haswell, но не внедренную толком до сих пор).
Про SGX и STM я уже упоминал в конце третьей части, поэтому начну рассказ с PSP, которым теперь без вариантов комплектуются все новые AMD APU.
AMD Platform Security Processor
Наблюдая за успехами Intel Management Engine, которым последние 5 лет оборудован каждый чипсет и SoC Intel, в AMD тоже решили не отставать от прогресса и встроить в свои SoC’и чего-нибудь эдакого.
Еще бы — хочется иметь аппаратный корень доверия, хочется нормальный генератор случайных чисел, хочется криптоускоритель и эмулятор TPM 2.0, в общем — много всего хочется, и реализовать это все не трудно — купи IP Core у какого-нибудь поставщика, напиши к нему прошивку и навесь на него побольше системных функций, чтобы пользователь твоей платформы даже не вздумал отключить то, за что столько денег уплочено.
В итоге в качестве IP Core купили ядро ARM Cortex-A5 с поддержкой технологии TrustZone, для эмуляции TPM 2.0 приобрели у Trustonic код TEE , остальное реализовали сами и представили получившийся SoC-внутри-SoC’а в 2013 году на очередном UEFI Plugfest.
Оригинальная схема PSP, про эмуляцию TPM речи тогда еще не шло.
Для обеспечения безопасности UEFI этот самый PSP предоставляет следующее: подсистему HVB, внутреннее хранилище для S3 BootScript, эмулятор TPM для реализации Measured Boot, генератор случайных чисел и ускоритель криптографических операций.
Hardware Validated Boot
Про эту технологию я уже рассказывал в первой части, теперь расскажу более подробно. Суть ее простая — PSP получает управление до старта BSP и проверяет, чтобы содержимое второй стадии его прошивки и стартового кода не было изменено, в случае успеха BSP стартует с ResetVector’а и машина загружается как обычно, а в случае неудачи пользователю показывают код ошибки на POST-кодере, а BSP крутит мертвый цикл до hard reset’а, после которого все повторяется заново.
HVB, таким образом, является аппаратным корнем доверия для системы, но защищает эта технология только PEI-том, проверка же всего остального — на совести авторов прошивки.
Оригинальная схема AMD HVB
По умолчанию HVB отключен на всех платформах и для включения необходима достаточно нетривиальное его конфигурирование, поэтому я пока и сам не испытывал технологию на практике (хотя непосредственно работаю с прошивками для второго поколения процессоров с PSP), и машин с включенным HVB на открытом рынке не видел.
Integrated TPM 2.0
К релизу Windows 10 рабочая группа TCG подготовила интересное нововведение: вместо использовавшегося ранее интерфейса TIS для взаимодействия с модулями TPM теперь можно использовать вызовы ACPI, что позволяет производителям процессоров реализовать TPM не на внешнем чипе, а прямо в чипсете, да еще и половину реализации сделать программной. Такое решение имеет как преимущества (заменить чипсет сложнее, чем чип TPM в корпусе SSOP-28), так и недостатки (vendor lock-in), но реализовали его на данный момент и Intel (в Skylake) и AMD (в APU с PSP). Стандарт TPM 2.0 поддерживается обоими решениями не целиком, а только настолько, чтобы система со встроенным TPM могла использовать BitLocker и получить сертификат Windows 10 Ready. Тем не менее, теперь полку пользователей TPM однозначно прибудет. Вместе с встроенным TPM появились также аппаратный ГСЧ и криптоускоритель, которые, при желании, можно использовать отдельно.
Secure S3 BootScript Storage
Еще одна фишка PSP — встроенный NVRAM, в котором можно безопасно хранить какие-то пользовательские данные. На данный момент AMD сохраняет туда S3 BootScript, что хорошо защищает систему от атак на него. При этом немного страдает время выхода из S3, но лишние 50-100 мс ради безопасности вполне можно терпеть.
К сожалению, у AMD с открытой документацией на PSP очень грустно, поэтому дать полезных ссылок не могу, все, что мог рассказать без нарушения NDA — уже рассказал.
Intel Software Guard Extensions
Вернемся теперь к технологиям Intel. Об SGX начали говорить около года назад, но для конечного пользователя она стала доступна всего несколько недель назад, когда Intel включила ее для процессоров Skylake в очередном обновлении микрокода. SGX — это новый набор инструкций, позволяющих приложениям создавать т.н. «анклавы», т.е. регионы памяти для кода и данных, аппаратно защищенные от доступа извне, даже если этот доступ производится из более привилегированных режимов исполнения вроде ring 0 и SMM.
Технология достаточно сложная для понимания и использования (почти 200 страниц Programming Reference), но потенциально очень мощная, поэтому Intel начала заниматься ее продвижением.
Принципиальная схема работы SGX, один из более 200 слайдов вот этой презентации, она же в виде 80-минутного видео.
Intel называет SGX «обратной песочницей», т.е вместо того, чтобы пытаться изолировать потенциально вредоносное или недоверенное ПО, при помощи SGX программа может изолировать себя от всего остального мира. Идея сходна с ARM TrustZone, но если у ARM мир делится на обычный и доверенный и они выполняются на разных ядрах, взаимодействуя только через вызов инструкции SMC , то у Intel ядро одно и то же, зато память делится обычную и безопасную:
Безопасный анклав посреди обычной памяти.
Мое отношение к этой технологии пока еще не сформировалось — я ее просто еще не пробовал, т.к. не работаю над Skylake в данный момент. Тем не менее, стараюсь не отставать от прогресса слишком уж сильно, поэтому читаю краем уха все, что пишут про SGX, к примеру:
Портал об SGX на сайте Intel.
Обзорная лекция об SGX с сайта Дармштадтского Технического Университета.
Обзорная статья NccGroup с кучей интересных ссылок.
Открытая платформа для написания своего кода для SGX.
И вообще, весь раздел про SGX на firmwaresecury.com.
Intel SMI Transfer Monitor
Вторая технология Intel, о которой я уже упоминал — STM. Первые упоминания о нем датированы 2009 годом, и после 6 лет разработки технология наконец-то была представлена в августе 2015. Суть ее простая: вместо диспетчера SMM в SMRAM запускается гипервизор, и все обработчики SMI выполняются в виртуализованном окружении, что позволяет запретить им вредоносные действия вроде изменения данных в памяти ядра и тому подобные.
Слайд из презентации STM на IDF2015.
Технология позволяет значительно уменьшить как «поверхность атаки» на обработчики SMM, так и разрушительность последствий взлома обработчиков SMI. К примеру, запретив доступ к MMIO чипсета для всех обработчиков, кроме используемого для обновления прошивки, можно защитить ее от остальных обработчиков, путь даже они взломаны атакующим и он имеет возможность выполнить в них произвольный код.
Самое главное преимущество — неприхотливость, для работы STM нужны только включенные VT-x/AMDV и правильные настройки уровней доступа. На данный момент предварительная поддержка STM реализована в EDK2 только для тестовой платы MinnowBoard Max, но в ближайшие полгода-год IBV адаптируют ее для своих платформ, и взлома SMM можно будет опасаться гораздо меньше. Понятно, что бесплатной безопасности не бывает, и STM вносит дополнительную сложность в итак не самый простой процесс инициализации SMM, плюс обработка SMI занимает больше времени (страшнее, на самом деле, то, что оно занимает еще более неопределенное время, опять страдают пользователи жестких ОСРВ), плюс виртуализацию незнающий пользователь платформы может отключить и STM не получится использовать в таких условиях. Тем не менее, я потыкал в STM веткой на MinnowBoard и могу сказать: чем скорее IBV внедрят её — тем лучше.
Заключение
Ну вот и подошел к концу этот цикл статей, надеюсь читателю было интересно.
Технологии развиваются быстро, и если завтра появится какая-то прорывная технология (или найдут зияющую дыру в существующих) — постараюсь о них написать.
В следующей статье будем укрощать SecureBoot — сгенерируем свои ключ PK и KEK, а параноики смогут запретить загрузку любых вещей, не подписанных их ключами. Спасибо за внимание.