Русский
Русский
English
Статистика
Реклама

Криптозащита

Изучаем безопасность офисного ПО какие механизмы влияют на защиту данных

18.12.2020 16:04:56 | Автор: admin


Недавно, издание D-Russia опубликовало авторское мнение Владимира Каталова, исполнительного директора компании Elcomsoft об уровне подверженности к взлому методом перебора защищенных паролем файлов офисного ПО. Компания специализируется на криминалистической экспертизе компьютеров, мобильных устройств и облачных данных, и в своей публикации среди прочего привела оценку безопасности продуктов МойОфис при работе с данными. Мы, как разработчик российского программного обеспечения для совместной работы с документами и коммуникациями, придерживаемся другой точки зрения и хотим обратить внимание на допущенные в публикации неточности.

Сразу стоит сказать, что некорректно приравнивать вопросы сертификации и подтверждения надежности продуктов к имплементации одной конкретной функции парольной защиты документов и, к тому же, отождествлять одну эту функцию с общим уровнем безопасности продуктов МойОфис.

Мы приветствуем экспертизу и развитие Elcomsoft в направлении защиты паролями, при этом хотим отметить, что использование механизмов шифрования документов на основе парольной информации не приводит к обеспечению надлежащего уровня конфиденциальности информации с ограниченным доступом (в обычных редакторах). Линейка защищенных решений любого производителя подразумевает использование комплексной (эшелонированной) защиты на уровне приложения, операционной системы, рабочей станции, сети и информационной инфраструктуры в целом.

МойОфис предлагает средства обеспечения информационной безопасности на уровне приложения. В решениях МойОфис реализованы технологии защиты каналов связи (TLS), функции шифрования и электронной подписи почтовых сообщений, а также возможность поддержки российских криптографических библиотек (подробнее о функциях безопасности). Продукты МойОфис регулярно проходят сертификационные испытания на соответствие требованиям действующих регламентов регулятора, и в полной мере им отвечают. В том числе, продукт МойОфис Стандартный, пробную версию которого изучали специалисты Elcomsoft в своей публикации, успешно прошел сертификацию в ФСТЭК России и получил сертификат, который определяет отсутствие недекларированных возможностей и соответствие требованиям по уровню доверия (подробнее о сертификации).

При необходимости и по желанию заказчика, решения МойОфис могут быть доукомплектованы дополнительными средствами обеспечения информационной безопасности. К числу таковых относятся, как наложенные программные средства, так и программно-аппаратные средства защиты, например защищённые ключевые носители. Продукты МойОфис совместимы с решениями КриптоПро, которые получили широкое распространение в Российской Федерации, в том числе, в органах государственной власти и крупных коммерческих структурах. Комплекс реализованных мер информационной безопасности позволяет нашим пользователям применять продукты МойОфис на объектах критической информационной инфраструктуры.

Учитывая вышесказанное, функция парольной защиты не может считаться единственным и, тем более, ключевым критерием обеспечения информационной безопасности. Из-за ряда своих технологических особенностей, она также не является и объектом сертификации. В целом, согласно действующим регламентам системы сертификации ФСТЭК России, программное обеспечение проходит оценку на предмет соответствия конкретному набору требований, и стандартная функция защиты файла паролем не заявляется как функция защиты.

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

Выбор параметров функции парольной защиты обусловлен требованиями стандартов OOXML и ODF в разрезе критериев обратной совместимости. Учитывая экспоненциальную зависимость скорости подбора ключей от длины ключа, количества символов в пароле и типа используемого набора символов, нам было бы интересно узнать, при каких условиях тестирования удалось наблюдать столь значительный перекос в опубликованных результатах. Мы дополнительно усилим функцию парольной защиты, но еще раз подчеркиваем, она не может комплексно влиять на вопросы безопасности наших продуктов.

