Gigabyte анонсировала обновление BIOS, включающее поддержку TPM 2.0 на материнских платах AMD и Intel
Компания Gigabyte анонсировала запуск новой версии BIOS для материнских плат с чипсетами Intel и AMD. Обновление BIOS позволит включить функцию TPM 2.0, которая требуется для установки новейшей ОС Windows 11.
На текущий момент Gigabyte анонсировала обновление BIOS для плат серий Intel X299, C621, C232, C236, C246, а также плат с чипсетами 200-й, 300-й, 400-й и 500-й серий. В случае с AMD, обновление будет доступно на платах с чипсетами TRX40, а также 300-й, 400-й и 500-й серий. Иными словами, почти все современные платы Gigabyte будут поддерживать включение TPM 2.0 и, как следствие, возможность установки Windows 11.
Примечательно, что наличие модуля TPM 2.0 не обязательно для прохождения проверки на возможность установки Windows 11. Платы Gigabyte с обновлением BIOS смогут пройти верификацию Intel Platform Trust Technology даже без отдельного модуля TPM 2.0, т. е. программно. Таким образом, пользователи смогут установить Windows 11 на системах с материнскими платами Gigabyte при условии наличия поддерживаемого процессора.
Напомним, что Windows 11 появится позже в этом году. Предположительно, запуск ОС состоится в октябре. Gigabyte будет распространять свежую версию BIOS через официальный сайт. Следите за страницей поддержки вашей материнской платы, чтобы не пропустить релиз новой версии BIOS.
Как IOMMU работает для связи ЦП и периферийных устройств
Как периферийные устройства взаимодействуют с процессором? Использование ОЗУ системы в качестве общей точки для взаимной связи, но это подразумевает ряд механизмов, наиболее важным из которых является тот, который мы собираемся описать ниже.
Где находится IOMMU?
Как видно на схеме выше, периферийные устройства подключены к южному мосту или южному мосту, который, в свою очередь, подключен к северному мосту, который является концентратором, с которым, в основном, обмениваются данными интерфейс оперативной памяти и процессора. каждый. Что ж, IOMMU расположен внутри южного моста, где сосредоточены все интерфейсы ввода-вывода, такие как USB, PCI Express, SATA и т. Д.
Все эти интерфейсы должны находиться под управлением IOMMU для доступа к системной RAM. В этом случае IOMMU действует как своего рода пограничный контроль, который следит за тем, чтобы периферийные устройства не осуществляли незаконный доступ к памяти и не обращаются к той части ОЗУ, которая назначена каждому из них и никуда больше.
Таким образом, IOMMU действует как MMU, но для периферийных устройств ввода-вывода.
В чем его полезность?
Периферийные устройства ввода-вывода не используют MMU (блок управления памятью) совместно с ЦП и, следовательно, не просматривают память так же, как центральный системный процессор. Эта проблема позволяет периферийным устройствам получать доступ к чувствительным частям системной памяти, например тем, которые зарезервированы для функций самой операционной системы, что является проблемой в многозадачных средах.
С другой стороны, IOMMU автоматически и динамически назначает адреса памяти для связи с различными периферийными устройствами, таким образом, ЦП всегда знает, на какие адреса памяти он должен указывать для связи с ними.
В более старых системах IOMMU не было доступно, и вместе с ними была предоставлена карта памяти, где программисты были проинформированы, какие адреса RAM предназначены для связи с устройствами. По этой причине разработчикам в каждой отдельной архитектуре приходилось изучать адресацию памяти, чтобы использовать периферийные устройства и другое поддерживающее оборудование в системе.
Сегодня это уже не так, и наличие IOMMU позволяет разработчикам избавиться от необходимости изучать адреса памяти для связи и расширяет возможности конфигурации и настройки наших ПК, позволяя создавать совершенно разные конфигурации.
Использование IOMMU в виртуализированных системах
IOMMU обеспечивает безопасный доступ к физическим устройствам в виртуализированных средах посредством того, что мы называем сквозной передачей устройств. Тандем между MMU и IOMMU позволяет устройствам, подключенным к ПК, появляться в пространстве виртуальной памяти, которое выполняет функцию физической памяти для виртуальной среды, которая работает в данный момент.
Без IOMMU виртуализированные среды, которые имеют правильный доступ к оборудованию, установленному в системе, были бы невозможны, поэтому сегодня он является незаменимой частью всех процессоров, которым приходится обрабатывать виртуализированные среды.
Изучаем шифрование памяти в процессорах AMD, или как EPYC 7000 защищает ваше облако
Конфигурация тестового стенда:
Сегодня, когда обычные Cloud-системы трансформируются в гибридные облака, необходимо обеспечить одинаковый уровень безопасности как на локальном сервере, который стоит под тремя замками офисе компании, так и на удалённом виртуальном, о котором может быть не известно ничего кроме виртуальной конфигурации. При этом, число уязвимостей в корпоративном ПО, связанным с виртуализацией, растёт с каждым годом, а общая динамика числа новых уязвимостей по данным NIST (https://www.nist.gov/) растёт экспоненциально:
Подобные атаки, связанные с повышением прав доступа, могут использовать не только программные ошибки в коде ОС, но и аппаратные баги в архитектуре процессора, что подтверждается печальным опытом компании Intel, которая вынуждена закрывать уязвимости в своих Xeon-ах ценой снижения их производительности. Даже у нас в тестовых серверах на Intel Xeon используются операционные системы осени 2018 года (до появления Meltdown/Spectre), потому что патчи безопасности настолько сильно замедляют машину, что это уже мешает нормальному тестированию.
Но есть в мире одна компания, которая каждую новую уязвимость в процессорах Intel встречает под звон бокалов с шампанским и аплодисменты: это AMD, поскольку мало того, что их архитектура CPU не подвержена уязвимостям, связанным со спекулятивным исполнением команд, так ещё и их процессоры EPYC серии 7000 изначально разрабатывались для более высокого уровня безопасности при работе в изолированных средах: обычная и контейнерная виртуализация, то есть всё то, что сегодня наиболее востребовано в IT-бизнесе.
В общем-то, под громкими словами «технологии безопасности», скрываются два основных нововведения:
Для начала, я изучил предложение ны рынке облачных провайдеров на июнь 2019 года. Ни одна из знакомых мне компаний не афишировала какие-то особые технологии, касаемые безопасности. Процессоры AMD EPYC 7000 открыто предлагала в аренду (в составе физических серверов, конечно), только компания » Селектел «. И хотя эти CPU созданы для того, чтобы нарезать их на сотни виртуалок и продавать как сервис в виде контейнеров и VPS, их предлагают по принципу «разбирайтесь сами». Тогда я прямо спросил ведущих российских облачных провайдеров о том, где используется шифрование и шифруют ли они память?
Максим Захаренко, генеральный директор компании Облакотека (https://oblakoteka.ru/):
С шифрованием данных ситуация довольно непростая. Каналы передачи корпоративных данных практически всегда и по умолчанию шифрованные, а вот хранение дисков виртуальных машин в облаке чаще всего осуществляется в открытом виде. Связано это с тем, что расшифровка данных осуществляется на стороне облачного провайдера, то есть данные реально защищены только в момент, когда машина выключена. При этом есть, например, технология Shielded VMs от Microsoft. Она позволяет полностью изолировать виртуальную машину от доступа провайдера, но «Облакотека» использует кластерную организацию платформы, поэтому любое неосторожное движение, ошибки в обновлениях могут привести к утрате доступа к ВМ без возможности восстановления. Так что теоретически шифрование выглядит панацеей от угроз безопасности в облаке, а практически — мало используется. NDA, административные санкции к провайдеру, методы защиты платформы — всё это на сегодняшний день достаточно зрело и системно. Поэтому фактически нарушений безопасности в облаке существенно меньше, чем при размещении ИТ-инфраструктуры в офисе.
Шифрование ОЗУ не используем. Оперативная память – не самое интересное для атаки место, по крайней мере в наших сценариях.
Ну что же, придётся разбираться самостоятельно. Тем интереснее будет понять, почему целевая аудитория процессоров EPYC 7000 так прохладно отнеслась к технологии, которая призвана дать им конкурентное преимущество на весьма перегретом рынке. Как говорится, поехали!
OK, что есть у AMD для защиты памяти?
TSME включается в BIOS-е материнской платы, но будьте готовы, что у вас этой функции может и не быть, так как она конфликтует с другими методами шифрования, и производители её не афишируют. В нашей тестовой материнской плате ASRock Rack EPYCD8-2T она включается через скрытое меню в BIOS-е при нажатии CTRL+ALT+F3, но ни в инструкции, ни на сайте компании о её поддержке не было ни слова.
От каких напастей защищает TSME?
AMD SME
Вообще, с моей точки зрения, при наличии TSME, функция SME уже выглядит излишней, так как требует поддержки со стороны софта. На момент подготовки статьи, SME поддерживалась только семейством операционных систем Linux с ядром выше 4.14. Но в некоторых дистрибутивах для корпоративного пользователя, например, в Oracle Linux 7.6 на ядре 3.10, функция SME поддерживается и включена по умолчанию. В других же дистрибутивах для включения SME нужно добавить в строку загрузки (файл конфигурации grub) параметр mem_encrypt=on. Проверить работу SME можно выполнив команду в терминале:
вывод должен быть следующим:
[ 0.000000] AMD Secure Memory Encryption ( SME ) active
Аналогично TSME, эта функция защищает данные в памяти от атак, связанных с физическим доступом к памяти: кража NVDIMM, различные варианты Cold Boot с замораживанием модулей DIMM.
Чем SME лучше TSME?
Прежде всего, SME лучше своим механизмом обновлений: если для полностью аппаратного TSME все апдейты осуществляются только через перепрошивку BIOS, про который производитель материнской платы может позабыть, то в для SME компания AMD выпускает обновления для ядра Linux через репозитории GIT. Но эта информация скорее важна для разработчиков ПО, потому что сисадмину остаётся лишь обновлять операционную систему в обычном ритме, и быть уверенным, что в системе установлены все патчи, относящиеся к шифрованию.
Владимир Карагиоз, руководитель группы архитекторов по решениям Red Hat (https://www.redhat.com):
Гипервизор KVM и платформа виртуализации Red Hat Virtualization давно достигли зрелости и помогают тысячам наших клиентов в решении их задач. Мы активно задействуем аппаратные возможности, предоставляемые современными процессорами. В случае нахождения уязвимостей выделенная команда внутри Red Hat позволяет в максимально короткие сроки устранить их.
Ну и разумеется, при выборочном шифровании ОЗУ достигается более высокая производительность, так давайте протестируем скорость. Начнём с нереляционной базы данных Redis, используемой в качестве кэширующего сервера в памяти.
Вообще, хочу заметить, что на таких современных процессорах, как AMD EPYC с активной системой энергосбережения, 1-поточный Redis даёт огромную погрешность измерений, и в нашем случае включение SME всегда ускоряло работу системы. К счастью, в данном тесте для нас важнее, что какого-то ощутимого снижения ни в операциях GET, ни в SET при включении шифрования не происходит.
При тестировании реляционной базы данных MySQL 5.7.26, я решил сменить Oracle Linux 7.6 на Ubuntu 18.04, используя Read-Only паттерн для двух таблиц по 10 000 записей в каждой.
Скажем так: я искал разницу в производительности в приложениях, интенсивно использующих ОЗУ, и не нашёл её. Небольшие различия в показателях можно смело списать на погрешность измерений, так что если вы устанавливаете выделенный сервер для базы данных, будь то NoSQL кэш или SQL база, то шифрование ОЗУ скорость не украдёт. Есть исследования, показывающие, что снижение скорости растёт с увеличением датасета. Я проводил тест MySQL с базой данных объемом 2.7 Гб (12 миллионов записей) и аналогично не заметил влияние TSME на скорость. Вообще, учитывая конфигурацию процессора EPYC 7551p (32 ядра по 2 ГГц), он больше подходит не для сервера под одно приложение, а для облака!
SEV: жемчужина всей защиты AMD
AMD позаботилась и о таком виде атак: функция Security Encryption Virtualization (SEV) обеспечивает шифрование области ОЗУ, выделенной под виртуальную машину, независимо от гипервизора. Каждая виртуалка использует собственный ключ, и ни root администратор, ни хакеры, использующие атаки на повышение прав, не смогут прочитать содержимое дампа памяти вашей виртуальной машины. Причём, функция AMD SEV работает независимо от TSME / SME, и на одном физическом сервере вы можете совмещать как обычные виртуальные машины, так и их варианты с индивидуально зашифрованной памятью, а какое-либо приложение, запущенное на хосте, может использовать шифрование SME.
Будь вы клиент или провайдер облачных услуг, вам важно запомнить, что с механизмом AMD SEV виртуалка в облаке защищена не только от хакеров извне, но и от хозяина сервера. Практически мы говорим о том, что любые атаки на кэши или механизмы префетчинга архитектуры AMD EPYC, не имеют смысла, так как в лучшем случае хакер получит данные в зашифрованном виде. Однако, как показала практика, исследователи смогли её обойти, но об этом чуть позже.
Подайте ложку дёгтя!
Вообще, у AMD есть хороший репозиторий на GITHub со скриптами установки SEV-окружения на SLES-15, RHEL8, Fedora 28(29) и Ubuntu 18.04 с примером запуска зашифрованной гостевой виртуальной машины. Следует заметить, что поскольку Virtual Manager и virsh не поддерживают AMD SEV, запуск и остановка виртуалок производятся командами из графической оболочки гипервизора, то есть окружение рабочего стола должно быть предустановлено и запущено.
Поддерживается ли AMD SEV в контейнерах?
Да, AMD гордится тем, шифрование ОЗУ для виртуалок реализовано в Open-source проекте Kata Containers (https://katacontainers.io), разрабатываемом сообществом OpenStack Foundation. Данная платформа имеет открытую поддержку на операционных системах Clear Linux, Fedora и CentOS 7, она используется такими интернет-гигантами как JD.Com, поддерживает оркестраторы Docker и Kubernetes, и при этом обеспечивает безопасность на том же уровне, что и виртуальные машины.
Фактически, архитектура Kata такова, что контейнеры запускаются внутри SEV-шифрованных виртуальных машин. Это, конечно, не так приятно и не так безопасно как в случае с индивидуальным шифрованием в гипервизоре, но в мультитанантных архитектурах, предлагающих услуги Caas (Container as a Service) вы можете шифровать, например, виртуальный узел, выделенный на клиента. Опять же, одну и ту же услугу можно предлагать как с повышенным уровнем безопасности, так и с традиционным, подгоняя свой маркетинг под запросы клиентов.
Влияние AMD SEV на производительность
Продолжим наше тестирование с помощью Redis 4.9 на платформе Ubuntu 18.04 с гипервизором QEMU из репозитория AMDSEV. В качестве гостевой ВМ использовалась та же Ubuntu 18.04 с 8 Гб ОЗУ и 64 ядрами. Не сравнивайте эти результаты с предыдущими: разные версии Linux и Redis отличаются по скорости почти в два раза.
Да, мы видим, как QEMU отжирает около 15% производительности системы, но при этом включение шифрования памяти не имеет сколько-нибудь существенного влияния на скорость. Перейдём к тестированию операций чтения в MySQL, используя 2 таблицы по 10 000 записей из общей базы данных, содержащей 12 таблиц по 1 миллиону записей, общим объёмом 2.7 Гб.
И впервые удалось увидеть заметное снижение скорости при использовании шифрования в MySQL, запущенной внутри SEV-машины. Обратите внимание: при отключенном шифровании разницы в производительности нет.
Пожалуй, надо сделать вывод по поводу производительности: я не увидел какой-то слабости контроллеров памяти и механизма шифрования. На транзакционных нагрузках, характерных для баз данных, разницу в скорости нужно искать днём с огнём, но вот софт, его версии и качество компиляции влияют на производительность сильнее, чем что-либо другое. Так что для лучшей скорости компилируйте всё из исходников под свои параметры.
Что есть у конкурента?
К слову, у Intel тоже есть похожая технология SGX, но работает она совершенно иначе. Во-первых, у «сине-белых» это чисто программная фишка, использующая вычислительную мощность ядер, во-вторых, Intel шифрует данные не на уровне виртуальной машины, а на уровне приложения. Это означает, что вы, например, можете зашифровать всю память гипервизора и всех его гостевых операционных систем, но это не спасёт от атаки типа VM Escape, а можете зашифровать только одну базу данных в каком-нибудь контейнере. Давайте сравним возможности Intel и AMD:
Tsme что это в биосе
Secure Memory Encryption (SME) is an x86 instruction set extension introduced by AMD for page-granular memory encryption support using a single ephemeral key. A subset of SME, Transparent SME (TSME), is a more limited form of SME used to transparently encrypt the full physical memory. Secure Encrypted Virtualization (SEV) extends SME to AMD-V, allowing individual VMs to run SME using their own secure keys.
On its Ryzen Pro processor families, AMD brands TSME as Memory Guard.
Contents
Motivation [ edit ]
Servers host a great deal of data including large sets of private client information. When stored in main memory in plain text, this data can be exposed to various user access attacks such as administrators scraping memory of guest data or a hypervisor bug allowing hosted guest to steal data from neighboring guest virtual machines. Furthermore, data stored in DRAM in plain text can be susceptible to physical access attacks allowing data to be stolen, especially for devices such as NVDIMMs.
The SME extension attempts to defend against those attacks by allowing the entirety of main memory to be encrypted as well as by enforcing full isolation between co-resident VMs. With the addition of SEV, this security can be extended to cloud users that can have fully private memory inaccessible to hypervisor or host software.
Overview [ edit ]
SME was proposed by AMD in their white paper in April 2016. SME adds the ability to mark individual pages of memory as encrypted through the page tables. Any marked page will automatically be encrypted on write and decrypted back when read by software.
Secure Memory Encryption [ edit ]
Secure Memory Encryption (SME) provides the ability for software to mark certain pages to be encrypted. Marked pages are automatically decrypted and encrypted upon software read and write. All pages are encrypted using a single 128-bit ephemeral AES key which is created randomly using a hardware random generator at each boot and is not accessible by software. A new key is generated by the processor on every boot.
Transparent SME [ edit ]
Transparent SME (TSME) as the name implies is a stricter subset of SME that requires no software intervention. Under TSME, all memory pages are encrypted regardless of the C-bit value. TSME is designed for legacy OS and hypervisor software that cannot be modified. Note that when TSME is enabled, standard SME as well as SEV are still available. TSME and SME share a memory encryption key.
Secure Encrypted Virtualization [ edit ]
Secure Encrypted Virtualization (SEV) is an extension of SME that effectively enables a per-virtual machine SME. In other words, SEV enables running encrypted virtual machines in which the code and data of the VM are private to the VM and may only be decrypted within the VM itself.
Mechanism [ edit ]
SME is typically enabled by BIOS or other firmware at boot time. This is done by setting the appropriate MSR bit to 1. Once activate, software can simply set the encryption C-bit (enCrypted) on the desired page. It’s worth noting that the location of the C-bit is actually implementation-specific and must determined by making the appropriate CPUID call. Pages with a C-bit set to 1 go through the encryption engine and are stored encrypted in memory. Likewise, pages with a C-bit set to 0 go directly to memory. This means unencrypted pages do not incur any added latency because of this feature. It’s worth noting that encryption I/O pages are not allowed and must have a C-bit of 0.
If SEV is supported and enabled, on each SEV-enabled VM, SME mode is enabled with that VM-specified encryption key. Under SEV, the ASID field in the page table is used as the key index that identifies which encryption key is used to encrypt and decrypt the memory traffic associated with that VM. SEV-enabled VMs can control their own C-bit for memory pages they want encrypted. This allows those VMs to determine which pages are private (C-bit = 1) or shared (C-bit = 0). The location of that C-bit is the same location as defined under SME. It’s worth noting that this control is limited to data page. In other words, memory accesses such as guest page tables and instruction fetches are always private, regardless of the value of the C-bit (i.e., in those cases the C-bit is a don’t care). This was done in order to ensure that non-guest entities such as the hypervisor itself cannot inject their own code into the SEV-enabled guest VM. If the C-bit is an address bit, this bit is masked from the guest physical address when it is translated through the nested page tables. The hypervisor itself does not need to be aware of which pages the guest VM marked as private. For example, a guest accessing a particular virtual address will get translated to a specific physical address with the C-bit set to 1 indicating the page should be encrypted. A specific virtual address is then used for the translation and the C-bit value from the guest physical address is saved and used on the final physical address after the nested table translation took place.
SEV may be used in conjunction with SME. Under this scenario, each SEV-enabled VM controls its own encryption via the C-bit and the host page tables control the encryption for shared memory.
| Encryption Control | ||||||
|---|---|---|---|---|---|---|
| Access Type | SME | Guest | SEV | Encrypted | Key Owner | Note |
| All | ✘ | X | X | No | N/A | SME Disabled |
| All | ✔ | ✘ | X | Optional | Host Key | Determined by page tables C-bit |
| All | ✔ | ✔ | ✘ | Optional | Host Key | Determined by nested page tables C-bit |
| Instruction Fetch | ✔ | ✔ | ✔ | Yes | Guest Key | C-bit ignored |
| Guest page table access | ✔ | ✔ | ✔ | Yes | Guest Key | C-bit ignored |
| Nested page table access | ✔ | ✔ | ✔ | Optional | Host Key | Determined by nested page tables C-bit |
| Data access | ✔ | ✔ | ✔ | Optional | Host/Guest Key | Determined by guest page tables and nested page tables C-bits |
Key management [ edit ]
Note that key management is actually managed by a separate processor AMD calls the AMD Secure Processor or AMD-SP for short which is present on SEV-enabled chips. Therefore, while a hypervisor can manage the virtual machine keys through the AMD-SP, the actual software is unaware of the key values and cannot access them.