Разговоры об аппаратной защите пользовательской информации процессорами AMD EPYC начались еще два года назад. Поэтому нельзя сказать, что защита памяти и виртуальных сред, доступная сегодня в серверных процессорах AMD с архитектурой Zen, стала полной неожиданностью. На Гиках/Хабре об этом можно прочитать в анонсе EPYC, в блоге ESET NOD32 и в гуляющих по интернету презентациях Дэвида Каплана из AMD. Архитектуру подобного рода защит детально описал CodeRush в статье «О безопасности UEFI», за что ему особая благодарность. Это действительно был взгляд в будущее.
Серверная плата ASUS KNPP-D3 с двумя процессорами AMD EPYC 7551 в корпусе RS700A-E9-RS4 поддерживает набор фирменных технологий криптозащиты от Advanced Micro Devices
Когда появилась возможность нам исследовать системную плату ASUS KNPP-D32 с двумя EPYC 7551, встала задача определиться с особенностями реализованной там криптозащиты. Не в последнюю очередь потому, что сложно представить иное использование такой платформы, кроме как в виде общежития для виртуальных машин. Все это хозяйство, упакованное в 1U стоечный корпус с терабайтом памяти о 64-х процессорных ядрах, – хорошая иллюстрация высокого удельного веса вычислительных возможностей. (При щадящем режиме потребления электроэнергии, кстати сказать).
Защита пользовательских данных видится в компании AMD как триединая задача, состоящая из шифрования памяти (Secure Memory Encryption), шифрования виртуальных сред (Secure Encrypted Virtualization) и шифрования процессорного контекста (Encrypted State). Второй том документа «AMD64 Architecture Programmer’s Manual» сообщает, что узнать готовность платформы можно выполнив инструкцию CPUID. Ее функция 8000001Fh в регистрах EAX, EBX, ECX и EDX дает полную картину состояния криптозащиты. Воспользуемся утилитой JavaCrossPlatformCPUID.
Хотя искомую функцию мы не находим среди закладок, результат ее работы можно увидеть в дампе – регистр EAX содержит 0000000Fh. Стр.534 означенного выше документа позволяет утверждать, что все режимы безопасности на платформе ASUS RS700A-E9 в норме.
Впрочем, можно и не вдаваться в подробности. Аналогичный результат сообщает и AIDA64. Правда, информация о поддержке режима Secure Memory Encryption почему-то недоступна пользователям этой программы – еще один аргумент в пользу непосредственной диагностики через функции CPUID.
Теперь облачные сервисы просто обязаны гарантировать жителям коммуналки, что их виртуальные машины полностью изолированы друг от друга, а равно и от пытливого ока хост-платформы. Кстати, оптимисты могут и не шифровать свои гостевые задачи: наряду с зашифрованными с мирно уживаются и незашифрованные виртуалки (до сих пор выбирать не приходилось – нужно было быть «как все»: или-или).
Дело за малым – оценить накладные расходы на криптование: независимо от производительности процессора алгоритмы шифрования всегда создавали и продолжают создавать чувствительные накладные расходы. Сайт techpowerup, ссылаясь на AMD, утверждает об увеличении задержки при операциях с памятью на 7-8 нсек, что приводит к снижению производительности по SPECInt на 1,5%.
Ряд источников утверждает, что AMD дает возможность включения и выключения SEV-ES, и это можно сделать в сеансе операционной системы без перезагрузки. Как же видится подсистема криптозащиты и какие рычаги воздействия на нее доступны пользователю?
В Windows Server 2016 диспетчер устройств предоставляет информацию о двух наборах устройств – AMD K17 Platform Security Processor 3.0 (Device ID = 1456h) и AMD Cryptographic Coprocessor (Device ID = 1468h). Поскольку в каждом сокете работает по четыре процессорных ноды, всего в системе обнаруживается восемь PSP и CCP. Операционная система не сообщает ничего о ресурсах этих процессоров. Известно, впрочем, что они подключены к шине PCI Express в режиме полной разрядности (x16).
Хотя PSP/CCP программно-недоступны, их можно отключить, запретив в диспетчере устройств. Можно даже отключить ведущий к ним AMD PCI-линк (для PSP – это шины с ID = 145Ah, для CCP – шины с ID = 1455h), либо отключить мосты AMD K17 Internal PCIe General Purpose Ports (GPP). Их в системе 16 штук для обеспечения трафика между нодами и уполномоченными крипто(со)процессорами. Что, впрочем, никак не отражается на производительности платформы, если судить по Cinebench R15. Разброс результатов в диапазоне 4700…5100 в зависимости от фаз Луны сводит на нет сам процесс сбора метрик.
Собственно, Platform Security Processor 3.0 может быть отключен и операционной системой, если потребуется экономить электричество. Здесь немой вопрос в глазах: а так можно делать?
Инициативы AMD по аппаратной защите пользовательских данных не будут востребованы до тех пор, пока Microsoft, Oracle, Red Hat и VMware не поддержат их программными продуктами. Шифрование может оказаться полезным в тот же день, когда станет доступным соответствующий софт. Иначе все это будет похоже на историю с 3DNow!
Серверная плата ASUS KNPP-D3 с двумя процессорами AMD EPYC 7551 в корпусе RS700A-E9-RS4 поддерживает набор фирменных технологий криптозащиты от Advanced Micro Devices
Когда появилась возможность нам исследовать системную плату ASUS KNPP-D32 с двумя EPYC 7551, встала задача определиться с особенностями реализованной там криптозащиты. Не в последнюю очередь потому, что сложно представить иное использование такой платформы, кроме как в виде общежития для виртуальных машин. Все это хозяйство, упакованное в 1U стоечный корпус с терабайтом памяти о 64-х процессорных ядрах, – хорошая иллюстрация высокого удельного веса вычислительных возможностей. (При щадящем режиме потребления электроэнергии, кстати сказать).
Защита пользовательских данных видится в компании AMD как триединая задача, состоящая из шифрования памяти (Secure Memory Encryption), шифрования виртуальных сред (Secure Encrypted Virtualization) и шифрования процессорного контекста (Encrypted State). Второй том документа «AMD64 Architecture Programmer’s Manual» сообщает, что узнать готовность платформы можно выполнив инструкцию CPUID. Ее функция 8000001Fh в регистрах EAX, EBX, ECX и EDX дает полную картину состояния криптозащиты. Воспользуемся утилитой JavaCrossPlatformCPUID.
Хотя искомую функцию мы не находим среди закладок, результат ее работы можно увидеть в дампе – регистр EAX содержит 0000000Fh. Стр.534 означенного выше документа позволяет утверждать, что все режимы безопасности на платформе ASUS RS700A-E9 в норме.
Впрочем, можно и не вдаваться в подробности. Аналогичный результат сообщает и AIDA64. Правда, информация о поддержке режима Secure Memory Encryption почему-то недоступна пользователям этой программы – еще один аргумент в пользу непосредственной диагностики через функции CPUID.
Теперь облачные сервисы просто обязаны гарантировать жителям коммуналки, что их виртуальные машины полностью изолированы друг от друга, а равно и от пытливого ока хост-платформы. Кстати, оптимисты могут и не шифровать свои гостевые задачи: наряду с зашифрованными с мирно уживаются и незашифрованные виртуалки (до сих пор выбирать не приходилось – нужно было быть «как все»: или-или).
Дело за малым – оценить накладные расходы на криптование: независимо от производительности процессора алгоритмы шифрования всегда создавали и продолжают создавать чувствительные накладные расходы. Сайт techpowerup, ссылаясь на AMD, утверждает об увеличении задержки при операциях с памятью на 7-8 нсек, что приводит к снижению производительности по SPECInt на 1,5%.
Ряд источников утверждает, что AMD дает возможность включения и выключения SEV-ES, и это можно сделать в сеансе операционной системы без перезагрузки. Как же видится подсистема криптозащиты и какие рычаги воздействия на нее доступны пользователю?
В Windows Server 2016 диспетчер устройств предоставляет информацию о двух наборах устройств – AMD K17 Platform Security Processor 3.0 (Device ID = 1456h) и AMD Cryptographic Coprocessor (Device ID = 1468h). Поскольку в каждом сокете работает по четыре процессорных ноды, всего в системе обнаруживается восемь PSP и CCP. Операционная система не сообщает ничего о ресурсах этих процессоров. Известно, впрочем, что они подключены к шине PCI Express в режиме полной разрядности (x16).
Хотя PSP/CCP программно-недоступны, их можно отключить, запретив в диспетчере устройств. Можно даже отключить ведущий к ним AMD PCI-линк (для PSP – это шины с ID = 145Ah, для CCP – шины с ID = 1455h), либо отключить мосты AMD K17 Internal PCIe General Purpose Ports (GPP). Их в системе 16 штук для обеспечения трафика между нодами и уполномоченными крипто(со)процессорами. Что, впрочем, никак не отражается на производительности платформы, если судить по Cinebench R15. Разброс результатов в диапазоне 4700…5100 в зависимости от фаз Луны сводит на нет сам процесс сбора метрик.
Собственно, Platform Security Processor 3.0 может быть отключен и операционной системой, если потребуется экономить электричество. Здесь немой вопрос в глазах: а так можно делать?
Заключение
Инициативы AMD по аппаратной защите пользовательских данных не будут востребованы до тех пор, пока Microsoft, Oracle, Red Hat и VMware не поддержат их программными продуктами. Шифрование может оказаться полезным в тот же день, когда станет доступным соответствующий софт. Иначе все это будет похоже на историю с 3DNow!