Если говорить о шифровании документов, как о методе ограничения доступа к информации, то целесообразно применять не функции парольной защиты, а использовать элементы ИОК (инфраструктуры открытых ключей). В том числе, защищать данные с помощью квалифицированных сертификатов ключей проверки электронной подписи, где уровень криптографической стойкости, включая устойчивость к механизмам подбора пароля, находится принципиально на другом уровне. Подобный способ позволяет производить шифрование с использованием технологии асимметричной криптографии, к которой не применимы атаки методом прямого перебора паролей, на которых специализируется Elcomsoft.

Стойкость электронной подписи в соответствии с ГОСТ Р 34.10-2012 основывается на сложности вычисления дискретного логарифма в группе точек эллиптической кривой, а также на стойкости используемой хэш-функции по ГОСТ Р 34.11-2012. Стандарты криптографической защиты информации разработаны Центром защиты информации и специальной связи ФСБ России совместно с ТК 26.

В статье также содержатся недостоверные данные о применяемых компонентах СПО в решениях МойОфис: это неправда, что функция парольной защиты реализована на базе технологий OpenOffice. Ядро, интерфейс, значительная часть кода платформы МойОфис, в том числе офисные редакторы написаны с нуля, полностью силами специалистов компании (всего более 1,5 млн строк собственного кода). Упоминаемая в статье функция парольной защиты является проприетарной и не имеет никакого отношения к решениям OpenOffice.

Мы приветствуем решение Elcomsoft добавить функцию восстановления паролей к зашифрованным документам и таблицам в форматах документов МойОфис в новых версиях приложений Advanced Office Password Recovery и Distributed Password Recovery. Таким образом, экосистема МойОфис пополнилась еще одним технологическим партнером, лидером в области разработки сервисных утилит в сфере информационной безопасности. Выражаем надежду на дальнейшее сотрудничество в вопросах независимого аудита программных решений МойОфис, что позволит сделать наши продукты еще лучше.
Подробнее..

Стражи публичных облаков как мы внедряли анклавы Intel SGX для защиты чувствительных данных

14.01.2021 16:09:15 | Автор: admin
Как развеять предубеждения потенциальных пользователей относительно безопасности публичных облаков? На помощь приходит технология Intel Software Guard Extensions (Intel SGX). Рассказываем, как мы внедрили её в своём облаке и какие преимущества от нашего решения получила компания Aggregion.





Кратко об Intel SGX и его роли в облаке


Intel Software Guard Extensions (Intel SGX) набор инструкций ЦП, с помощью которых в адресном пространстве приложения создаются частные защищённые области (анклавы), где размещается код уровня пользователя. Технология обеспечивает конфиденциальность и целостность чувствительных данных. Путём изоляции в анклаве они получают дополнительную защиту как от несанкционированного внешнего доступа, в том числе со стороны провайдера облачных услуг, так и от внутренних угроз, включая атаки со стороны программного обеспечения привилегированного уровня.

Принципы работы. Для хранения кода и данных анклавов технология Intel SGX выделяет область памяти Processor Reserved Memory (PRM). ЦП защищает её от всех внешних обращений, в том числе от доступа со стороны ядра и гипервизора. В PRM содержится Enclave Page Cache (EPC), состоящий из блоков страниц объёмом 4 КиБ, при этом каждая страница должна принадлежать только одному анклаву, а их состояние фиксируется в Enclave Page Cache Metadata (EPCM) и контролируется ЦП.

Безопасность EPC обеспечивается за счёт Memory Encryption Engine (MEE), который генерирует ключи шифрования, хранящиеся в ЦП. Предполагается, что страницы могут быть расшифрованы только внутри физического ядра процессора.

Преимущества. Intel SGX позволяет повысить уровень доверия к публичному облаку со стороны организаций, использующих в своей работе чувствительные данные (пароли, ключи шифрования, идентификационные, биометрические, медицинские данные, а также информацию, относящуюся к интеллектуальной собственности). Речь идёт о представителях самых разных отраслей финансового сектора, медицины и здравоохранения, ритейла, геймдева, телекома, медиасферы.

