Кольца защищенного режима разделяют привилегированный код ядра и код приложений, а также отделяют приложения друг от друга. Однако при этом приложения не защищены от атак со стороны привилегированного кода. Зловредное приложение может проникнуть в него с помощью эксплойта и затем внедриться в беззащитную жертву. При этом участок для атаки очень широк: нападать можно и на компоненты ОС, и на само приложение, и даже на аппаратную подсистему.
Смысл SGX состоит в том, чтобы сузить периметр защиты, разместив все критически важные данные в отдельных областях-анклавах, недоступные даже из кода ядра. При этом, однако, не должен коренным образом изменяться процесс разработки и среда, где исполняется приложение.
Приложение состоит из двух частей: доверенного и общего. При запуске оно создает анклав в защищенной части памяти, состоящий из страниц размером 4 Кб. При вызове доверенной функции она видит данные анклава, любой другой внешний доступ (в том числе и со стороны ОС) запрещен. После окончания работы функции анклав остается в защищенной области.
Среда защищенного исполнения встроена в пользовательский процесс, у нее собственные код и данные. Она обеспечивает безопасность, целостность данных, контроль входных точек, поддерживает многопоточность.
При попытке доступа к анклаву проверяется, находятся ли по данному адресу данные вызывающего процесса (EPC, Enclave Page Cache). Далее подвергаются контролю полномочия функции (EPCM, Enclave Page Cache Metadata), и только потом предоставляется требуемый доступ.
Аттестация происходит следующим образом. Анклав запрашивает аппаратно подписанный отчет, содержащий, в том числе информацию о целостности анклава. Этот отчет отсылается на аттестующий сервер, где происходит его верификация. Анклаву высылается ключ приложения (открытая часть ключа), где генерируется подписывающий (приватный) ключ, зависящий от анклава и платформы. Ключ приложения шифруется подписывающим ключом и сохраняется для дальнейшего использования.
Функционал Intel Software Guard Extensions реализуется с помощью комбинации SGX инструкций, поддерживающих локальную аттестацию и предоставляемого Intel аттестационного анклава для поддержки удаленной аттестации.
Разработчики SGX предусмотрели защиту от различного рода атак на данные и код: угрозы со стороны пользовательского и системного ПО, а также загрузчика. Заметим, что средствами SGX невозможно защититься от side-channel уязвимостей, когда злоумышленники собирают статистику использования ЦПУ для определения характеристик исполняемого на нем кода. Для решения подобного рода задач предназначены средства динамического анализа программ, такие, например, как Pin.
Для предотвращения перехвата данных при обмене между процессором и памятью используется Memory Encryption Engine (MEE), работающий как расширение контроллера памяти и поддерживающий технологию SGX. Для определенных областей памяти осуществляется шифрование данных, передающихся по шине. MEE использует специальные комбинации криптографических примитивов для эффективного шифрования при очень жестких требованиях по задержкам.
Как выглядит разработка приложений, поддерживающих SGX? Чувствительные фрагменты кода и данных размещаются в отдельном shared object (.so). Далее определяются интерфейса анклава и генерируются заглушки. Библиотеки SGX взаимодействуют с кодом через API, для разработки используются обычные, привычные для разработчика тулчейны. Для облегчения процесса обработки уже имеется Intel SGX SDK.
Что обещает нам технология Intel SGX? Прежде всего то, что требования к техническим навыкам пользователя, работающего с конфиденциальной информацией, могут быть сильно сокращены. Ей больше не страшны вирусы, трояны и странные программы, которые могут иметься на его компьютере. Далее, повысится доверие к облачным платформам – им можно будет доверять свои приложения, поскольку они будут защищены от любого кода хоста. Конечно, все это дело довольно далекого будущего, ведь процессоры Skylake еще только появились. Но использовать SGX можно уже сейчас. Мы готовы углубляться в эту тему и отвечать на любые вопросы, с ней связанные.
Комментарии (58)
a5b
13.04.2016 20:05+1Сможет ли автор трояна/шифратора воспользоваться SGX для скрытия своего кода/ключей от "враждебного" антивируса?
https://www.virusbulletin.com/virusbulletin/2014/01/sgx-good-bad-and-downright-ugly — "Scenario 1, the botnet creator:… With SGX, the attacker could create an enclave, perform remote attestation with their C&C (command and control) server from inside the enclave, set up some private-public key encryption based on their SGX keys, and receive a payload to execute inside the enclave or any other commands from the C&C server."
Будет ли вводится "белый список" для компаний желающих воспользоваться SGX? Ожидается ли выдача авторам отдельных антивирусов возможности обхода SGX? (Возможен ли обход из ME?)
J. Rutkowska. Thoughts on Intel’s upcoming Software Guard Extensions (Part
2), Sept. 2013. http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-intels-upcoming-software.html "Unless there was a way for “Certified Antivirus companies” to get around SGX protection..."
Возможно ли отключение возможностей SGX в BIOS?
a5b
14.04.2016 02:33+2В работе
"Intel SGX Explained", Cryptology ePrint Archive: Report 2016/086, Jan 2016 https://eprint.iacr.org/2016/086.pdf
действительно подробно описана известная информация об SGX — инициализация привилегированная (потребуется разрешение от ОС, она же может и отключить весь SGX), при инициализации работает Launch Enclave, в которой заложена возможность проверки создаваемого Enclave, вероятно для запуска потребуется сертификат, подписанный Intel:
5.9.2 Licensing "SGX patents… Launch Enclave is intended to be an enclave licensing mechanism that allows Intel to force itself as an intermediary in the distribution of all enclave software."
5.9.3 System Software Can Enforce a Launch Policy "SGX instructions used to load and
initialize enclaves (ECREATE, EADD, EINIT) can only be issued by privileged system software"
5.9.4 Enclaves Cannot Damage the Host Computer "In SGX, the system software can always evict an enclave’s EPC pages to non-EPC memory, and then to disk. The system software can also outright deallocate an enclave’s EPC pages"
5.9.5 Interaction with Anti-Virus Software "Enclave code always executes at the lowest privilege mode (ring 3 / user mode), so it cannot perform any I/O without invoking the services of system software.… SGX’s enclave loading model allows the possibility of performing static analysis on the enclave’s software."
Документация по SGX от Intel:
Intel Software Guard Extensions Programming Reference, 329298-002US, OCTOBER 2014
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf
0serg
13.04.2016 20:07+2Уважаемая компания Intel, а предусмотрена ли возможность принудительно заблокировать выполнение SGX в Ваших процессорах?
В идеале — будет ли доступна широкая линейка процессоров без поддержки SGX?
dartraiden
14.04.2016 02:58Скорее всего нет. Так же, как недоступны чипсеты без ME (см. в комментариях выше). Потребителю выбор не даётся.
zim32
13.04.2016 21:19>Чувствительные фрагменты кода и данных размещаются в отдельном shared object (.so).
Зато сразу ясно где искать интересные данные. И если пропатчить тот сошник, то защиту можно обойти?0serg
13.04.2016 23:32+1Там принцип как я понимаю следующий:
1. Оформляется so-шник в виде небольшой программы с кодом, стеком и данными и к нему дописывается публичный ключ
2. Обычный код загружает этот so-шник вместе с ключем в специальный раздел памяти.
3. После того как загрузка завершена раздел блокируется для любого доступа
4. Процессор аппаратно генерит на все загруженное уникальный хэш (надо полагать с участием соли, хотя в доках про это я не нашел) по которому можно проверить что загруженное соответствует ожидаемому
5. Хэш отсылается обычным же кодом по интернету «владельцу» кода
6. Владелец проверяет что хэш верный и генерирует на основе известного только ему секретного ключа подпись «разблокировки» которую отправляет обратно
7. Программа получив код разблокировки использует его для того чтобы получить доступ к созданному ранее защищенному разделу. Процессор проверяет валидность подписи по публичному ключу.
8. «Доступ» означает что софт может начать выполнять код расположенный в этом разделе. Этот код проверен через хэш разработчиком и его уже невозможно модифицировать «извне».
Таким образом сошник можно пропатчить, но запустить его без разрешения того кто знает секретный ключ уже не получится. Но конечно без интернета и хранения секретного ключа отдельно эта схема не работает. Правда, очевидно, тот кто загружал .so-шник знает о его содержимом. Но это легко поправимо:
9. Помещаем в защищенный подобным образом раздел специальный «загрузчик» который устанавливает зашифрованное безопасное соединение с серваком разработчика
10. Качаем по зашифрованному каналу любой желаемый код либо просто ключ расшифровки к тому что уже лежит в памяти и выполняем полученное в контексте уже созданного «безопасного раздела»
И всё. К тому что таким образом скачано доступ получить без отмычки на уровне процессора будет невозможно.0serg
13.04.2016 23:54А хотя нет. Все даже еще проще. Владелец секретного ключа просто подписывает код с дописанным к нему аппаратным хэшем и всё. Ни соли ни интернета не нужно, хотя при желании тоже можно добавить.
zim32
14.04.2016 00:23Короче авторы вирусов вымогателей вообще ликуют ) Вернуть данные не будет никакой возможности 100%
0serg
14.04.2016 00:29Ну это и сейчас так при правильно написанном вымогателе, к сожалению
KivApple
14.04.2016 00:58Не совсем. Сейчас хотя бы можно запустить вирус под отладчиком и попытаться найти его слабости. Понятное дело, что это не для рядового пользователя, но вполне по силам специалистам антивирусных компаний. Плюс у эвристической защиты больше возможностей для анализа кода (можно анализировать не только системные вызовы, но и сам код). А так получается, что код вируса будет полностью защищён от какого-либо анализа или вмешательства из-вне.
zim32
14.04.2016 05:59С другой стороны, можно написать приложение которое будет монтировать защищенную анклавом файловую систему и тогда никакой вирус не зашифрует на ней ничего. Если я правильно понял.
0serg
14.04.2016 10:40+1Там в лучшем случае возможна только защита уровня «данные на отдельном NAS в сети».
0serg
14.04.2016 01:42+1Хотя нет, напротив все сложнее. Например анклав может запустить кто угодно (со своей собственной подписью), поэтому код работающий в защищенном анклаве получает возможность аппаратно подписывать сообщения ключем интела, процессора и хэша идентифицирующего работающий в анклаве код. Это обеспечивает возможность безопасного установления канала связи с secure enclave гарантирующего защиту от MITM
Хорошее описание SGX здесь
https://eprint.iacr.org/2016/086.pdf
И там куча всего интересного о чем интел не очень-то спешит распространяться. Например о Launch Enclave.
KivApple
14.04.2016 00:55Тут важно каким образом будет реализовано это самое создание защищённой области. Если это будет делаться через привилегированную инструкцию (вызываемую через системный вызов ядра), то на OpenSource-платформах (Linux и т. д.), можно просто сымитировать данное действие, а по факту защиту не делать.
Но вообще, несмотря на якобы благие намерения, это откровенный DRM. Как по мне, если вредоносный код уже проник в ядро ОС, то у него есть тысячи способов нанести ущерб. Одним больше, одним меньше — не суть важно (так что чистое ядро — единственный способ гарантировать безопасность). Тем более, что данная технология точно также хорошо будет играть и на стороне злоумышленника (защита от антивирусов и просто исследования кода антивирусными компаниями).
d_olex
14.04.2016 11:52-1> 5. Хэш отсылается обычным же кодом по интернету «владельцу» кода
И в этот момент вредоносный код (ранее внедривший бекдор в SGX анклав перехватив процедуру его инициализации) подменяет невалидный хэш на валидный, в результате чего программа/сервер думает что все ok.0serg
14.04.2016 16:16+1Полученная в ответ от удаленного сервера для «правильного» хэша подпись не сработает на фактически загруженном коде с «неправильным»
Ca5per
13.04.2016 22:19Видимо пора переходить на процессоры от AMD
dartraiden
14.04.2016 02:59Сначала советую дождаться их полностью новой архитектуры (в конце следующего года) и поглядеть, не будет ли там аналогичной функции. Вполне может оказаться, что переходить вам некуда (разве что на процессоры VIA или архитектуру MIPS).
Да и мы с вами перейдём, а обычный пользователь? В бенчмарках попугаев больше, в играх FPS выше, угадайте, что он возьмёт?Ca5per
14.04.2016 11:04+1Выше сообщили, что у AMD тоже самое, мы в заложниках.
ValdikSS
14.04.2016 15:34Как говорит coderush, у AMD все-таки есть десктопные процессоры без этого.
CodeRush
14.04.2016 16:26+2Мобильные тоже есть, eKabini (FT3) и более старые APU, но тенденция на внедрение fTPM 2.0 для Windows 10 никуда не девается, поэтому AMD может внедрить PSP в десктопные процессоры в любой момент.
0serg
14.04.2016 01:57+2Еще один вопрос к господам из Интела. Согласно вот этому документу
https://eprint.iacr.org/2016/086.pdf
любая процедура инициализации нового secure enclave проходит через специальный защищенный анклав Launch Enclave который предоставляется исключительно самой компанией Intel.
1) Верно ли что любая инициализация Secure Enclave должна проходить проверку в Launch Enclave доступном сугубо от компании Intel?
2) Верно ли что из этого следует что для того чтобы запустить что-либо в Secure Enclave код кроме как в «debug» или «prerelease» версии придется код подписывать у Intel дабы LE авторизовал его инициализацию?
3) Верно ли что процедура аутентификации проводится Launch Enclave через серверы Intel и Intel может в любой момент отозвать авторизацию для ранее подписанного SE?
4) Верно ли что все остальные процедуры аутентификации доступные коду работающему в Secure Enclave базируются на ключе генерируемом в ходе авторизации запуска SE на серверах Intel?
ultrinfaern
14.04.2016 11:02Эта муть — TPM внедренный в процессор. Борцуны авторских прав спали и видели впаянный TPM в каждый компьютер. Ну что-же, Интел подсобил — теперь не нужно никого уламывать, теперь на шару принудительно для всех.
Ca5per
14.04.2016 11:10Сначала это >новые процессоры Intel Skylake не будут работать с Windows 7 и 8
Теперь еще эта ваша новая «фича», крутимся как можем?
Мало вам денег за процессоры?
d_olex
14.04.2016 11:39+2«Меня терзают смутные сомнения» ©(TM) не получится ли с SGX такой же фейл как и с TXT? NB: для тех кто не в курсе истории TXT, там была примерно следующая ситуация: Intel зарелизила технологию TXT, спустя некоторое время ITL показали как обходить TXT через SMM. Для того что бы защититься от продемонстрированной ITL атаки — Intel спустя 5 или около того лет (!!!) создала другой механизм под названием STM, который в настоящий момент времени не используется ни в одном (вообще ни в одном, ноль) реально существующем на рынке продукте. Таким образом, Intel TXT представляет собой broken by design технологию практического смысла в использовании которой нет.
Так вот, возвращаясь к SGX, давайте внимательно прочтем спецификацию и проведем следующий мысленный эксперимент:
1) У нас есть ОС и два приложения: secured app которое при запуске создает SGX анклав, и evil app которое пытается получить доступ к данным которые хранятся внутри анклава. Когда анклав уже запущен — evil app по очевидным причинам не может получить к нему доступ;
2) Процесс evil app делает kill -9 процессу secured app;
3) Когда пользователь или ОС заново запускает secured app — evil app внедряет в процесс secured app код, который перехватывает процедуру загрузки .so в анклав и модифицирует этот самый .so на лету с целью внедрения бекдора внутрь анкалва;
4) Работая внутри анклава бекдор реализует скрытый канал связи с внешним миром который позволяет evil app получить полный доступ к хранящимся в анклаве данным;
5) PROFIT!
Увы, продемонстрировать данную атаку PoC-ом (как я обычно делаю) у меня нет возможности — Intel SGX пока еще нигде не используется. Однако, причин по которым данная атака была бы невозможной я не вижу, такие дела.
PS: алсо, посмеялся с идиотов которые не удосужились разобраться с тем зачем нужен SGX и какие задачи он решает, но зато уже начали вопить а-ля «Intel нарушает нашу свободу!!111», «дайте нам железо без этого вашего SGX» и тому подобный бред :)CodeRush
14.04.2016 12:05+2Подвижки в сторону внедрения STM определенные есть, и его даже можно потестировать на Minnowboard Max, но в остальном ты кругом прав.
Я тоже опасаюсь за будущее SGX, но по несколько другим причинам: технология банально слишком сложная для реализации даже очень опытным разработчиком, поэтому (даже если, по счастливой случайности, в ее реализации не окажется дыр, и твой способ атаки не сработает по каким-то гипотетическим причинам) большая часть софта просто не будет его использовать, плюс еще доступна она буквально на двух с половиной процессорах, требует поддержки со стороны прошивки (но там только память под кэши выделить, ничего сложного), имеет мутный лицензионный статус (так до конца и непонятно, кто кому какие ключи подписывает) и так далее.
Много вы видели софта, который использовал бы AVX2? Я видел полторы оптимизированные вручную опенсорсные утилиты и дорогущий интеловский компилятор. А ведь набору инструкций уже больше трех лет, и он простой как валенок.
Не могу сказать, что SGX вот прямо совсем мертворожденая фигня, как TXT, но в истории с ним очень четко прослеживается тенденция, которую я называю «много развожу, и много вешаю»: на каждом новом поколении Intel пробует какие-то новые технологии, часть которых «выстреливает» и их начинают поддерживать и использовать все (NX bit, SMEP, SMAP те же), а другая тихо уходит в небытие после 2-3 поколений. При этом презентуют их все с максимальной помпой, т.к. Инновации и Технологическое Лидерство. А потом приходят ребята вроде тебя или Рафаля и портят маркетингу всю малину. :)d_olex
14.04.2016 12:13+1> Я тоже опасаюсь за будущее SGX, но по несколько другим причинам: технология банально слишком сложная для реализации даже очень опытным разработчиком
Вот да, в плане правильной реализации это еще более нетривиальная штука чем TXT. Нужно ждать референсную реализацию в общем, а то сейчас чем больше читаешь о том как SGX работает — тем больше вопросов возникает.
0serg
14.04.2016 16:24+13) Для запуска анклава требуется подпись которая зависит от хэша содержимого анклава. Вы можете загрузить в анклав левый код, но запустить его не получится. Причем похоже подпись можно только у Intel получить, причем возможно что только по сети (= возможность отзыва ранее выданной подписи)
4) Дабы избежать MITM код работающий внутри анклава (и только внутри) получает возможность подписывать сообщения секретным ключем зависящим от хэша анклава сделанного на момент запуска. На основе этой подписи сторонний код / сервер может проверить что общается со строго определенным (на момент запуска) кодом работающем в защищенном анклаве
С другой стороны SGX не защищает от ошибок в коде защищенного анклава, плюс довольно проблематично защитить все каналы ввода-вывода. Например безопасный ввод данных с клавиатуры в приложение SGX возможен будет только со специальной клавиатурой с которой можно будет установить зашифрованный канал связи — иначе тот же пароль будет просто перехвачен в драйвере клавиатуры или на уровне передачи символов от ОСи к приложению SGX.d_olex
14.04.2016 16:46+1Я все равно не вполне понял где находится, так сказать, root of trust благодаря которому процессор «знает» какой код исполняемый внутри анклава является модифицированным, а какой нет. Там на каком-то этапе будет нужна цифровая подпись секретная часть ключа для которой есть только у Intel? Из того что я читал про SGX это не вполне очевидно.
Алсо, для QEMU уже реализовали эмуляцию SGX в режиме бинарной трансляции. Получается, из этого следует возможность атаки когда вредоносный код внедряет себя в атакуемое приложение после чего полностью эмулирует SGX для бизнесс-логики этого самого приложения.0serg
14.04.2016 17:20+2Процессор идентифицирует выполняемый код по его хэшу вычисляемому и сохраняемому на этапе инициализации контейнера.
Основная защита строится на основании того что код запущенный в контейнере может подписывать сообщения с использованием секретного ключа хранящегося в процессоре. В эти сообщения принудительно дописывается хэш контейнера который сообщение генерирует. Получаем подписанный секретным ключом хранящимся в процессоре мессадж вида «запущенный на процессоре в безопасном анклаве код с хэшем таким-то сообщает X». То есть процессор гарантирует (своим секретным ключем) что сообщение сгенерировал код идентифицируемый этим хэшем. Для эмуляции этого нужно знать секретный ключ, так что в QEMU скорее всего он просто задан от балды и известен, позволяя отлаживать код, однако подписанные этим кодом мессаджи будут однозначно идентифицированы как сгенерированные не на интеловском процессоре, а QEMU.
Кроме этого в текущей реализации вроде запуск нового анклава возможен только через специальный «стартовый» анклав от самого интела. Стартовый анклав, вероятно, не запустится если его хэш не совпадет с прописанным непосредственно в процессоре (ну или не будет подписан ЭЦП от интела с публичным ключем опять же прошитым в процессоре). А дальше у стартового анклава есть куча возможностей типа, к примеру, отправки хэша контейнера который планируем запускать на сервер к интелу на «одобрение» по списку разрешенных хэшей.d_olex
14.04.2016 23:31> Получаем подписанный секретным ключом хранящимся в процессоре
Получается, достаточно распилить всего один процессор что бы извлечь ключ с помощью которого в последствии можно будет ломать любой SGX анклав где угодно? Не думаю что эти ключи уникальные для каждого CPU, ведь тогда будет нереальный гемор с key management на этапе расшифровки/верифицирования зашифрованного/подписанного сообщения.d_olex
14.04.2016 23:37+2А в прочем нет, судя по докам они таки уникальны. Но key management в данном случае действительно будет болью которая потенциально может вылезти боком в виде рабочих схем атак и прочих проблем с безопасностью.
a5b
15.04.2016 01:57У Apple в SoC Ax зашиты два ключа — GID и UID. GID — в самой схеме для данной модели чипа (как GWK у Интела, см чуть ниже); уникальный для каждого чипа UID — в eFuse. Как показал недавний спор
https://en.wikipedia.org/wiki/FBI-Apple_encryption_dispute и слухи о попытках CIA — https://www.theiphonewiki.com/wiki/GID_Key, ни тот, ни другой дешевыми способами не вытаскиваются. Серийные номера чипа в eFuse уже прошивают при изготовлении, прошить еще несколько десятков байт — не слишком сложно. Сохранять в базе уникальные ключи всех выпущенных чипов не обязательно, если есть общий GWK (GID) ключ, в который можно обернуть все что угодно (а развернуть — только зная GWK ключ). Еще предлагали какую-то магию с записью ключей, обернутых в PUF — http://www.google.com/patents/US20140270177 "sending, by a key server, a global key… encrypting, by the integrated circuit, the global key using a physically unclonable function (PUF) key; and burning ...in fuses in the integrated circuit."d_olex
15.04.2016 21:34+1> ни тот, ни другой дешевыми способами не вытаскиваются
Зависит от того что именно считать дешевым способом, но вообще там несколько другая специфика. Если речь не идет про серьезные защищенные смарт-карты — то содержимое ROM-ов и фьюзов в целом вытаскивается: все технологии и оборудование которое для этого необходимо является коммерчески доступным, так как инвазивный анализ микрочипов активно используют сами же производители микрочипов для fault analysis на этапе запуска в производство нового изделия.
Другое дело, что никто в здравом уме не даст 100% гарантии того, что в ходе инвазивной атаки на один конкретный чип этот самый чип не будет фатально поврежден — это куда большая проблема чем стоимость.
a5b
14.04.2016 17:21+1В процессорах, вероятно, будут ключи: https://eprint.iacr.org/2016/086.pdf "original SGX patents [108, 136] disclose that the Fused Seal Key and the Provisioning Key, which are stored in e-fuses (§ 5.8.2), are encrypted with a global wrapping logic key (GWK). The GWK is a 128-bit AES key that is hard-coded in the processor’s circuitry… Newer Intel patents [67, 68] describe SGX-enabled processors that employ a Physical Unclonable Function (PUF)".
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf 3.4 INTEL SGX KEY AND ATTESTATION "Each processor is provisioned with a unique key as the root of the key hierarchy. This is done at manufacturing time. This key is the basis for all keys derived in the EGETKEY instruction."
Можно построить такие схемы, в которых без знания ключа не получится полной эмуляции SGX.
Ссылка на qemu-симулятор с SGX — https://github.com/sslab-gatech/opensgx https://taesoo.gtisc.gatech.edu/pubs/2016/jain:opensgx.pdf (в нем нет реального ключа от Intel, произвольный ключ подается как опция при запуске)
d_olex
14.04.2016 16:51+1Ну и еще наводящий на интересные мысли вопрос на засыпку: что будет если во время исполнения кода анклава произойдет SMI? :)
Даже если SMI обработчик не сможет прочесть не_зашифрованное содержимое памяти анклава — он все равно получит доступ к сохраненному в SMRAM контексту исполнения SGX из которого вполне себе можно ликнуть ключи и прочую чувствительную инфу.d_olex
14.04.2016 16:58(Это сугубо теоретические измышления, на самом деле я не знаю как именно SGX и SMM учитывают существование друг друга что бы все было крассиво и безопасно)
a5b
14.04.2016 17:14+2Контекст SGX не сохраняется в SMRAM при SMI. Сначала регистры SGX сохраняются внутри Enclave, затем регистры заполняются синтетическим состоянием (4.3.1), после чего начинает работать SMI обработчик
https://software.intel.com/sites/default/files/managed/48/88/329298-002.pdf
Chapter 4. For that reason, such events are called an enclave-exiting events (EEE);
EEEs include external interrupts, non-maskable interrupts, system-management interrupts, exceptions, and VM exits. The process of leaving an enclave in response to an EEE is called an asynchronous enclave exit (AEX). To protect the secrecy of the enclave, an AEX saves the state of certain registers within enclave memory and then loads those registers with fixed values called synthetic state.
6.8.2 SMI while Inside an Enclave
If the logical processor executing inside an enclave receives an SMI when dual-monitor treatment is not enabled, the logical processor exits the enclave asynchronously, and transfers the control to the SMM handler
If the logical processor executing inside an enclave receives an SMI when dual-monitor treatment is enabled, the logical processor exits the enclave asynchronously, and transfers the control to the SMM monitor via SMM VM exit.
All processor registers saved in the SMRAM have the same synthetic values listed in Section 4.3.
0serg
14.04.2016 17:26+2Любые прерывания и выходы принудительно триггерят специальную процедуру «выхода из защищенного анклава» которая сохраняет state анклава в зашифрованный раздел памяти и выдает на выход только код необходимый для продолжения исполнения анклава из сохраненного стейта.
amarao
Простите, я правильно понимаю, что теперь вредоносный код сможет создать области памяти, к которым нельзя получить доступ даже с правами суперпользователя? Например, отладить.
Лично меня, как пользователя, очень возмущает ситуация, что какое-либо ПО создаёт области памяти к которым я не имею права доступа.
И я вижу в этом очередную попытку пропихнуть DRM на мой компьютер за мой счёт.
Спасибо, не надо.
0serg
Ага. Вирусописатели, авторы руткитов и создатели DRM будут счастливы. Технология остроумная и продуманная, но здесь явно тот случай когда вреда будет больше чем пользы.
sumanai
> Спасибо, не надо.
К сожалению, ни вас, ни меня не спрашивают ((
Просто процессоры без этого исчезнут из продажи.
amarao
Это в любом случае будет привилегированная инструкция (т.к. ядро должно понимать, что «эту страницу нельзя своппить») и в приличных ядрах (линукс) обязательно появится возможность её либо запретить (т.е. уронить того, кто её выполнит), либо просто заменить на noop.
Если же каким-то образом её сделают неотключаемой, то добротная виртуализация с pci-passthrough наше всё. Включаем эмуляцию процессора предыдущего поколения — и живём с этим.
В опенсорсе её, ествественно, сделают опциональной. Что будут делать пользователи проприетарных систем, когда windows 10 в 2025 году скажет, что после нового принудительного апдейта старые процы не поддерживаются — не знаю.
nidalee
Не будут обновляться, потому что им это обновление даже не предложат?..
amarao
В рамках новой модели windows — автоматически обновятся и заметят только когда будет слишком поздно.
nidalee
Windows не обновляется, если железо ее не поддерживает. В вашем посте явная несовместимость «старого процессора» с «новой системой».
dartraiden
Так у вас и сейчас уже потенциально может быть запущен код, к которому вы никак не сможете получить доступ и даже узнать о факте запуска. Называется эта штука Intel ME и представляет собой RISC-процессор + немножко собственной оперативной и флеш-памяти. Всё это богатство работает под управлением собственной ОС реального времени и уже лет 10 встроено во все десктопные и мобильные чипсеты Intel. Микропроцессор обладает доступом к оперативной памяти, набортному сетевому контроллеру. Умеет исполнять Java-апплеты, подписанные Intel, и осуществлять функции DRM.
Раньше была возможность прошить вместо BIOS что-то свободное (тот же Coreboot/Libreboot), но после 2008 года требуется подсовывать бинарный блоб для работы ME. При отсутствии оного чипсет принудительно выполняет перезагрузку. Именно по этой причине, кстати, все «свободные» компьютеры, одобренные Фондом СПО (Столлманом и компанией) обладают материнками и процессорами того самого 2008 года, поскольку на более новом железе Libreboot не заработает, а блоб грузить им не позволяют убеждения.
На базе этой же технологии работает удалённое администрирование Intel vPro. Вся разница там в том, что рычаги доступа к vPro доступны пользователю (на соответствующих чипсетах), а ME, хоть и есть абсолютно везде, пользователю совершенно не подконтролен.
У AMD всё аналогично, только хуже изучено и документировано. Если вам захочется свалить из этого ада — придётся попрощаться с архитектурой x86. И с ARM заодно, у них уже давно есть TrustZone.
Теперь решили дать эти возможности более широкому кругу разработчиков.
amarao
И это очень печалит.
MariannaSvetlosanova
д
MariannaSvetlosanova
Давайте не будем паниковать. SGX включается и выключается на уровне BIOS компьютера. Никто насильно никого не обязывает.
тем не менее, это возможность защиты на аппаратном уровне от вредоносного ПО и да, защита своего контента
amarao
Простите, «защита своего контента» от кого? От пользователя?
На всякий случай — я пользователь. И я очень не люблю когда за мой счёт кто-то что-то от меня защищает.
ToSHiC
Вот есть у вас сейчас какой-то ноутбук с процессором от Интела, в котором уже есть ряд мест, куда даже ябро/гипервизор не может подсмотреть:
1. SMM, на центральном процессоре
2. ME, на отдельном процессоре в чипсете
3. довольно мощное ядро в wifi карточке
4. хиленькое ядро в ряде ethernet карточек
5. код, запущенный на GPU
Ещё 5 лет назад один мужик смог сделать firmware для карточки marvell (если я не ошибаюсь), которая могла форвардить пакеты в другие интерфейсы и запускать небольшой шелл на GPU, с доступом ко всей оперативной памяти через DMA.
dartraiden
И это плохо. Но, если в подъезде уже разбили 5 окон, зачем же бить шестое? Наоборот, число таких мест нужно сокращать.
amarao
Доступ к DMA будет только если VT-D или что-то подобное отсутсвует. Остальное — да, печальная правда.
ToSHiC
А VT-D будет изолировать доступ, если инициатором транзакции является pci-e устройство?
a5b
Да (устройства часто обычно сами и инициируют DMA транзакции).
http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
Отображение работает даже для устройств без PASID — "Second-level translation applies to requests-without-PASID" (3.7).
DMA remapping использует source-id (PCI Bus/Device/Function number) для идентификации устройств и выбора таблиц трансляции (раздел 3.9). (Есть предположения о попытках подделать source-id — [11] = doi:10.1109/MALWARE.2010.5665798 — "3.2.2 I/O controller source-id theft"). Не думаю, что root-complex пропустит запрос с левым для данного порта source-id, т.е. атака возможна только из-за дальних мостов, можно представиться другим устройством из-за того же моста.
Даже p2p запросы между двумя pci-e устройствами могут быть оттранслированы, если прошли через Root-complex (а они пройдут, если pcie switch умеет ACS и был настроен).
amarao
Да. Требуется согласие кого-то. Если VT-D используется, то mmu (точнее, IOmmu) учитывает пожелания системы виртуализации (или ядра) о трансляции страниц памяти, в т.ч. в page fault.