Данная статья направлена, прежде всего, на начинающего специалиста, который только
приступил к исследованию методов и способов обеспечения информационной безопасности исполняемого программного кода. С такой задачей рано или поздно сталкиваются все разработчики ПО и системные инженеры, что и произошло на одном из проектов компании Альтирикс системс, в рамках которого необходимо было реализовать защищенное исполнение программного кода в условно не защищенной среде. Для чего, помимо, уже известных и хорошо описанных методов и средств защиты информации, была выбрана, достаточно редко применяемая в российских проектах технология Trusted Execution Environment (TEE) или, говоря по-русски, технология доверенных сред исполнения. Конкретно в этой статье мы решили описать практический пример использования анклавов процессора Intel для доверенной среды исполнения кода (Intel Software Guard Extensions или SGX).

Доверенные среды исполнения поддерживаются далеко не только процессорами данного производителя. Также, TEE поддерживается рядом процессоров AMD (Secure Execution Environment, Secure Technology), процессорами с архитектурой ARM (TrustZone), процессорами с архитектурой RISC-V. Кроме того, TEE поддерживается современными мейнфреймами IBM Z. Мы же выбрали Intel SGX для своего примера поскольку считаем, что на момент написания статьи (лето 2020г.) процессоры Intel наиболее популярны и доступны для начинающих специалистов на постсоветском пространстве. С полным перечнем моделей процессоров Intel с поддержкой Intel SGX можно ознакомиться на сайте Intel в разделе Intel product specifications (ARK), выбрав для поиска соответствующую технологию. И да, возможно, воспользоваться эмуляциями Intel SGX для учебных или исследовательских целей. Работа с несколькими из таких эмуляций выявила ряд сложностей в их настройке. Также нужно понимать, что для реальных боевых проектов никакая эмуляция технологии основанной на аппаратом функционале, естественно, недопустима.

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

Введение

Основной вопрос, который мы задаем в начале пути изучения доверенных сред исполнения: можем ли мы доверять компонентам системы компьютера? А если можем, то каким? Разработчики, а в частности инженеры Intel, дают на этот вопрос однозначный ответ: никому, кроме самого Intel. Что под этим подразумевается? Предлагаю поподробнее в этом разобраться.

Кольца привилегий

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


Кольцо 3. На внешнем кольце располагаются все пользовательские приложения, которые мы используем на компьютере в повседневной жизни, они имеют низший уровень доступа.
Кольцо 2 и 1. На данных уровнях располагаются операционные системы и драйвера устройств.
Кольцо 0. Режим супервизора. Здесь расположено ядро операционной системы (управление периферий, распределение ресурсов между процессами), а также системные драйвера.
Кольцо -1. Гипервизор. Отвечает за распределение ресурсов в случае, если на компьютере одновременно запущены несколько операционных систем, а также отвечает за их изоляцию.
Кольцо -2. Режим системного управления (SMM System Management Mode). Управляет энергообеспечением системы, управляет платами расширения.

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

Анклавы

Основной задачей злоумышленника является получение уровня привилегий, который обеспечил бы ему доступ к необходимым ресурсам системы. Если это секрет приложения-жертвы, то злонамеренному приложению необходим именно тот уровень доступа, который отвечает за хранение секретов в системе. Отсюда напрашивается вывод, что управление секретами приложений стоит доверить самому внутреннему кольцу, ведь доступ туда получить сложнее всего. Однако, данный подход был несколько переосмыслен. Теперь все секреты хранятся на одном уровне с пользовательскими приложениями, как и код, который этими секретами управляет за одним условием: никто, абсолютно никто, кроме процессора, не может получить туда доступ. Программа и данные как бы упакованы в хранилище, в данном случае это хранилище называется анклавом (Enclave закрытый, запертый), ключ от которого есть только у процессора.

Приложения, работающие с доверенной средой

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