Наш подход к внедрению Intel SGX


Чтобы в публичном облаке G-Core Labs появилась возможность выделять виртуальные машины с анклавами Intel SGX, нам пришлось пройти путь от компиляции патченного ядра KVM и QEMU до написания Python-скриптов в сервисах OpenStack Nova. Вычислительные узлы, которые планировалось использовать для выделения виртуальных машин повышенной безопасности, мы решили определить в отдельный агрегатор тип вычислительных ресурсов, требующий дополнительной настройки. На таких узлах было необходимо:

  • Включить поддержку Intel SGX на уровне BIOS.
  • Поставить патченные QEMU/KVM.

Изначально у нас не было понимания, как это должно работать и что в итоге мы должны прикрутить, чтобы получить ВМ нужной конфигурации. Разобраться с этим вопросом нам частично помогло руководство Intel для разработчиков. С его помощью мы узнали, как подготовить вычислительный узел для работы с SGX и какими дополнительными параметрами должен обладать конфигурационный XML-файл виртуальной машины. Здесь же мы нашли исчерпывающую информацию, как с помощью виртуализации KVM сделать гостевую машину с использованием Intel SGX. Чтобы убедиться, что мы смогли обеспечить поддержку данной технологии, мы использовали два способа:

  • Проверили секцию /dev/sgx/virt_epc в файле /proc/$PID/smaps:

    [root@compute-sgx ~]# grep -A22 epc /proc/$PID/smaps7f797affe000-7f797b7fe000 rw-s 00000000 00:97 57466526/dev/sgx/virt_epcSize:               8192 kBKernelPageSize:        4 kBMMUPageSize:           4 kBRss:                   0 kBPss:                   0 kBShared_Clean:          0 kBShared_Dirty:          0 kBPrivate_Clean:         0 kBPrivate_Dirty:         0 kBReferenced:            0 kBAnonymous:             0 kBLazyFree:              0 kBAnonHugePages:         0 kBShmemPmdMapped:        0 kBFilePmdMapped:         0 kBShared_Hugetlb:        0 kBPrivate_Hugetlb:       0 kBSwap:                  0 kBSwapPss:               0 kBLocked:                0 kBTHPeligible:0VmFlags: rd wr sh mr mw me ms pf io dc dd hg
    
  • И воспользовались данным shell-скриптом, предварительно поставив SGX-драйвер (все действия осуществлялись внутри ВМ):

    [root@sgx-vm ~]# cat check_sgx.sh#!/bin/bashMETRICS="sgx_nr_total_epc_pages \    sgx_nr_free_pages \    sgx_nr_low_pages \    sgx_nr_high_pages \    sgx_nr_marked_old \    sgx_nr_evicted \    sgx_nr_alloc_pages \    "MODPATH="/sys/module/isgx/parameters/"for metric in $METRICS ; do    echo "$metric= `cat $MODPATH/$metric`"done[root@sgx-vm ~]# curl -fsSL https://raw.githubusercontent.com/scontain/SH/master/install_sgx_driver.sh | bash -s - install -p metrics -p page0[root@sgx-vm ~]# ./check_sgx.shsgx_nr_total_epc_pages= 2048sgx_nr_free_pages= 2048sgx_nr_low_pages= 32sgx_nr_high_pages= 64sgx_nr_marked_old= 0sgx_nr_evicted= 0sgx_nr_alloc_pages= 0
    

    Стоит учитывать, что, если одна страница занимает 4 КиБ, то для 2048 страниц требуется 8 МиБ (2048 x 4 = 8192).

Трудности разработки и их преодоление


Отсутствие какой-либо технической документации по интеграции Intel SGX в OpenStack было нашей основной трудностью на момент внедрения. Поиск привел нас к статье проекта SecureCloud, где был представлен способ управления виртуальными машинами с анклавами SGX.

