• nav


Изучаем шифрование памяти в процессорах AMD, или как EPYC 7000 защищает ваше облако

Давайте приведём простую аналогию: если данные вашей компании - это деньги, то раньше физический сервер, на котором они хранились, представлял собой защищённый сейф: закрытая железка с паролем, расположенная за тремя замками и под охраной. Но с переходом в облака, сервер уже больше похож на банкомат: он расположен в общедоступном месте, любой человек может подойти к нему, проверить баланс на карте, снять деньги, пнуть его ногой или молотком, да что там мелочиться - даже увезти его с собой, как уже бывало.. Вас не волнуют проблемы безопасности банкомата лишь по одной причине: содержимое банкомата - это собственность банка, и если оттуда похитят деньги - вас это не коснётся. Но в случае с информацией всё иначе. Да, сегодня большинство данных в облаках, хранятся не "в сейфах", а в "банкоматах", на серверах, которыми пользуются другие клиенты. Вы, заключая договор об обслуживании, зачастую не знаете даже где физически размещается сервер, не знаете личности его администраторов и мероприятия по обеспечению безопасности, которые проводит облачный провайдер. Да, у вас есть SLA, но ваши потери в случае кражи информации могут не покрываться ответственностью облачного провайдера.

Конфигурация тестового стенда:

Программное обеспечение:

  • Oracle Linux 7.6
  • Ubuntu:
    • Ubuntu 18.04 Server
    • Ubuntu 19.04 Desktop
  • Redis Server
  • MySQL 5.7
  • Sysbench

