Конфиденциальные вычисления: TDX, SEV-SNP, шифрование памяти и аттестация
Функциональная граница защищённой VM: аппаратная изоляция, системное управление и обмен данными решают разные задачи. Геометрия условная. Открыть иллюстрацию в полном размере.
В обычной виртуальной машине гостевая операционная система изолирована от соседей, но гипервизор остаётся привилегированным управляющим слоем. Он распределяет физическую память, запускает виртуальные процессоры и организует ввод-вывод. Для владельца чувствительной задачи возникает неудобный вопрос: можно ли пользоваться чужим сервером, сократив доверие к программам его администратора?
Конфиденциальные вычисления добавляют аппаратно поддерживаемую границу защиты. Intel TDX и AMD SEV-SNP используют разные механизмы, но позволяют рассматривать защищённую виртуальную машину как отдельную доверенную среду. Чтобы понять эту технику, недостаточно знать про шифрование DRAM: важны владение страницами, сохранение состояния процессора, аттестация, общие буферы и политика выдачи ключей. Ниже разобраны эти механизмы и их практические ограничения. Источники сверены на 26 октября 2026 года. Все расчёты и схемы учебные; они не являются тестами конкретного сервера.
Содержание статьи
- 1. От кого должна защищать аппаратная граница
- 2. Где шифруется память и что видят ядра
- 3. Почему шифрования недостаточно для владения страницами
- 4. AMD SEV-SNP: обратная таблица и принятие памяти
- 5. Intel TDX: модуль между VMM и защищённым гостем
- 6. Кто входит в доверенную вычислительную базу
- 7. Частная и общая память на пути к устройству
- 8. Учебный баланс стоимости промежуточных копий
- 9. Аттестация: свидетельство, проверка и решение
- 10. Измеренный запуск не равен вечной корректности
- 11. TDREPORT и Quote: локальная и удалённая проверка
- 12. Свежесть и привязка к получателю секрета
- 13. Ключи памяти, диска и приложения живут по разным правилам
- 14. Защищённый ввод-вывод требует собственной архитектуры
- 15. Миграция и восстановление меняют цепочку доверия
- 16. Холодный запуск и устойчивая серия дают разные числа
- 17. Накладные расходы блока и полного приложения
- 18. Прошивки и обновления остаются частью защиты
- 19. Как проверить конфигурацию и измерить реальную цену
- 20. Первичные источники и версии
- Читайте также
1. От кого должна защищать аппаратная граница
Начинать следует с модели угроз. Оператор облака управляет хостовой ОС, гипервизором, прошивками и физической машиной. Заказчик контролирует образ своей виртуальной машины и приложение. Цель аппаратной изоляции — ограничить определённые возможности привилегированного хостового ПО в отношении содержимого защищённого гостя. Это более сильное требование, чем разделение двух обычных процессов.
При этом остаются разные классы свойств. Конфиденциальность ограничивает чтение данных, целостность — недопустимое изменение, доступность — возможность продолжать работу. Если гипервизор перестанет выдавать гостю процессорное время, шифрование памяти не заставит сервер выполнять запросы. В документации Intel отказ в обслуживании со стороны VMM прямо исключён из целей защиты TDX.
Физическое вмешательство, наблюдение за внешними сигналами и программная атака из хоста тоже нельзя смешивать. Механизм, блокирующий доступ административного процесса к страницам гостя, не обязан закрывать все физические и побочные каналы. Поэтому осмысленное описание содержит действующее поколение процессора, конфигурацию платформы и перечень защищаемых границ, а не обещание «никто ничего не увидит».
2. Где шифруется память и что видят ядра
При аппаратном шифровании памяти преобразование выполняется на пути между внутренней вычислительной системой и внешней DRAM. Приложение продолжает работать с привычными числами, указателями и инструкциями. Оно не получает зашифрованное значение вместо каждого прочитанного байта: для разрешённого обращения данные доступны в понятном процессору виде.
Ключ памяти и идентификатор ключа — разные сущности. Идентификатор выбирает аппаратный контекст, а секретное значение используется криптографическим механизмом. Системное ПО может управлять допустимыми операциями жизненного цикла, не получая сам ключ в виде обычного массива байтов. Конкретные правила назначения и очистки определяются архитектурой.
Из этого следуют два важных ограничения. Во-первых, ключ приложения, например для базы данных, не превращается автоматически в ключ шифрования DRAM. Во-вторых, шифрование оперативной памяти само по себе не защищает файл, записанный на диск, сетевой пакет или диагностический журнал. Путь данных нужно проследить от источника до результата и отдельно определить защиту каждой границы. Название функции процессора не заменяет эту карту.
3. Почему шифрования недостаточно для владения страницами
Представим, что гостю доступны два разных адреса, которые по замыслу программы должны обозначать независимые области. Если управляющий слой сможет незаметно сопоставить их с одной физической страницей, программа получит неожиданное совместное состояние. Данные могут оставаться зашифрованными на внешней шине, а ожидаемая логика адресации уже будет нарушена.
Поэтому нужны правила владения, разрешённых отображений и изменения состояния страниц. Аппаратная проверка должна учитывать, какому защищённому контексту принадлежит память и в каком состоянии разрешён доступ. При повторной передаче ресурса другому владельцу недостаточно заменить указатель: требуется согласованный протокол перехода.
Целостность также имеет несколько смыслов. Логическая защита от действий хостового ПО и криптографическая проверка содержимого памяти отвечают на разные угрозы. Intel отдельно описывает Logical Integrity и Cryptographic Integrity; свойства конкретной платформы и режима следует брать из документации. Нельзя приписывать любому зашифрованному DIMM полноценную защиту от всех видов подмены, физического повторного воспроизведения и ошибок хранения.
4. AMD SEV-SNP: обратная таблица и принятие памяти
В SEV-SNP важную роль играет Reverse Map Table, или RMP. Она связывает физическую память с владельцем и состоянием, чтобы обычного изменения таблиц трансляции гипервизором было недостаточно для нарушения правил защищённого гостя. Это дополнительный уровень контроля, а не замена всей виртуальной памяти.
Выделение страницы и её принятие гостем разделены. Хост выполняет предусмотренную архитектурой операцию управления, а гостевая сторона подтверждает допустимость страницы через PVALIDATE. Смысл такого разделения — не позволять одному управляющему слою произвольно менять уже принятую гостем картину памяти. Подробности размеров страниц и состояний зависят от используемых спецификаций и реализации.
На учебной схеме две страницы принадлежат машине A. Запрос назначить одну из них машине B должен пройти проверку владения и корректный переход, а не превратиться в ещё одно разрешённое отображение той же частной памяти. При анализе системы полезно спрашивать не только «какой ключ используется», но и «кто вправе изменить владельца, когда очищается состояние и кто подтверждает переход».
5. Intel TDX: модуль между VMM и защищённым гостем
TDX вводит доверенный модуль, работающий в специальном режиме SEAM. VMM сохраняет функции управления ресурсами, но операции с trust domain проходят через интерфейсы, ограниченные правилами модуля и процессора. Такой посредник позволяет отделить право запланировать виртуальную машину от права читать её частную память.
Частная трансляция использует Secure EPT и защищаемые метаданные. Состояние виртуальных процессоров также входит в модель изоляции: защита памяти мало помогает, если секрет остаётся в регистрах и без ограничений раскрывается при остановке гостя. При этом TDX не превращает гипервизор в отсутствующий компонент: планирование и обслуживание разрешённых запросов всё ещё необходимы.
Следует различать процессорные расширения, версию TDX Module, интерфейс гостя и возможности системного ПО. Наличие инструкции либо опубликованной спецификации ещё не подтверждает, что нужный сценарий поддержан данным сервером. Обновление модуля, загрузчика или гостевого ядра может менять доступные возможности и условия аттестации. Рабочая конфигурация описывается целым набором версий и настроек.
6. Кто входит в доверенную вычислительную базу
Trusted Computing Base, или TCB, — совокупность компонентов, от корректности которых зависит рассматриваемая защита. Уменьшение доверия к гипервизору не устраняет доверие к процессору, определённым прошивкам, доверенному модулю и программам внутри защищённой среды. Граница доверия меняется, но не исчезает.
Если внутри защищённой виртуальной машины работает большая гостевая ОС, её привилегированные компоненты обычно остаются частью доверенного окружения приложения. Уязвимость в гостевом сервисе может раскрыть данные через его обычный сетевой ответ, не нарушая аппаратную изоляцию от хоста. Поэтому аппаратная функция дополняет контроль образа и обновлений.
Полезно составить список: кто загружает код, кто проверяет измерения, кто выдаёт секреты и какие компоненты видят открытые данные. Затем отдельно отметить изменяемые зависимости. Например, корректно измеренный загрузчик может позднее загрузить приложение по сети; доверие к этому приложению требует собственного механизма проверки. Хэш ранней стадии не становится автоматическим доказательством происхождения каждого последующего файла.
7. Частная и общая память на пути к устройству
Виртуальная машина должна взаимодействовать с дисками, сетевыми картами и управляющим слоем. Для этого предусмотрены области памяти, которыми можно обмениваться. Общий буфер по определению имеет другие правила доступа, чем частная область гостя. Его содержимое следует оценивать как данные на отдельной границе доверия.
Документация Linux для TDX описывает преобразование страниц между private и shared и использование SWIOTLB для многих DMA-операций. Приложение может продолжать видеть привычный интерфейс ввода-вывода, а под ним появятся промежуточное размещение и копирование. Поэтому совместимость драйвера ещё не означает отсутствие дополнительных переносов.
Входящие данные общего буфера нужно проверять так же внимательно, как любой недоверенный ввод. Важны длины, диапазоны, форматы и согласованность состояния. После проверки нельзя бездумно читать меняющийся общий объект повторно: между чтениями внешний участник способен изменить его содержимое. Безопасная программная организация этой границы является частью полноценного решения, даже когда аппаратная защита частной памяти работает корректно.
При этом общий буфер не обязательно содержит открытый прикладной секрет. Если шифрование транспорта выполнено внутри защищённого гостя, наружу может передаваться уже зашифрованное сообщение. Ключи и исходные данные остаются в частной области, а общая память обслуживает доставку. Однако размер, время и частота таких сообщений могут оставаться наблюдаемыми. Это показывает, почему нужно отдельно описывать содержимое буфера и доступные внешнему участнику метаданные. Проверка защищённого канала также должна устанавливать нужного получателя: шифрование до произвольного внешнего сервиса не означает, что результат остаётся доступен только владельцу задачи.
8. Учебный баланс стоимости промежуточных копий
Рассмотрим строго последовательный обмен: 64 МиБ отправляются устройству, затем столько же возвращаются. Перед отправкой данные копируются из частной области в общий буфер, после приёма — обратно. Для каждой копии по одной выбранной границе памяти проходят чтение и запись, то есть 128 МиБ.
Пусть полезная полоса этой границы равна 40 ГиБ/с. Одна копия занимает 128 МиБ / 40 ГиБ/с = 3,125 мс, две — 6,25 мс. Полезная скорость передачи в каждом направлении задана как 16 ГБ/с в десятичных единицах. Передача 64 МиБ занимает 4,194304 мс; туда и обратно — 8,388608 мс. Сумма четырёх последовательных стадий равна 14,638608 мс.
Это не оценка накладных расходов TDX или SNP. Мы исключили команды, вычисления, шифрование транспорта и очередь, а перекрытие стадий намеренно запретили. Пример показывает способ учёта: копия перемещает больше байтов по памяти, чем размер полезного сообщения. При реальном конвейере нужно измерять перекрытие и конкуренцию за одну и ту же полосу, а не механически складывать независимые максимумы.
9. Аттестация: свидетельство, проверка и решение
Аппаратная среда мало полезна удалённому заказчику, если он не может проверить, куда отправляет секрет. Аттестация предоставляет свидетельство о платформе и защищённом окружении. Но получение подписанного объекта, его проверка и разрешение доступа — разные этапы.
Архитектура IETF RATS выделяет Attester, Verifier и Relying Party. Первый предоставляет свидетельства, второй оценивает их, а третья сторона принимает прикладное решение на основе результата. В конкретном сервисе некоторые роли могут совмещаться, но их смысл от этого не меняется. Проверяющий должен располагать доверенными исходными данными и политикой оценки.
Для сервера ключей решение может звучать так: выдать ключ только разрешённому образу, при подходящей конфигурации и допустимом состоянии платформы. Простая проверка математической подписи недостаточна, если подписанный объект относится к другому гостю или содержит запрещённые параметры. Аттестация превращает аппаратные сведения в полезное условие доступа только вместе с явными правилами того, что считается приемлемым.
10. Измеренный запуск не равен вечной корректности
Измерение загрузки связывает определённые данные и конфигурацию с криптографическим отпечатком. Для разных технологий набор измеряемых компонентов и регистров отличается. Например, в TDX используются измерение начального состояния MRTD и регистры расширяемых измерений RTMR; их интерпретация зависит от процесса загрузки.
Измерение не является автоматическим анализом исходного кода на отсутствие ошибок. Два идентичных образа дадут ожидаемый результат измерения даже тогда, когда в обоих находится одна и та же уязвимость. И наоборот, штатное обновление может изменить отпечаток, хотя приложение стало безопаснее. Поэтому нужен управляемый каталог разрешённых версий.
Важен и момент времени. Проверка перед выдачей секрета отвечает на вопрос о предъявленном состоянии, а не гарантирует любой будущий результат программы. Политика должна учитывать время действия решения, обновления и повторное подтверждение. Чем длиннее живёт приложение и чем больше оно подгружает после запуска, тем существеннее становится связь между начальным измерением и дальнейшей цепочкой доверенного кода.
11. TDREPORT и Quote: локальная и удалённая проверка
В TDX гостевая сторона получает TDREPORT от доверенного модуля. Его проверка связана с локальной платформой. Для удалённого подтверждения используется Quote, формируемая через механизм quoting и снабжённая проверяемой цепочкой удостоверяющих данных. Эти объекты решают разные задачи и не должны называться взаимозаменяемыми файлами.
Получатель проверяет не только подпись. Нужны подходящие сертификаты, сведения об отзыве и состоянии TCB, ожидаемые измерения и разрешённые атрибуты. Источники удостоверяющих данных должны быть определены политикой, а не произвольным адресом, который прислал проверяемый участник. Библиотека проверки помогает с форматом и криптографией, но не выбирает за владельца допустимый образ приложения.
У SNP иной формат отчёта и своя цепочка ключей. Нельзя обрабатывать его как TDX Quote с переименованными полями. При интеграции полезен нормализованный прикладной результат, но он должен сохранять значимые различия технологий, происхождение утверждений и статус проверки. Потеря этих деталей ради единственного флага «всё хорошо» делает политику непрозрачной.
12. Свежесть и привязка к получателю секрета
Даже подлинное свидетельство может оказаться старым или относиться к другому сеансу. Поэтому протоколу нужна свежесть: например, одноразовый запрос проверяющего, связанный с предъявляемыми данными. RATS описывает разные подходы, включая nonce и время; подходящий способ определяется полной схемой взаимодействия.
Не менее важна привязка к каналу выдачи секрета. Проверяющий должен понимать, что последующий защищённый обмен заканчивается в той среде, о которой получено свидетельство. В качестве концепции можно связать nonce, открытый ключ сеанса и контекст протокола криптографическим хэшем, включённым в пользовательские данные отчёта. Реальный формат требует однозначного кодирования и проверенной реализации.
Например, 512-битное поле имеет размер 64 байта. Такой размер встречается у REPORT_DATA в открытой спецификации SNP и у REPORTDATA TDX. Сам процессор не придаёт произвольным пользовательским байтам смысл «правильный клиент» — этот смысл устанавливают протокол и проверяющая программа. Одинаковая длина полей также не делает взаимозаменяемыми отчёты двух архитектур.
13. Ключи памяти, диска и приложения живут по разным правилам
Аппаратный ключ оперативной памяти обслуживает изоляцию в работающей платформе. Ключ зашифрованной базы или дискового тома должен иметь собственный жизненный цикл: создание, выдачу, смену, отзыв и восстановление. Подмена этих понятий приводит к неприятному сюрпризу после остановки виртуальной машины.
Сохранённые данные часто должны переживать перезапуск, а аппаратный контекст — пересоздаваться. Если доступ к данным выдаётся только после аттестации, новая допустимая машина сможет получить соответствующий ключ через сервис управления секретами. Такой сервис становится значимым участником системы: необходимо определить его полномочия и допустимые условия восстановления.
Похожая логика относится к журналам и результатам. Программа внутри защищённого гостя может сама отправить открытые данные наружу. Для предотвращения этого нужны правила приложения и транспорта, а не дополнительный слой шифрования DRAM. Полезно проверить всю цепочку: где секрет появляется, кто его использует, что сохраняется и в каком виде результат покидает защищённую область.
14. Защищённый ввод-вывод требует собственной архитектуры
Ускоритель или сетевая карта не становятся доверенными только потому, что работают рядом с защищённой VM. Необходимо проверить устройство, его состояние и назначение интерфейса, а также защитить передачу и правила доступа. IOMMU ограничивает адресуемые области, но сама по себе не заменяет все эти проверки.
В документации Intel TDX Connect описано расширение к TEE-IO; AMD отдельно публикует материалы Trusted I/O с использованием TDISP. Эти направления следует рассматривать вместе с возможностями конкретного устройства, процессора, прошивок и драйверов. Наличие спецификации не подтверждает доступность любого сочетания платы и гостевой ОС.
Для проектирования важна непрерывность границы. Если данные защищены в памяти CPU, а затем в открытом виде попадают в недоверенный буфер ускорителя, защита изменилась. Иногда приемлем именно такой сценарий, но решение должно быть явным. Полный доверенный путь и обычное подключение устройства — разные конфигурации с разными условиями совместимости и эксплуатации.
15. Миграция и восстановление меняют цепочку доверия
Обычную VM удобно переносить и сохранять. У защищённой машины состояние связано с аппаратными контекстами и политикой, поэтому миграция требует специального поддерживаемого механизма. Необходимо определить, кому разрешено принять состояние, как подтверждается целевая среда и что происходит с исходным экземпляром.
Нельзя переносить успешный результат одного поколения документации на все реализации. Возможность может быть описана в архитектуре, поддержана конкретным модулем и ещё не включена в используемый набор системных программ. Эти три стадии стоит проверять отдельно. То же относится к снимкам, отладке и взаимодействию с дополнительными доверенными сервисами.
Откат постоянного хранилища представляет отдельную задачу. Защищённая оперативная память не доказывает, что гипервизор подал самую свежую версию дискового образа. Приложению может понадобиться внешний доверенный учёт версии или другой протокол согласованности. Поэтому план восстановления следует проверять вместе с сохранением конфиденциальности и целостности, а не добавлять после запуска сервиса.
16. Холодный запуск и устойчивая серия дают разные числа
Затраты на создание окружения и получение аттестационного решения могут быть разовыми для серии запросов. Возьмём условный обычный путь 20 мс на запрос. Защищённый путь требует 300 мс начальной подготовки, а затем 22 мс на запрос. Для N запросов времена равны 20N и 300 + 22N мс.
При N = 1 получаются 20 и 322 мс. При N = 100 — 2000 и 2500 мс, то есть 25% добавочного полного времени. При N = 1000 — 20 000 и 22 300 мс: добавка составляет 11,5%. Отношение равно 1,1 + 15/N; разовая подготовка постепенно размывается, но постоянная надбавка 10% в заданной модели остаётся.
Ни одно из этих чисел не является типичным временем аттестации или потерей производительности конкретного TEE. Они выбраны для объяснения границы измерения. Если среда создаётся для каждого запроса, начальная подготовка повторяется. Если решение проверки кэшируется, нужно учитывать его срок и политику обновления. Устойчивый режим и кратковременные задачи требуют разных графиков.
17. Накладные расходы блока и полного приложения
Другой учебный пример: полный запрос занимает 100 мс, из них 40 мс приходятся на рассматриваемый защищаемый участок, а 60 мс остаются неизменными. Если первый участок стал занимать на 20% больше времени, он вырос до 48 мс. Полное время равно 108 мс, поэтому общая надбавка составляет 8%, а не 20%.
Допустим, на новой границе дополнительно возникли 4 мс последовательного копирования. Получаем 112 мс и 12% добавки. Если копирование уже было включено в измеренные 48 мс, прибавлять его ещё раз нельзя. Если оно перекрывается с другим этапом, нужна соответствующая конвейерная модель, а не простая сумма.
Именно поэтому измерения шифрования памяти, локального ядра, сетевого обмена и готового сервиса могут давать разные проценты. В первичном исследовании Intel 2026 года для TDX и H100 отдельно рассматривается система с bounce buffer. Результаты такой конфигурации нельзя автоматически переносить на другую схему ввода-вывода. Любой процент должен сопровождаться указанием нагрузки и границы учёта.
18. Прошивки и обновления остаются частью защиты
Аппаратная поддержка не освобождает систему от исправлений. Уязвимость может находиться в управляющей прошивке, проверке состояния или взаимодействии компонентов. Поэтому при оценке платформы нужно читать бюллетени производителя и сопоставлять их с точной моделью, версией BIOS и предоставляемыми OEM обновлениями.
Показателен AMD-SB-3034 о конфигурации маршрутизации SEV-SNP. В актуальной на дату материала редакции перечислены средства устранения для конкретных продуктов, а в истории отдельно отмечено удаление TCB values 24 сентября 2026 года. Из этого нельзя выводить, что любой один проверенный числовой атрибут отчёта автоматически подтверждает установку каждого требуемого исправления платформы.
Политика проверки и управление обновлениями должны работать согласованно. Важно понимать, какие свойства отражены в свидетельстве, какие проверяются через учёт конфигураций и когда изменение вызывает повторную оценку. Отладочные режимы тоже требуют отдельного внимания: допустимый для лаборатории атрибут может быть неприемлем при выдаче рабочих секретов. Это конкретные условия доверия, которые нужно зафиксировать до эксплуатации.
19. Как проверить конфигурацию и измерить реальную цену
Для воспроизводимого сравнения зафиксируйте процессор, BIOS, доверенную прошивку или модуль, хостовую систему, гостевое ядро и драйверы. Укажите, какой режим действительно запущен, как проверяется свидетельство и по какой политике принимается решение. Обычная VM на совместимом процессоре ещё не означает, что защищённый режим включён.
Измеряйте полный путь: создание, загрузку, аттестацию, получение секрета, подготовку входа, обработку и выдачу результата. Отдельно полезны устойчивая серия, разные размеры сообщений, интенсивность ввода-вывода и поведение при нехватке ресурсов. Сравнение должно сохранять одинаковую задачу, конфигурацию памяти, число виртуальных CPU и условия нагрузки.
Проверка отказов тоже содержательна: отклоняется ли запрещённый образ, просроченное решение, неверная привязка сеанса и недопустимый режим отладки? Можно ли восстановить сервис после обновления без несанкционированной выдачи ключей? Успешный проект объединяет аппаратную границу с проверяемой политикой. Его результат описывается конкретными условиями защиты и измеренной стоимостью, а не общим обещанием полной неуязвимости.
20. Первичные источники и версии
Использованы документы производителей, документация Linux и архитектура IETF RATS. Приведённый открытый PDF AMD ABI имеет ревизию 1.58 от мая 2025 года; каталог AMD отдельно перечисляет более новую ревизию. Здесь не предполагается одинаковая поддержка всех расширений всеми процессорами. Архитектурная спецификация, программная поддержка и проверенная конфигурация сервера — отдельные уровни подтверждения.
- Intel TDX: обзор границ доверия и архитектуры.
- Intel Architecture Memory Protections for Confidential Computing.
- Intel Trust Domain CPU Architectural Extensions.
- AMD SEV: возможности поколений и каталог спецификаций.
- AMD SEV-SNP Firmware ABI, ревизия 1.58.
- Linux: поддержка TDX, общая память и аттестация.
- Linux: AMD Memory Encryption.
- IETF RFC 9334: архитектура Remote Attestation Procedures.
- Intel TDX DCAP: генерация и проверка Quote.
- Intel Trust Authority: поля аттестационных токенов.
- Intel TDX Connect: архитектура защищённого ввода-вывода.
- Intel: анализ конфиденциальных AI-вычислений с TDX и H100, 2026.
- Intel: методика сравнения производительности TDX.
- AMD-SB-3034: конфигурация маршрутизации SEV-SNP и исправления.