Найденная информация помогла понять, над чем именно нам предстоит работать. В результате мы сформировали следующие задачи:

  1. Добиться от сервиса OpenStack Nova генерации XML-файла с дополнительными параметрами для виртуальных машин с поддержкой Intel SGX.
  2. Написать фильтр планировщика OpenStack Nova с целью определения доступной памяти для анклавов на вычислительных узлах и осуществления некоторых других проверок.

Их выполнения было достаточно для интеграции Intel SGX в наше публичное облако.

Кроме того, мы дописали сбор статистики с учетом EPC:

# openstack usage showUsage from 2020-11-04 to 2020-12-03 on project a968da75bcab4943a7beb4009b8ccb4a:+---------------+--------------+| Field         | Value        |+---------------+--------------+| CPU Hours     | 47157.6      || Disk GB-Hours | 251328.19    || EPC MB-Hours  | 26880.02     || RAM MB-Hours  | 117222622.62 || Servers       | 23           |+---------------+--------------+


Безопасная среда для запуска контейнеризированных приложений



Научившись выделять виртуальные машины с поддержкой Intel SGX, мы использовали платформу SCONE компании Scontain, чтобы обеспечить возможность безопасного запуска контейнеризированных приложений в случае угроз со стороны привилегированного программного обеспечения. При использовании данного решения для прозрачной защиты файловых систем в средах Docker, Kubernetes и Rancher достаточно наличия процессора Intel с поддержкой SGX и драйвера Linux SGX.

Запуск каждого из контейнеров возможен лишь при наличии файла конфигурации, создаваемого клиентским расширением платформы SCONE. В нём содержатся ключи шифрования, аргументы приложения и переменные среды. Файлы, сетевой трафик и стандартные потоки ввода/вывода (stdin/stdout) прозрачно зашифрованы и недоступны даже для пользователей с правами root.
Платформа SCONE оснащена встроенной службой аттестации и конфигурации, проверяющей приложения на соответствие принятой политике безопасности. Она генерирует приватные ключи и сертификаты, которые должны быть доступны только в пределах анклава. Конфиденциальность и целостность данных в процессе их передачи обеспечиваются криптографическим протоколом TLS.

С помощью драйвера SGX для каждого анклава в виртуальном адресном пространстве резервируется до 64 ГБ памяти. Платформа SCONE поддерживает языки программирования C/C++/C#/Rust/Go/Python/Java. За счёт специального компилятора исходный код автоматически (без необходимости дополнительных модификаций) подготавливается к использованию совместно с Intel SGX.

Кейс Aggregion


Завершив все необходимые работы по интеграции Intel SGX, мы подключили к нашему публичному облаку платформу управления распределёнными данными компании Aggregion.

Она предназначена для реализации совместных маркетинговых проектов представителями различных отраслей финансовых и страховых услуг, государственного управления, телекоммуникаций, ритейла. Партнёры анализируют поведение потребителей, развивают таргетированное продвижение товаров и услуг, разрабатывают востребованные программы лояльности, обмениваясь и обрабатывая обезличенные массивы данных на платформе Aggregion. Поскольку утечка конфиденциальной информации крайне не желательна и грозит серьёзными репутационными рисками, компания уделяет особое внимание вопросам безопасности.

Софт Aggregion целиком ставится в контур поставщика данных, что подразумевает наличие в его распоряжении инфраструктуры с поддержкой Intel SGX. Теперь клиенты компании могут рассматривать подключение к нашему публичному облаку в качестве альтернативы аренде или покупке физических серверов.

Принципы безопасной работы на платформе Aggregion. В контуре каждого поставщика чувствительные данные изолируются в анклавы Intel SGX, которые фактически представляют собой чёрные ящики: что происходит внутри, недоступно никому, в том числе и провайдеру облачной инфраструктуры. Проверка первоначального состояния анклава и возможности его использования для хранения конфиденциальной информации осуществляется за счёт удалённой аттестации, когда MrEnclave определяет хеш-значение.