Доверенная часть представляет из себя набор функций и процедур, называемых ECALL (Enclave Call). Сигнатура таких функций должна быть прописана в специальном header-файле, а их реализация в файле с исходным кодом. В целом, подход схож с тем, что мы используем при обычном прописывании хедеров, однако, в данном контексте используется специальный C-подобный язык EDL (Enclave Definition Language). Также необходимо прописать прототипы тех функций, которые можно будет вызвать изнутри анклава, такие функции называются OCALL (Outside Call). Прототипы прописываются в том же хедере, где и ECALL-функции, а реализация, в отличие от ECALL, прописывается соответственно в недоверенной части приложения.
Доверенный и недоверенный код жестко связываются между собой сертификацией с использованием протокола Диффи-Хеллмана. За процедуру подписи отвечает процессор, где и хранится ключ обмена информации, обновляющийся каждый раз при перезагрузке системы. Содержимое анклавов хранится в общей памяти, используемой пользовательскими приложениями, однако хранение происходит в зашифрованном виде, расшифровать которую может только процессор. В идеализированном мире, где код анклавов прописан без единого бага, а все железо работает точно так, как это задумал производитель и никак иначе, мы бы получили универсальную, полностью защищенную систему. Основным достоинством данной системы является исполнение секретной части на том же процессоре, где исполняются все остальные программы, в том числе и пользовательские. Однако, в последние несколько лет стало известно о целом классе микроархитектурных уязвимостей современных процессоров, позволяющих получить доступ внутрь анклавов.

Однако, в последние несколько лет перед широкой аудиторий предстало большое количество микроархитектурных уязвимостей современных процессоров, позволяющих получить доступ внутрь анклава: Foreshadow (уязвимость класса Spectre), SGAxe, Zombieload, CacheOut и многие другие. Нет никакой гарантии того, что это список не пополнится очередной серьезной аппаратной уязвимостью, программное исправление которой не иначе как программной заплаткой назвать будет нельзя. Возможно, мы доживем до того времени, когда миру будет представлена абсолютно новая архитектура процессоров, в которой будут исправлены все недостатки, а пока, стоит говорить о том, что у нас есть под рукой. А под рукой у нас есть универсальный, мощный инструмент, серьезно повышающий безопасность современных систем. Повышающий настолько, что он реализован в той или иной интерпретации в миллиардах устройств по всему миру: от умных часов, смартфонов до огромных вычислительных кластеров.

Hello world!

Перейдем от теории к практике. Напишем небольшую программу, которая реализует ставшую уже каноничной задачу: вывести строку Hello world!. В данной интерпретации укажем ещё и место, откуда будет отправлено послание.

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


Запускаем VS и создаем проект Intel SGX.


Выбираем имя для проекта и для решения и ждем далее.

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



Затем добавьте к созданному решение ещё один проект: обычное консольное приложение C++.
В результате в диалоговом окне проектов должна получиться следующая картина:



Затем необходимо связать анклав с недоверенной частью. Жмем правой кнопкой на проект Untrusted part.



Далее необходимо изменить некоторые свойства проектов.




Это необходимо проделать для корректной работы программы. Повторяем действия для обоих проектов.

Также необходимо обозначить в свойствах решения главный проект.


Всё, наша программа готова к реализации.

В данной программе будет 3 файла, с которыми мы будем работать: Enclave.edl (тот самый хедер), Enclave.cpp (прописана реализация ECALLов), Untrusted Part.cpp (главный файл проекта недоверенная часть).

Поместим в файлы следующий код:

Untusted Part.cpp:

#define ENCLAVE_FILE "Enclave.signed.dll" //библиотека, через которую осуществляется подпись анклава#include "sgx_urts.h" //базовый хедер, в котором упакованы функции создания и удаления анклава и многие другие#include "Enclave_u.h" //подключение автоматически сгенерированного файла#include "stdio.h"void print_string(char* buf) //OCALL для вывода текстовой строки - секрета из анклава{printf("ocall output: %s\n", buf);}int main(){sgx_enclave_id_t eid; // id анклава, в проекте может быть несколько анклавов, каждый со своим idsgx_status_t ret = SGX_SUCCESS; //необходимо для отлавливания ошибок на этапе доступа к анклавуsgx_launch_token_t token = { 0 }; //инициализация токена запуска для анклаваint updated = 0; // токен запуска не был изменен const int BUF_LEN = 30; //размер буфера данных, которые мы отправляем в анклавret = sgx_create_enclave(ENCLAVE_FILE, SGX_DEBUG_FLAG, &token, &updated, &eid, NULL); //функция создания анклаваif (ret != SGX_SUCCESS){printf("Failed to create enclave with error number: %#x\n", ret); //отлавливаем ошибки return 0;}char buf[BUF_LEN]; //создаем пустую переменную, в которую запишем секрет из анклаваenclaveChat(eid, buf, BUF_LEN); //вызов ECALL функции printf("\noutput form main(): %s\n", buf); //вывод полученного секрета}

Enclave.edl:

enclave {    from "sgx_tstdc.edl" import *;    trusted {        /* define ECALLs here. */        public void enclaveChat([out, size=len] char* str, size_t len);        /* прописываем сигнатуру функции, которая работает с секретом. OUT - указывает на то, что данные            отправляются из анклава в основную программу, out по отношению к местоположению функции.           Также, для строковых и символьных переменных необходимо прописывать размер буфера информации,           который мы отправляем или получаем из анклава.        */    };    untrusted {        /* define OCALLs here. */        void print_string([in, string] char* buf); //прописываем сигнатуру функции, которая будет осуществлять вывод секрета    };};

Enclave.cpp:

#include "Enclave_t.h"#include "sgx_trts.h"#include <cstring>void enclaveChat(char* str, size_t len){char* secret = "Hello from better place"; // Наша секретная фразаmemcpy(str, secret, len); //копируем секрет по ссылке, которую получилиprint_string(secret); //вызов OCALL-функции вывода строки}

Жмем f7 собираем решение, а затем ctrl+f5 для запуска.

Если у вас выдало ошибку следующего содержания:


убедитесь, что в BIOS активирован Intel SGX: Bios: Security/IntelSGX/Enabled.

В случае, если никаких ошибок не последовало, а перед экраном на консоли вы увидели следующие строки:


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

На сегодня только ленивый не написал про технологию блокчейн, криптовалюты и насколько это круто. Но в этой статье не будет восхваления данной технологии, речь пойдет как раз о ее недостатках и способах их устранения.

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

Проблема заключается в том, что блокчейн сам по себе является автономным, замкнутым объектом, поэтому смарт-контракты внутри блокчейна ничего не знают о внешнем мире. В то же время условия смарт-контрактов часто связаны с информацией о реальных вещах (flight delay, курс валют и т.д.). Для правильной работы смарт-контрактов, информация, полученная извне блокчейна, должна быть надежной и проверенной. Данная проблема решается с помощью использования оракулов, таких как Town Crier и DECO. Данные оракулы позволяют смарт-контракту в сети блокчейн доверять информации с проверенного веб-сервера, можно сказать, что это поставщики надежной информации.

Оракулы

Представьте, что смарт-контракт выполняет перевод 0.001 btc на ваш bitcoin-кошелек в случае победы вашего любимого футбольного клуба в кубке России. В случае действительной победы, смарт-контракту необходимо передать информацию о том, какой клуб победил, и здесь возникает ряд проблем: где взять эту информацию, как ее безопасно передать в смарт-контракт и как убедиться, что информация, поступившая в смарт-контракт на самом деле совпадает с действительностью?

В вопросе с источником информации могут быть 2 сценария: подключение смарт-контракта к доверенному веб-сайту, на котором централизованно хранится информация о результатах матчей и второй вариант подключить сразу несколько сайтов и дальше делать выбор информации по большинству источников, предоставляющих одинаковые данные. Для того, чтобы удостовериться в правильности информации, используются оракулы, например Oraclize, использующий TLSNotary (Модификация TLS для доказательства подлинности данных). Но про Oraclize информации в гугл достаточно, и на Хабре есть несколько статей, я же сегодня расскажу об оракулах, использующих немного другой подход к передаче информации: Town Crier и DECO. В статье приведено описание принципов работы обоих оракулов, а также детальное сравнение.

Town Crier

Town Crier (TC) был представлен IC3 (The Initiative for CryptoCurrencies and Contracts) в 2016 году на CCS16. Основная идея TC: передать информацию с веб сайта смарт-контракту и убедиться, что информация, доставленная TC такая же, как на веб сайте. TC использует TEE (Trusted Execution Environment) для подлинности собственности данных. В оригинальном варианте TC описана работа с Intel SGX.
Town Crier состоит из части внутри блокчейна и части внутри самой ОС TC Server.

TC Contract находится в блокчейне и действует как front end для TC. Он принимает запросы от C_U (смарт-контракт пользователя) и возвращает ответ от TC Server. Внутри TC Server находится Relay, который устанавливает связь анклава с сетью интернет (двунаправленный трафик) и связывает анклав с блокчейном. Enclave содержит prog_encl, который представляет собой код, выполняющий запросы из блокчейна и возвращающий сообщения в блокчейн с цифровой подписью, prog_encl содержит часть кода смарт-контракта и по сути выполняет некоторые из его функций.

Анклав Intel SGX можно рассматривать, как общую библиотеку с API, работающую посредством ecall. Ecall передает управление анклаву. Анклав выполняет свой код, пока не завершится, либо пока не произойдет исключение. Для вызова функций, определенных вне анклава, используются ocall. Ocall выполняется вне анклава и обрабатывается им как ненадежный вызов. После выполнения ocall управление возвращается анклаву.

В части Enclave происходит настройка secure channel с веб-сервером, анклав сам выполняет TLS handshake с целевым сервером и выполняет все криптографические операции внутри себя. Библиотека TLS (mbedTLS) и HTTP-код в уменьшенном варианте экспортированы в среду SGX. Также, Enclave содержит root CA certificates (коллекция сертификатов), чтобы проверять сертификаты удаленных серверов. Request Handler принимает запрос datagram в формате, предоставляемом Ethereum, расшифровывает его и анализирует. Затем генерирует транзакцию Ethereum, содержащую requested datagram, подписывает ее с помощью sk_TC и передает в Relay.

Часть Relay включает в себя Client Interface, TCP, Blockchain Interface. Client Interface нужен для аттестации кода анклава и связи с клиентом. Клиент отправляет запрос на аттестацию с помощью ecall и получает timestamp, подписанный sk_TC вместе с att (сигнатура аттестации), далее att подтверждается с помощью Intel Attestation Service (IAS), а timestamp проверяется доверенным time service. Blockchain Interface проверяет поступающие запросы и размещает транзакции в блокчейн для доставки datagrams. Geth официальный клиент Ethereum и позволяет Relay взаимодействовать с блокчейном через RPC calls.

Работая с TEE, TC позволяет запустить сразу несколько анклавов параллельно, тем самым увеличивая скорость обработки информации в 3 раза. Если при одном работающем анклаве скорость была 15 tx/sec, то при 20 параллельно запущенных анклавах скорость возрастает до 65 tx/sec, для сравнения, максимальная скорость работы в блокчейне Bitcoin 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) был представлен на CCS20, работает с сайтами, поддерживающими TLS соединение. Обеспечивает конфиденциальность и целостность данных.
DECO c TLS используют симметричное шифрование, тем самым у клиента и веб-сервера есть ключи шифрования, и клиент, если захочет, может подделать данные сеанса TLS. Для решения данной проблемы DECO использует трехсторонний протокол рукопожатия между prover (смарт-контракт), verifier (оракул) и web-server (источник данных).

Принцип работы DECO состоит в том, чтобы проверяющий (prover) получил часть данных D и подтвердил верификатору (verifier), что D поступил от TLS-сервера S. Еще одна проблема заключается в том, что TLS не подписывает данные и TLS-клиенту сложно доказать, что данные получены именно с того сервера (provenance difficulty).

В протоколе DECO используются ключи шифрования K_Enc и K_Mac. Клиент отправляет запрос Q на веб-сервер, ответ от сервера R приходит в зашифрованном виде, но клиент и сервер владеют одними и теми же K_Mac, и клиент может подделать TLS сообщение. Решение от DECO состоит в том, чтобы спрятать K_Mac от клиента (prover), пока он не ответит на запрос. Теперь K_Mac разделен между prover и verifier K_p^Mac и K_v^Mac. Сервер получает K_Mac для шифрования ответа с помощью операции над частями ключа K_p^Mac K_v^Mac = K_Mac.

Настроив трехстороннее рукопожатие, обмен данными между клиентом и сервером будет проведен с гарантией безопасности.

Говоря о системе децентрализованных оракулов, нельзя не упомянуть Chainlink, который стремится создать децентрализованную сеть узлов оракулов, совместимую с Ethereum, Bitcoin и Hyperledger, с учетом модульности: каждая часть системы может быть обновлена. При этом для обеспечения безопасности, Chainlink предлагает каждому оракулу, участвующему в задании, выдавать комбинацию ключей (открытый и закрытый). Закрытый ключ используется для генерации частичной подписи, которая содержит их решение на запрос данных. Для получения ответа необходимо объединение всех частичных подписей оракулов сети.

Chainlink планирует провести первоначальный PoC DECO с упором на децентрализованные финансовые приложения, такие как Mixicles. На момент написания статьи вышла новость на Forbes, о том, что Chainlink приобрела DECO у Cornell University.

Атаки на оракулы

С точки зрения информационной безопасности, были рассмотрены следующие атаки на Town Crier:

1. Rogue smart-contact code injection on TEE nodes.
   Суть атаки: передача в TEE заведомо неверного кода смарт-контракта, таким образом, злоумышленник, который получил доступ к узлу, будет иметь возможность выполнить собственный (мошеннический) смарт-контракт на дешифрованный данные. Тем не менее возвращаемые значения будут зашифрованы с помощью private key, и единственный вариант доступа к таким данным заключается в утечке зашифрованного текста при возврате/выводе.
   Защита от данной атаки заключается в проверке анклавом правильности кода, находящегося по текущему адресу. Это может быть достигнуто с помощью схемы адресации, где адрес контракта определяется путем хеширования кода контракта.

   
   

2. Contract state ciphertext changes leak.
   Суть атаки: Владельцы узлов, на которых выполняются смарт-контракты, имеют доступ к contract state в зашифрованной форме вне анклава. Злоумышленник, заполучив управление узлом, может сравнивать contact state до и после выполнения транзакции и может определить, какие аргументы были внесены и какой именно метод смарт-контракта использован, так как сам код смарт-контракта и его технические спецификации общедоступны.
   Защита в обеспечении надежности самого узла.

   
   

3. Side-channel attacks.
   Особый тип атак, использующий мониторинг доступа к памяти и кэшу анклава в различных сценариях. Пример такой атаки Prime and Probe.
   
   Порядок проведения атаки:

   
   
   • t₀: Злоумышленник заполняет весь кэш данных процесса жертвы.
   • t₁: Жертва выполняет код с обращениями к памяти, которые зависят от конфиденциальных данных жертвы (криптографические ключи). Выбор cache line происходит по значению keybit. В примере на рисунке, keybit = 0 и прочитан адрес X в cache line 2. Данные, хранящиеся в X, загружаются в кэш, вытесняя данные, которые были там до этого.
   • t₂: Злоумышленник проверяет, какие из его строк кэша были вытеснены строки, используемые жертвой. Делается это с помощью измерения времени доступа. Повторяя эту операцию для каждого из keybit, злоумышленник получает весь ключ.
   
   

Защита от атаки: В Intel SGX есть защита от side-channel attacks, которая запрещает мониторинг событий, связанных с кэшем, но атака Prime and Probe все равно пройдет, так как злоумышленник наблюдает за событиями кэша своего процесса и разделяет кэш с жертвой.

Таким образом, на данный момент надежной защиты от этой атаки нет.

Известны также атаки типа Spectre и Foreshadow (L1TF), похожие на Prime and Probe. Они позволяют производить чтение данных из кэш-памяти через сторонний канал. Предусмотрена защита от уязвимости Spectre-v2, работающая против двух данных атак.

По отношению к DECO, трехстороннее рукопожатие предоставляет гарантию безопасности:

1. Prover Integrity: взломанный prover не может подделать информацию о происхождении server и не может заставить принимать server недопустимые запросы или отвечать неправильно на действительные запросы. Это осуществимо через шаблоны запросов между server и prover.
2. Verifier Integrity: взломанный verifier не может заставить prover получать неправильные ответы.
3. Конфиденциальность: Взломанный verifier изучает только общедоступную информацию (запрос, имя сервера).

В DECO возможны только уязвимости, связанные с инъекцией трафика. Вначале, при трехстороннем рукопожатии verifier может установить идентичность сервера с помощью fresh nonce. Однако, после рукопожатия verifier должен полагаться на индикаторы сетевого уровня (IP-адреса). Таким образом, связь между verifier и server должна быть защищена от инъекции трафика. Это достигается с помощью использования Proxy.

Сравнение оракулов

Town Crier основан на работе с анклавом в серверной части, DECO же позволяет производить проверку подлинности происхождения данных с помощью трехстороннего рукопожатия и шифрования данных криптографическими ключами. Сравнение данных оракулов проводилось по следующим критериям: быстродействие, безопасность, стоимость и практичность.

Быстродействие: Для работы с DECO требуется настройка трехстороннего рукопожатия, при настройке через LAN это занимает 0.37 секунд, для взаимодействия после установления связи эффективен 2PC-HMAC (0,13 с на запись). Производительность DECO зависит от доступных наборов шифров TLS, размера личных данных и сложности доказательств для конкретного приложения. На примере приложения бинарного опциона от IC3: завершение протокола через LAN занимает около 10,50 с. Для сравнения, Town Crier требуется для выполнения аналогичного приложения примерно 0,6 секунды, то есть примерно в 20 раз быстрее, чем DECO. При равных условиях, TC будет быстрее.

Безопасность: Атаки на анклав Intel SGX (side-channel attacks) работают и могут нанести реальный ущерб участникам смарт-контракта. Относительно DECO возможны атаки, связанные с инъекцией трафика, но использование proxy сводит такие атаки на нет. Поэтому DECO более безопасный.

Стоимость: Стоимость оборудования, поддерживающего работу с Intel SGX выше стоимости настройки протокола в DECO. Поэтому TC дороже.

Практичность: Для работы с Town Crier обязательно специальное оборудование, поддерживающее TEE. Например, Intel SGX поддерживается на процессорах семейства Intel Core 6-го поколения и новее. DECO же позволяет работать с любым оборудованием, хотя есть настройка DECO с использованием TEE. По процессу настройки трехстороннее рукопожатие у DECO может занять некоторое время, но это не идет ни в какое сравнение с ограничением в hardware для TC, поэтому DECO более практичный.

Заключение

Рассмотрев два оракула в отдельности и сравнив их по четырем критериям, видно, что Town Crier уступает DECO по трем пунктам из четырех. DECO более надежный с точки зрения информационной безопасности, дешевле и более практичный, хотя настройка трехстороннего протокола может занять некоторое время и имеет свои минусы, например, дополнительные операции с ключами шифрования. TC работает быстрее DECO, но уязвимость, связанная с side-channel attack делает его подверженным риску потери конфиденциальности. Надо учитывать, что DECO был представлен в январе 2020 года, и еще не прошло достаточно времени, чтобы полагать его безопасным. Town Crier уже 4 года подвергается атакам и прошел через множество проверок, так что его применение во многих проектах оправдано.

Как развеять предубеждения потенциальных пользователей относительно безопасности публичных облаков? На помощь приходит технология 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 наряду с уже задействованными технологиями информационной безопасности и тем самым повысить доверие наших пользователей к хранению и обработке конфиденциальных данных. Надеемся, что в будущем нам ещё предстоит поделиться с вами успешными клиентскими кейсами, хотя и не берёмся утверждать, что наши статьи не будут основаны на историях обнаружения и устранения новых уязвимостей. А пока предлагаем вам поделиться своими методами по защите чувствительных данных в комментариях.

С момента публикации статьи о внедрении 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'/> # 2⁵ = 32₁₀ = 20₁₆
</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 так же будет нам полезно при написании своих собственных решений.

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