Сегодня, когда обычные Cloud-системы трансформируются в гибридные облака, необходимо обеспечить одинаковый уровень безопасности как на локальном сервере, который стоит под тремя замками офисе компании, так и на удалённом виртуальном, о котором может быть не известно ничего кроме виртуальной конфигурации. При этом, число уязвимостей в корпоративном ПО, связанным с виртуализацией, растёт с каждым годом, а общая динамика числа новых уязвимостей по данным NIST (https://www.nist.gov/) растёт экспоненциально:

Мы видим двукратный рост в 2017-2018 годах, и за первую половину 2019 года тенденция сохраняется. Я слышал, что при аренде виртуальной машины менеджер рассказывал клиенту про респектабельных и интеллигентных соседей по серверу - и я до сих пор не знаю, было ли это правдой или нет, потому что существуют типы атак, при которых владелец виртуальной машины сможет получить доступ к данным всех виртуалок на том же сервере.

Подобные атаки, связанные с повышением прав доступа, могут использовать не только программные ошибки в коде ОС, но и аппаратные баги в архитектуре процессора, что подтверждается печальным опытом компании Intel, которая вынуждена закрывать уязвимости в своих Xeon-ах ценой снижения их производительности. Даже у нас в тестовых серверах на Intel Xeon используются операционные системы осени 2018 года (до появления Meltdown/Spectre), потому что патчи безопасности настолько сильно замедляют машину, что это уже мешает нормальному тестированию.

Но есть в мире одна компания, которая каждую новую уязвимость в процессорах Intel встречает под звон бокалов с шампанским и аплодисменты: это AMD, поскольку мало того, что их архитектура CPU не подвержена уязвимостям, связанным со спекулятивным исполнением команд, так ещё и их процессоры EPYC серии 7000 изначально разрабатывались для более высокого уровня безопасности при работе в изолированных средах: обычная и контейнерная виртуализация, то есть всё то, что сегодня наиболее востребовано в IT-бизнесе.

AMD Secure Processor

В общем-то, под громкими словами "технологии безопасности", скрываются два основных нововведения:

  • Первое - это отдельное ядро безопасности AMD Secure Processor (ARM Cortex-A5), управляющее генерацией и хранением ключей, а так же берущее на себя механизм загрузки доверенной операционной системы. Оно интегрировано в каждый процессор AMD EPYC серии 7000.
  • Второе - это шифрование оперативной памяти алгоритмом AES-128, выполняющееся полностью на аппаратном уровне самими контроллерами памяти. И если все мы знаем и используем шифрование дисков, то подобная защита ОЗУ для многих IT-специалистов до сих пор оказывается в новинку.

Для начала, я изучил предложение ны рынке облачных провайдеров на июнь 2019 года. Ни одна из знакомых мне компаний не афишировала какие-то особые технологии, касаемые безопасности. Процессоры AMD EPYC 7000 открыто предлагала в аренду (в составе физических серверов, конечно), только компания "Селектел". И хотя эти CPU созданы для того, чтобы нарезать их на сотни виртуалок и продавать как сервис в виде контейнеров и VPS, их предлагают по принципу "разбирайтесь сами". Тогда я прямо спросил ведущих российских облачных провайдеров о том, где используется шифрование и шифруют ли они память?

Максим Захаренко, генеральный директор компании Облакотека (https://oblakoteka.ru/):

С шифрованием данных ситуация довольно непростая. Каналы передачи корпоративных данных практически всегда и по умолчанию шифрованные, а вот хранение дисков виртуальных машин в облаке чаще всего осуществляется в открытом виде. Связано это с тем, что расшифровка данных осуществляется на стороне облачного провайдера, то есть данные реально защищены только в момент, когда машина выключена. При этом есть, например, технология Shielded VMs от Microsoft. Она позволяет полностью изолировать виртуальную машину от доступа провайдера, но "Облакотека" использует кластерную организацию платформы, поэтому любое неосторожное движение, ошибки в обновлениях могут привести к утрате доступа к ВМ без возможности восстановления. Так что теоретически шифрование выглядит панацеей от угроз безопасности в облаке, а практически — мало используется. NDA, административные санкции к провайдеру, методы защиты платформы — всё это на сегодняшний день достаточно зрело и системно. Поэтому фактически нарушений безопасности в облаке существенно меньше, чем при размещении ИТ-инфраструктуры в офисе.

Шифрование ОЗУ не используем. Оперативная память – не самое интересное для атаки место, по крайней мере в наших сценариях.

Ну что же, придётся разбираться самостоятельно. Тем интереснее будет понять, почему целевая аудитория процессоров EPYC 7000 так прохладно отнеслась к технологии, которая призвана дать им конкурентное преимущество на весьма перегретом рынке. Как говорится, поехали!

OK, что есть у AMD для защиты памяти?

Скопировав содержимое памяти, злоумышленник может вытащить не только ключи шифрования к дисковому тому, зашифрованному LUKS и Bitlocker (хотя сегодня это сделать всё сложнее), но и непосредственно сами данные, которые могут храниться в кэше СУБД или другом приложении. Обеспечить полную изоляцию ваших данных, защитив их от любого взлома, невозможно, но можно сделать их нечитаемыми для взломщика с помощью 128-битного шифрования ОЗУ, для чего в процессорах AMD EPYC есть несколько методов. Самый простой - это TSME (Transparent Secure Memory Encryption), прозрачное шифрование всей оперативной памяти хоста единым ключом. При использовании данного метода ни операционная система, ни софт не знают о том, что данные в ОЗУ шифруются, поэтому вы можете использовать совершенно любое приложение и любую операционную систему.

TSME включается в BIOS-е материнской платы, но будьте готовы, что у вас этой функции может и не быть, так как она конфликтует с другими методами шифрования, и производители её не афишируют. В нашей тестовой материнской плате ASRock Rack EPYC8D-2T она включается через скрытое меню в BIOS-е при нажатии CTRL+ALT+F3, но ни в инструкции, ни на сайте компании о её поддержке не было ни слова.

От каких напастей защищает TSME?

От атаки Cold Boot (https://en.wikipedia.org/wiki/Cold_boot_attack), при которой злоумышленник замораживает специальным спреем модули памяти на работающей машине до температуры -50 градусов Целсьия и отключает питание, не давая операционной системе сбросить информацию в ячейках. При столь низкой температуре обесточенная память может сохранять всю свою информацию аж до 6 минут, а при -100 градусах - до 10 минут. Остаётся лишь установить модуль DIMM в машину с модернизированным BIOS-ом и собственной операционной системой, и слить хранимую на нём информацию, чтобы в спокойной обстановке извлечь из дампа памяти ключи шифрования, пароли, пользовательские данные, да и вообще всё, что было в операционной системе. На видео ниже представлен удачный пример подобного взлома.

У этой атаки есть и более простой аналог - это кража модулей энергонезависимой памяти NVDIMM, не боящейся отключания питания. Сейчас этот вид ОЗУ продвигается такими компаниями как HPE и Dell, так что с ростом его популярности, данная атака будет более распространена.

При каждой загрузке сервера, процессор меняет ключ шифрования памяти, так что считать краденые данные даже загрузив сервер со своей флешки не удастся. Помимо принудительного прозрачного шифрования, процессорами AMD EPYC поддерживается скрэмблинг памяти, включаемый аналогично через секретную вкладку в BIOS. Эти два режима работают независимо, и сводят на нет попытки вскрыть сервер методом холодной загрузки.

Получается, что если вы используете сервер, выделенный исключительно под ваши приложения (например, сервер баз данных или СХД), функция тотального шифрования памяти - это серьёзный барьер от атаки, связанной с физическим доступом к модулям DIMM/NVDIMM. К сожалению, от других типов атак AMD TSME не спасает.

AMD SME

Без приставки «Transparent», функция Secure Memory Encryption работает по вызовам операционной системы, которая выбирает, какие страницы памяти шифровать, а какие - нет. Функция SME имеет два режима работы: шифрование всей памяти аналогично TSME, или только выбранных страниц, но во всех случаях используется один общий ключ, который не меняется в течение всего времени после загрузки операционной системы.

Вообще, с моей точки зрения, при наличии TSME, функция SME уже выглядит излишней, так как требует поддержки со стороны софта. На момент подготовки статьи, SME поддерживалась только семейством операционных систем Linux с ядром выше 4.14. Но в некоторых дистрибутивах для корпоративного пользователя, например, в Oracle Linux 7.6 на ядре 3.10, функция SME поддерживается и включена по умолчанию. В других же дистрибутивах для включения SME нужно добавить в строку загрузки (файл конфигурации grub) параметр mem_encrypt=on. Проверить работу SME можно выполнив команду в терминале:

dmesg | grep 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 при включении шифрования не происходит.

При конвейерном доступе, в запросах записи в базу данных мы можем увидеть максимальное снижение скорости - около 5%.

При тестировании реляционной базы данных 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

Ну вот допустим, вы купили виртуальный сервер у какого-то облачного провайдера, на разбираясь в деталях, а я - сисадмин данного сервиса с кучей свободного времени и root-доступом к серверу, где работает ваша виртуалка. Технически, я могу прочитать содержимое памяти вашей виртуальной машины, вытащив оттуда номера кредитных карт, пароли или E-mail адреса ваших клиентов: всё то, чем дорожит ваша компания. И даже если я сильно держусь за своё рабочее место и не стану этого делать, виртуальные среды подвержены уязвимостям типа VM Escape, при которой клиент, арендующий VPS, применяет атаку на повышение прав доступа. В итоге он так же, как и администратор, может считать память виртуальных машин, получив нужные данные.

AMD позаботилась и о таком виде атак: функция Security Encryption Virtualization (SEV) обеспечивает шифрование области ОЗУ, выделенной под виртуальную машину, независимо от гипервизора. Каждая виртуалка использует собственный ключ, и ни root администратор, ни хакеры, использующие атаки на повышение прав, не смогут прочитать содержимое дампа памяти вашей виртуальной машины. Причём, функция AMD SEV работает независимо от TSME / SME, и на одном физическом сервере вы можете совмещать как обычные виртуальные машины, так и их варианты с индивидуально зашифрованной памятью, а какое-либо приложение, запущенное на хосте, может использовать шифрование SME.

Если вы думаете, что SEV ограничивается только шифрованием, вы заблуждаетесь: при обработке данных из виртуальной машины, процессор помечает всю информацию тегами, соответствующими определённой виртуальной машине. Эта технология очень похожа на виртуальные сети (VLAN) в сетевых коммутаторах, с той лишь разницей, что вместо сетевого свитча у нас - 180-Ваттный 32-ядерный SoC, а вместо сетевых портов - виртуальные машины. Всё время, пока данные какой-то виртуалки поступают или создаются внутри процессора, они остаются доступны только для этой самой машины, где бы они ни находились, включая все уровни кэширования. Даже гипервизор и операционная система хоста не имеют доступа к страницам памяти ВМ, находящемся на обработке в процессоре. Таким образом, данные даже в момент вычислений в процессоре, данные остаются экранированы не только от других виртуальных машин, но и от самого окружения сервера.

В случае, если атакующий захочет скомпрометировать гипервизор, установив драйвер, подменяющий маппинг физической памяти, чтобы получить доступ к ОЗУ виртуалки, AMD-VI (IOMMU) не позволит этой атаке состояться. В принципе, тема защиты области загрузки и выполнения - слишком обширна для данной статьи, и по возможности, мы рассмотрим её в другой раз.

Будь вы клиент или провайдер облачных услуг, вам важно запомнить, что с механизмом AMD SEV виртуалка в облаке защищена не только от хакеров извне, но и от хозяина сервера. Практически мы говорим о том, что любые атаки на кэши или механизмы префетчинга архитектуры AMD EPYC, не имеют смысла, так как в лучшем случае хакер получит данные в зашифрованном виде. Однако, как показала практика, исследователи смогли её обойти, но об этом чуть позже.

Подайте ложку дёгтя!

Конечно, всё прекрасно, но у AMD SEV есть и серьёзная проблема: эта технология поддерживается только платформой QEMU под Linux, так что весь софт от VMWare и Microsoft все эти прелести не использует (хотя говорят, что в работа в этом направлении идёт и скоро всё будет, только потерпите). Но и это ещё не всё: чтобы AMD SEV работала, нужно чтобы не только гипервизор, библиотеки QEMU и Libvirt её поддерживали, но и в качестве гостевой операционной системы использовалась современная версия Linux. Полноценная поддержка AND SEV появилась лишь в ядре Kernel 4.14, но как и полагается миру Linux, во всех дистрибутивах всё по-разному: например, в Ubuntu 19.04 на ядре 5.1 по умолчанию все функции AMD SME/SEV выключены, а в Oracle Linux 7.6 с ядром 3.10 - наоборот включены, т.к. разработчик применил все необходимые патчи. Сама AMD рекомендует использовать в роли гипервизора SUSE Enterprise Linux 15 или Fedora 28+, а в качестве гостевой ОС - Ubuntu 18.04, но я считаю что на роль гипервизора лучше сосватать Oracle Linux 7.6, и при необходимости доставить на него 5-е ядро из репозитория UEK5.

Вообще, у AMD есть хороший репозиторий на GITHub со скриптами установки SEV-окружения на SLES-15, RHEL8, Fedora 28(29) и Ubuntu 18.04 с примером запуска зашифрованной гостевой виртуальной машины. Следует заметить, что поскольку Virtual Manager и virsh не поддерживают AMD SEV, запуск и остановка виртуалок производятся командами из графической оболочки гипервизора, то есть окружение рабочего стола должно быть предустановлено и запущено.

Конечно же, AMD SEV можно включить и для существующих виртуальных машин, если в их XML добавить параметры безопасной загрузки, так что если вам это интересно - рекомендуем почитать инструкции в блоге SUSE Linux Enterprise Server. Когда всё настроено и работает, выполните в терминале гостевой операционной системы команду dmesg | grep SVE. Вывод должен быть таким:

Хочу добавить, что начиная с Linux 4.19 / QEMU 3.1, гостевые SEV-системы получили поддержку практически любых устройств с прямым доступом к памяти, включая GPU, шифрование для них - прозрачно. Так же в репозитории 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:


AMD SME

AMD SEV

Intel SGX

Защита от атак на физическом уровне

Да

Да

*

Защита всей системной памяти

Да

Да


Защита от:

компрометации гипервизора


Да

*

компрометации гостевых ОС


Да

*

Требует изменений приложения

Нет

Нет

Да

* - каждое приложение должно быть модифицировано и перекомпилировано для включения защиты

Здесь я хочу добавить, что мало кто согласится менять приложение и перекомпилировать своими силами. Для этих целей в сети есть целые сервисы, предлагающие контейнеры, скомпонованные из софта, скомпилированного под Intel SGX. Одним из таких репозиториев является Scone, так что если вы доверяете сообществу - поищите, возможно нужное вам приложение уже кто-то скомпилировал и выложил в сеть.

А что нужно клиенту?

Углубившись в технологии, описания алгоритмов взлома и защиты, я как-то совершенно забыл, ради чего всё это делается, ведь по сути, в любом облачном сервисе главное - не защита, а клиент. Может, клиентам это всё не надо?

Максим Захаренко, генеральный директор компании Облакотека (https://oblakoteka.ru/):


Клиенты, безусловно, интересуются тем, насколько обеспечена безопасность размещаемых данных. При этом клиенты четко делятся на два множества. Первые очень хорошо знают все аспекты безопасности и проговаривают (прописывают их в SLA), включая, например, местоположение и методы защиты резервных копий. А другие практически не разбираются в теме, поэтому само наличие у нас стандартных методов, систем и NDA уже дает достаточный уровень доверия к "Облакотеке".



Владимир Карагиоз, руководитель группы архитекторов по решениям Red Hat (https://www.redhat.com):

Некоторые наши клиенты заинтересованы в тестировании в технологии аппаратной изоляции виртуальных машин и данная технология стала для них интересным рабочим вариантом. Мы активно работаем со всеми нашими партнерами-поставщиками аппаратных средств, для того, чтобы обеспечить высокий уровень безопасности и производительности.

Я никогда не слышал о том, чтобы где-то в ЦОД-е кто-то замораживал модули ОЗУ спреем и проводил Cold-boot атаку. Возможно, потому что такие хакеры или сисадмины таких дата-центров (смотря кому из них больше повезло) уже ничего не могут сказать, но я своими руками тестировал SAS-диски, списанные из дата-центра банка, которые не прошли через утилизацию данных, и на которых были служебные файлы. А уж получить на тестирование смартфон, не залоченный паролем, но с активной привязкой к Google (читай - со всеми письмами, фотками и контактами блоггера-растяпы) - это вообще святое дело.

Похвалим AMD:

Самое интересное, что AMD SEV - это технология как раз для таких беcпечных ребят, как те, что окружают нас с вами. Для тех, кто не ставит каждый апдейт операционной системы, экономит на профессиональной настройке и обслуживании безопасности и на программном обеспечении, надеясь на "авось". Это и возможность для недорогих облачных сервисов заявить об изоляции виртуальной машины, экранированной в том числе от глаз самого провайдера. И всё это работает на бесплатном программном обеспечении и не требует оплаты за лицензию. Это своеобразная Zero-Day защита от ещё не появившихся угроз, которые рано или поздно взломают соседский VPS.

Что касается шифрования памяти всего хоста, то я бы рассчитывал на прозрачную TSME, как на надёжную словно гвоздь технологию. Кто там знает, что операционная система решит шифровать, а что - нет? Простыми средствами из терминала это не проверить, да и при обновлении SME может отключиться. Так что если ваш сверхсекретный сервер хранит государственную тайну, сделайте его устойчивым к Cold Boot атакам простым параметром в BIOS.

Поругаем AMD:

Справедливости ради стоит сказать, что в мае 2018 года исследователи смогли обойти AMD Secure Encrypted Virtualization, получив доступ к памяти гостевой VM, на скомпрометированном гипервизоре. Это очень странная история, и вот почему: например, скрипты для атаки Meltdown/Spectre открыто выкладывают на GitHub, а для истории с "Severed" (именно так назвали эксплоит AMD) есть только одна публикация немецкой лаборатории типа "мы нашли баг - попробуйте разберитесь, как он работает", официальный ответ AMD, звучащий как "Ну мы разберёмся" и ответ немцев на ответ AMD: "Ну уж разберитесь". Всё: ни обсуждений, ни эксплоитов - н и ч е г о! Да, баг достаточно быстро исправили - хватило обновления микрокода, но всё было сделано как-то тихо, без лишней шумихи, как это обычно случается.

Не стоит рассчитывать, что вот сейчас вы поставите бесплатную Ubuntu и получите защищённое облако, как у крупных провайдеров, которые по глупости своей тратят миллионы на ИБ, а вы им нос утрёте. Ничего в этом мире не даётся бесплатно, и версия QEMU/libvirt под Ubuntu, распространяемая через репозиторий AMDSEV представляет собой жалкое зрелище: с 4 Гб ОЗУ виртуальная машина запускается "на ура", с 16 Гб - через раз, а уже с 32 Гб - не запускается вовсе. Из корпоративных линуксов громко заявляющих о поддержке AMD SME и SEV бесплатным является только Oracle Linux с устаревшим (но чертовски быстрым) софтом в репозиториях. На "домашних" дистрибутивах вроде Ubuntu и Fedora и даже Debian, эти функции отключены из-за конфликта с драйверами GPU. Для мира бесплатного софта такая неоднородность - обычное дело.

Цена вопроса и выводы

Рассматривайте защитные функции процессоров EPYC 7000 как экономию на безопасности. У вас аппаратная изоляция виртуальных окружений доступна из коробки, и если вы строите облако на базе Linux, то можете только посмеяться над такими технологиями, как Shielded VM от Microsoft, которые могут при неловком движении превратить ВМ в "кирпич". У вас защита от компрометации хоста подключением непонятных устройств, от загрузки недоверенного гипервизора, у вас виртуалки внутри CPU общаются с кэшем по аналогу VLAN внутри сетевого коммутатора, и всё это с недавнего времени поддерживает миграцию между хостами.

Вы получаете всё это в составе сервера, и для вас стоимость защиты включена в цену железки наряду с доставкой, ценой инсталляции и пакетами расширенной гарантии. Но изначально конфигурируя сервер с AMD EPYC 7000 под Linux, вы понимаете, что технология экранирования VM от компании Microsoft обошлась бы вам в дополнительные 11 550$, ведь именно столько стоит лицензия на Windows Server 2016 Datacenter Edition для 32-ядерного процессора.

Михаил Дегтярёв (aka LIKE OFF)
03/07.2019




ПОХОЖИЕ СТАТЬИ:

Каковы шансы у AMD на серверном рынке? Экспертное мнение и аналитика.

Почему AMD возлагает свои надежды на второе поколение процессоров, объявленное 7 августа 2019 года и суждено ли этим надеждам сбыться? Мы совершим небольшой экскурс в историю, и посмотрим, почему так получилось с Opteron-ами, и как...

Неочевидные проблемы нехватки специалистов по облачной безопасности

Согласно отчету ESG, 53% респондентов считают, что нехватка кадров в области кибербезопасности составляет проблему для их организации. И это касается только общих специалистов, которые занимаются поддержкой и защитой традиционных...

Как поставщики коммуникационных услуг могут защитить сети устройств IoT?

Любой поставщик коммуникационных услуг, поддерживающий сервисы IoT, должен уделять пристальное внимание тем рискам и угрозам безопасности, которые несет в себе Интернет вещей. Устройства IoT по своей природе обладают весьма скудным...

GDPR и облако: три основные функции

Для выполнения строгих требований законодательства в отношении конфиденциальных данных в облачных окружениях организации вынуждены внедрять решения безопасности, которые в целях централизации управления и обеспечения прозрачности о...

Обзор серверной материнской платы ASRock Rack EPYCD8-2T для AMD EPYC 7000

Платформа AMD EPYC 7000 хороша тем, что в 1-сокетном формате вам доступно большое количество каналов PCI Express. Для сборки сервера на несколько GPU это - серьёзное преимущество, ведь 1-процессорная компоновка позволяет собирать к...


НА ФОРУМЕ ГОВОРЯТ



НОВЫЕ СТАТЬИ
Как работают системы бесперебойного энергоснабжения в ЦОДах

В этой статье мы расскажем как в ЦОД обеспечивается бесперебойная работа оборудования с точки зрения резервирования источников питания. В качестве практического кейса в завершение статьи мы рассмотрим недавний инцидент во...

Каковы шансы у AMD на серверном рынке? Экспертное мнение и аналитика.

Почему AMD возлагает свои надежды на второе поколение процессоров, объявленное 7 августа 2019 года и суждено ли этим надеждам сбыться? Мы совершим небольшой экскурс в историю, и посмотрим, почему так получилось с Opteron-ами,...