Потенциальная польза для клиентов. Комбинирование баз данных нескольких поставщиков позволяет повысить эффективность совместных рекламных кампаний. При выделении целевой аудитории по заданным параметрам мэтчинг (сопоставление) сегментов выполняется непосредственно внутри контейнеров с поддержкой анклавов Intel SGX. За пределы выводится только конечный результат: например, численность пользователей, соответствующих выбранным атрибутам. Аналогичным образом оценивается эффективность проведенных кампаний: в анклавы выгружаются данные о рекламных показах и совершённых продажах для вычисления прироста покупок целевой группы относительно контрольной, который и выдаётся наружу для дальнейшего использования.



Выводы


Мы понимаем, что Intel SGX не является панацеей по защите данных и можно найти ряд статей, порицающих эту технологию, в том числе и на Хабре. Периодически появляются сообщения об атаках, способных извлечь конфиденциальные данные из анклавов: так, в 2018 году бреши в SGX пробили Meltdown и Spectre, в 2020 году SGAxe и CrossTalk. В свою очередь компания Intel устраняет выявленные уязвимости с помощью обновлений микрокода процессоров.

Почему же мы всё-таки решили внедрить данную технологию? Мы видим в применении Intel SGX возможность сократить потенциальную область кибератак за счёт создания дополнительного контура защиты облачной инфраструктуры G-Core Labs наряду с уже задействованными технологиями информационной безопасности и тем самым повысить доверие наших пользователей к хранению и обработке конфиденциальных данных. Надеемся, что в будущем нам ещё предстоит поделиться с вами успешными клиентскими кейсами, хотя и не берёмся утверждать, что наши статьи не будут основаны на историях обнаружения и устранения новых уязвимостей. А пока предлагаем вам поделиться своими методами по защите чувствительных данных в комментариях.
Подробнее..

Как мы добавляли CPU флаги Intel SGX в libvirt

22.04.2021 14:23:53 | Автор: admin
С момента публикации статьи о внедрении Intel SGX в наше публичное облако прошло несколько месяцев. За это время решение было существенно доработано. В основном улучшения касаются устранения мелких багов и доработок для нашего же удобства.



Есть, однако, один момент, о котором хотелось бы рассказать подробнее.



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

Первые попытки


Ещё раз повторим формулировку задачи: нам требовалось передать параметры поддержки SGX в конфигурационный XML-файл виртуальной машины. Когда мы только начинали эту задачу решать, в OpenStack и libvirt поддержки SGX не было, соответственно, передать их в XML виртуальной машины нативно было невозможно.

Сначала мы попытались решить эту проблему путем добавления блока Qemu command-line в скрипт подключение к гипервизору через libvirt, как это описано в руководстве Intel для разработчиков:

<qemu:commandline>     <qemu:arg value='-cpu'/>     <qemu:arg value='host,+sgx,+sgxlc'/>     <qemu:arg value='-object'/>     <qemu:arg value='memory-backend-epc,id=mem1,size=''' + epc + '''M,prealloc'/>     <qemu:arg value='-sgx-epc'/>     <qemu:arg value='id=epc1,memdev=mem1'/></qemu:commandline>

Но после этого у виртуальной машины добавилась вторая процессорная опция:

[root@compute-sgx ~] cat /proc/$PID/cmdline |xargs -0 printf "%s\n" |awk '/cpu/ { getline x; print $0 RS x; }'-cpuSkylake-Client-IBRS-cpuhost,+sgx,+sgxlc

Первая опция задавалась штатно, а вторая была непосредственно нами добавлена в блоке Qemu command-line. Это приводило к неудобству при выборе модели эмуляции процессора: какую бы из моделей процессоров мы ни подставляли в cpu_model в конфигурационном файле вычислительного узла Nova, в виртуальной машине мы видели отображение хостового процессора.

Как решить эту проблему?

В поисках ответа мы сначала пробовали экспериментировать со строкой <qemu:arg value='host,+sgx,+sgxlc'/> и пытаться передать в неё модель процессора, но это не отменяло дублирование этой опции после запуска ВМ. Тогда было решено задействовать libvirt для присвоения флагов CPU и управлять ими через конфигурационный файл Novы вычислительного узла с помощью параметра cpu_model_extra_flags.

Задача оказалась сложнее, чем мы предполагали: нам потребовалось изучить инструкцию Intel IA-32 CPUID, а также найти информацию о нужных регистрах и битах в документации Intel об SGX.

Дальнейший поиск: углубляемся в libvirt


В документации для разработчиков сервиса Nova указано, что маппинг CPU флагов должен поддерживаться самим libvirtом.

Мы нашли файл, в котором описываются все флаги CPU это x86_features.xml (актуален с версии libvirt 4.7.0). Ознакомившись с этим файлом, предположили (как выяснилось потом, ошибочно), что нам нужно лишь получить hex-адреса необходимых регистров в 7-м листе с помощью утилиты cpuid. Из документации Intel мы узнали, в каких регистрах вызываются нужные нам инструкции: sgx находится в EBX регистре, а sgxlc в ECX.

[root@compute-sgx ~] cpuid -l 7 -1 |grep SGX      SGX: Software Guard Extensions supported = true      SGX_LC: SGX launch config supported      = true[root@compute-sgx ~] cpuid -l 7 -1 -rCPU:   0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc000600

После добавления флагов sgx и sgxlc со значениями, полученными с помощью утилиты cpuid, мы получили следующее сообщение об ошибке:

error : x86Compute:1952 : out of memory

Сообщение, прямо говоря, не очень информативное. Чтобы хоть как-то понять, в чём проблема, мы завели issue в gitlabe libvirta. Разработчики libvirta заметили, что выводится неверная ошибка и исправили ее, указав на то, что libvirt не может найти нужную инструкцию, которую мы вызываем и предположили, где мы можем ошибаться. Но понять, что именно нам нужно было указывать, чтобы ошибки не было, нам так и не удалось.

Пришлось зарыться в источники и изучать, это заняло много времени. Разобраться удалось лишь после изучения кода в модифицированном Qemu от Intel:

    [FEAT_7_0_EBX] = {        .type = CPUID_FEATURE_WORD,        .feat_names = {            "fsgsbase", "tsc-adjust", "sgx", "bmi1",            "hle", "avx2", NULL, "smep",            "bmi2", "erms", "invpcid", "rtm",            NULL, NULL, "mpx", NULL,            "avx512f", "avx512dq", "rdseed", "adx",            "smap", "avx512ifma", "pcommit", "clflushopt",            "clwb", "intel-pt", "avx512pf", "avx512er",            "avx512cd", "sha-ni", "avx512bw", "avx512vl",        },        .cpuid = {            .eax = 7,            .needs_ecx = true, .ecx = 0,            .reg = R_EBX,        },        .tcg_features = TCG_7_0_EBX_FEATURES,    },    [FEAT_7_0_ECX] = {        .type = CPUID_FEATURE_WORD,        .feat_names = {            NULL, "avx512vbmi", "umip", "pku",            NULL /* ospke */, "waitpkg", "avx512vbmi2", NULL,            "gfni", "vaes", "vpclmulqdq", "avx512vnni",            "avx512bitalg", NULL, "avx512-vpopcntdq", NULL,            "la57", NULL, NULL, NULL,            NULL, NULL, "rdpid", NULL,            NULL, "cldemote", NULL, "movdiri",            "movdir64b", NULL, "sgxlc", NULL,        },        .cpuid = {            .eax = 7,            .needs_ecx = true, .ecx = 0,            .reg = R_ECX,        },

Из приведенного листинга видно, что в блоках .feat_names побитово (от 0 до 31) перечисляются инструкции из EBX/ECX-регистров 7-го листа; если инструкция не поддерживается Qemu или этот бит зарезервирован, то он заполняется значением NULL. Благодаря этому примеру мы сделали такое предположение: возможно, нужно указывать не hex-адрес необходимого регистра в libvirt, а конкретно бит этой инструкции. Проще это понять, ознакомившись с таблицей из Википедии. Слева указан бит и три регистра. Находим в ней нашу инструкцию sgx. В таблице она указана под вторым битом в регистре EBX:



Далее сверяем расположение этой инструкции в коде Qemu. Как мы видим, она указана третьей в списке feat_names, но это потому, что нумерация битов начинается от 0:

    [FEAT_7_0_EBX] = {        .type = CPUID_FEATURE_WORD,        .feat_names = {            "fsgsbase", "tsc-adjust", "sgx", "bmi1",

Можно посмотреть другие инструкции в этой таблице и убедиться при подсчете от 0, что они находятся под своим битом в приведенном листинге. Например: fsgsbase идет под 0 битом регистра EBX, и он указан в этом списке первым.

В документации Intel мы нашли этому подтверждение и убедились, что необходимый набор инструкций можно вызвать с использованием cpuid, передавая правильный бит при обращении к регистру нужного листа, а в некоторых случаях подлиста.

Мы стали более подробно разбираться в архитектуре 32-битных процессоров и увидели, что в таких процессорах имеются листы, которые содержат основные 4 регистра: EAX, EBX, ECX, EDX. Каждый из этих регистров содержит по 32 бита, отведенных под определенный набор инструкций CPU. Бит является степенью двойки и чаще всего может передаваться программе в hex-формате, как это сделано в libvirt.

Для лучшего понимания, рассмотрим еще пример c флагом вложенной виртуализации VMX из файла x86_features.xml, используемый libvirtом:

<feature name= 'vmx'>
<cpuid eax_in='0x01' ecx='0x00000020'/> # 25 = 3210 = 2016
</feature>

Обращение к этой инструкции осуществляется в 1-м листе к регистру ECX под 5 битом и убедиться в этом можно посмотрев таблицу Feature Information в Википедии.

Разобравшись с этим и сформировав понимание, как в итоге добавляются флаги в libvirt, мы решили добавить и другие флаги SGX (помимо основных: sgx и sgxlc), которые имелись в модифицированном Qemu:

[root@compute-sgx ~] /usr/libexec/qemu-kvm -cpu help |xargs printf '%s\n' |grep sgxsgxsgx-debugsgx-exinfosgx-ksssgx-mode64sgx-provisionkeysgx-tokenkeysgx1sgx2sgxlc

Некоторые из этих флагов являются уже не инструкциями, а атрибутами структуры управления данными анклавов (SECS); подробнее об этом можно прочитать в документации Intel. В ней мы нашли, что необходимый нам набор атрибутов SGX находится в листе 0x12 в подлисте 1:

[root@compute-sgx ~] cpuid -l 0x12 -s 1 -1CPU:   SGX attributes (0x12/1):      ECREATE SECS.ATTRIBUTES valid bit mask = 0x000000000000001f0000000000000036



На скриншоте таблицы 38-3 можно найти необходимые нам биты атрибутов, которые мы укажем позже в качестве флагов в libvirt: sgx-debug, sgx-mode64, sgx-provisionkey, sgx-tokenkey. Они находятся под битами 1, 2, 4 и 5.

Так же мы поняли из ответа в нашем issue: libvirt имеет макрос проверки флагов на предмет их поддержки непосредственно процессором вычислительного узла. Это означает то, что недостаточно указать в документе x86_features.xml необходимые листы, биты и регистры, если сам libvirt не поддерживает лист набора инструкций. Но к нашему счастью выяснилось, что в коде libvirta имеется возможность работы с этим листом:

/* Leaf 0x12: SGX capability enumeration * * Sub leaves 0 and 1 is supported if ebx[2] from leaf 0x7 (SGX) is set. * Sub leaves n >= 2 are valid as long as eax[3:0] != 0. */static intcpuidSetLeaf12(virCPUDataPtr data,               virCPUx86DataItemPtr subLeaf0){    virCPUx86DataItem item = CPUID(.eax_in = 0x7);    virCPUx86CPUIDPtr cpuid = &item.data.cpuid;    virCPUx86DataItemPtr leaf7;    if (!(leaf7 = virCPUx86DataGet(&data->data.x86, &item)) ||        !(leaf7->data.cpuid.ebx & (1 << 2)))        return 0;    if (virCPUx86DataAdd(data, subLeaf0) < 0)        return -1;    cpuid->eax_in = 0x12;    cpuid->ecx_in = 1;    cpuidCall(cpuid);    if (virCPUx86DataAdd(data, &item) < 0)        return -1;    cpuid->ecx_in = 2;    cpuidCall(cpuid);    while (cpuid->eax & 0xf) {        if (virCPUx86DataAdd(data, &item) < 0)            return -1;        cpuid->ecx_in++;        cpuidCall(cpuid);    }    return 0;}

Из этого листинга видно, что при обращении к 2-му биту EBX регистра 7-го листа (т.е. к инструкции SGX), libvirt может задействовать лист 0x12 для проверки имеющихся атрибутов в подлистах 0, 1 и 2.

Заключение


После проделанного исследования мы поняли, как правильно дополнить файл x86_features.xml. Мы перевели необходимые биты в hex-формат и вот что у нас получилось:

  <!-- SGX features -->  <feature name='sgx'>    <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x00000004'/>  </feature>  <feature name='sgxlc'>    <cpuid eax_in='0x07' ecx_in='0x00' ecx='0x40000000'/>  </feature>  <feature name='sgx1'>    <cpuid eax_in='0x12' ecx_in='0x00' eax='0x00000001'/>  </feature>  <feature name='sgx-debug'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000002'/>  </feature>  <feature name='sgx-mode64'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000004'/>  </feature>  <feature name='sgx-provisionkey'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000010'/>  </feature>  <feature name='sgx-tokenkey'>    <cpuid eax_in='0x12' ecx_in='0x01' eax='0x00000020'/>  </feature>

Теперь для передачи этих флагов виртуальной машине мы можем указать их в конфигурационном файле Nova с помощью cpu_model_extra_flags:

[root@compute-sgx nova] grep cpu_mode nova.confcpu_mode = customcpu_model = Skylake-Client-IBRScpu_model_extra_flags = sgx,sgxlc,sgx1,sgx-provisionkey,sgx-tokenkey,sgx-debug,sgx-mode64[root@compute-sgx ~] cat /proc/$PID/cmdline |xargs -0 printf "%s\n" |awk '/cpu/ { getline x; print $0 RS x; }'-cpuSkylake-Client-IBRS,sgx=on,sgx-mode64=on,sgx-provisionkey=on,sgx-tokenkey=on,sgx1=on,sgxlc=on

Проделав сложный путь, мы научились добавлять в libvirt поддержку флагов SGX. Это нам помогло решить проблему дублирования процессорных опций в XML-файле виртуальной машины. Полученный опыт мы будем использовать и в дальнейшей работе: если в процессорах Intel или AMD появится новый набор инструкций, мы сможем их аналогичным образом добавить в libvirt. Знакомство с инструкцией CPUID так же будет нам полезно при написании своих собственных решений.

Если у вас есть вопросы добро пожаловать в комментарии, постараемся ответить. А если у вас есть, что дополнить тем более пишите, будем очень признательны.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru