Розбий моноліт! Kuberton — конференція для DevOps-ів & Python, Java, Ruby, GO розробників. 2-3 March, 2019
×Закрыть

ARM TrustZone: как сделать Linux безопаснее

Меня зовут Андрей Лукин, я Senior Linux Kernel Developer в GlobalLogic. Тема, которую затрону сегодня, довольно обширная, и здесь хочу лишь описать основную идею технологии; те базовые кирпичики, на которых строится техника защиты. А за более подробным рассказом приходите на Root Linux Conference 18 марта в КВЦ «Парковый».

Говорят, что уровень секьюрности системы — это уровень паранойи разработчика. Или, если по-научному, система защищена настолько, насколько защищено самое слабое её звено.

Согласно статистике, доля Linux на персональных компьютерах и ноутбуках в мире едва ли достигает 6%. Но сталкиваемся мы с этой операционной системой, на самом деле, намного чаще. Linux повсеместно используется в серверах, мобильных устройствах, разнообразных embedded-решениях от промышленных агрегатов до бытовой электроники и автомобилей. При этом, не секрет, что Linux не является защищенной операционной системой, в частности, по требованиям американской Orange book (она же The Common Criteria for Information Technology Security Evaluation). То же наличие в системе суперюзера, которому позволено всё, является серьёзным недочётом. Некоторые попытки структурировать защитные механизмы предпринимаются постоянно, например SELinux (Security Enhanced Linux). Но это чисто программный подход, со всеми достоинствами и недостатками. По-хорошему, необходимо комплексное решение. В этой статье я решил сосредоточиться на технологии защиты для ARM-процессоров, поскольку невозможно объять необъятное ещё и в рамках одной публикации.

ARM-платформа стала очень популярной с распространением мобильных устройств; в то же время возросла и стоимость данных для защиты. С повсеместным переводом всего и вся в онлайн — платежей, банкинга, продаж контента — хакеры стали готовы тратить всё большие и большие деньги на подготовку и проведение атак. Никто не гнушается реверс-инжиниринга прошивок, загрузчиков и даже вмешательств в железо. Лакомый кусочек — найти так называемую атаку на целое поколение или даже класс устройств (например, рутование айфонов или взлом игровых приставок Sony PlayStation 4). И если сам процесс взлома может потребовать относительно много времени на исследование, большого опыта и, возможно, дорогостоящих инструментов, включая даже электронный микроскоп, то эксплуатация найденной уязвимости, как правило, не требует серьёзных усилий. Вспомнить тот же Pegasus, который по клику на ссылку, по сути, удалённо рутовал айфон и делал, что хотел на устройстве.

В попытке защититься или хотя бы создать изолированный от всей остальной системы доверенный островок была спроектирована технология — набор компонентов и подход к построению системы — под общим названием ARM TrustZone®.

Разделение миров

В основе концепции ARM TrustZone лежит разделение на уровне аппаратуры среды выполнения на защищенную и незащищенную, далее Secure World (trusted, доверенный мир) и Normal World (non-trusted, недоверенный мир). Причём Normal World (NWd) не имеет доступа к Secure World (SWd), тогда как последний может достучаться куда угодно. Этот подход затрагивает не только процессор, но и память, транзакции на шинах, прерывания, периферийные устройства в рамках System-on-a-Chip (SoC) и, в том числе, программное обеспечение.

Для удобства введем терминологию: Rich OS — полнофункциональная операционная система работающая в Normal World, Secure OS — доверенная операционная система работающая в Secure World и ограниченная в функционале ради безопасности, Trustlet — приложение запущенное в Secure OS, которое может быть предоставлено сторонними разработчиками. TEE — это Trusted Execution Environments, совокупность аппаратных (TrustZone) и программных (Secure OS + приложения) средств обеспечения безопасности критически важных компонентов.

ARM TrustZone (source: ARM) Normal/Secure Worlds (source: ARM whitepaper)

Так что же из себя представляют эти миры?

По большому счету, разницы особой нет. В обоих есть все возможные режимы процессоров (supervisor, user, data abort и т.д.) исключая monitor mode, который всегда secure. Оба могут использовать все регистры, аппаратные блоки SoC. Но SWd может в runtime закрыть от NWd устройства на шине с помощью контроллера TZPC, или куски памяти с помощью контроллера TZASC. Соответственно, если мы обеспечиваем загрузку нашего доверенного кода в Secure World, то он там может выполняться независимо и защищенно от NWd.

Разделение миров

Процедура загрузки и разделения миров обычно выглядит так:
Процессор стартует в режиме монитора, то есть находится в Secure World, и инициирует загрузку так называемой Secure OS, которая будет основой нашего Trusted Execution Environment. Она делает всю необходимую секьюрную конфигурацию системы. Например, она закрывает сканер отпечатков пальцев и часть оперативной памяти от доступа из Normal World. После этого инициируется переход в Normal World, где уже другой загрузчик, например GRUB, запускает Rich OS (Linux/Android) как обычно. Теперь, если Linux захочет проверить отпечаток пальца, он обязан будет отправлять запрос в SWd с помощью команды процессора SMC (Secure Monitor Call) и TEE сможет проверить легитимность этого запроса.

Таким образом, построение Secure World все равно ложится на плечи программиста. Если ничего специально не предпринимать и загрузить Linux «как есть», он будет выполняться в SWd как ни в чём ни бывало, так как никто не производил процедуру «разделения миров» на старте системы.

ARM TrustZone — замена TPM?

Так что же мы можем сделать, находясь в TEE? Как минимум всё то, что обычно возлагается на Trusted Platform Module (TPM). Речь идет о защищённом хранении данных в зашифрованном виде, генерации ключей на основе базового и проверке подписей. Но в любом случае, это не полноценная замена, так как в ARM TrustZone не используются такие специальные аппаратные средства противодействия как «хитрая» топология слоёв микросхемы, шифрование данных на шинах и т.д. Защита здесь лишь та, что получается автоматически, так как аппаратные модули встроены в SoC. Но это же является и преимуществом, поскольку они могут работать на полной скорости системы и защищать каждый компонент SoC.

Тогда зачем это всё нужно?

Классические примеры использования — это защита электронных платежей, проприетарного видео/аудио контента, аутентификация всевозможных данных.

Посмотрим, например, последовательность проверки отпечатка пальца пользователя:

  • Android Lockscreen обратится в демон keystore;
  • Тот, в свою очередь, вызовет keymaster HAL, и при наличии TrustZone обращение пойдёт именно туда;
  • Библиотека обратится к драйверу доступа в TrustZone через соответствующий демон;
  • Вызов TrustZone
  • Драйвер же имеет возможность сделать SMC вызов, в отличие от кода, работающего в user mode процессора;
  • Процессор перейдёт в режим Monitor и передаст управление Secure OS;
  • Та, в свою очередь, запустит соответствующий Trustlet, который будет работать со сканером напрямую, может запросить эталоны отпечатков пальцев из защищённого хранилища и т.д. А в конце концов аутентифицирует пользователя (или нет) для Rish OS. При этом Normal world не может вмешиваться в процесс, так как все необходимые ресурсы (модуль сканера, память) аппаратно закрыты от него.

Новые возможности

Как следствие работы аппаратных компонентов TrustZone на высокой скорости, появляется возможность постоянного runtime-контроля целостности ядра Linux. Грубо говоря, можно регулярно вычислять хэш кода ядра и сверять его с эталонным. Это становится применимым в продакшне, поскольку может быть выполнено очень быстро и незаметно для пользователя.

Более того, мы можем верифицировать не только статический код, но и загружаемые библиотеки, таблицы виртуальных указателей, указатели возврата в стеке и т.д. Есть даже свеженький white paper от Qualcomm с подробностями аппаратной поддержки верификации указателей.

Будущее рядом?

Так что, нужно срочно переводить критический к безопасности код в Trustlets и запускать в TrustZone? Хорошо бы, но пока ещё наличествует огромный зоопарк реализаций Secure OS и всей инфраструктуры для неё. Samsung предлагает своё решение, Qualcomm своё, Renesas опирается на открытые коды OP-TEE, консорциум GlobalPlatform пытается как-то всё систематизировать и выдать спецификацию на API, есть сторонние разработчики вроде Trustonic Mobicore. В итоге, сделать универсальное решение, например, для множества телефонов, не представляется возможным, если ты не сам вендор. Да и корпорациям приходится учитывать разнообразие своих же платформ. Поэтому старый добрый white box ещё пригодится до тех пор, пока Global Platform не отшлифует свою спецификацию или открытый код OP-TEE не станет стандартом де факто.

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

Полезные ссылки

  1. ARM TrustZone official page
  2. Building a Secure System using TrustZone® Technology whitepaper pdf
  3. Introduction to Trusted Execution Environments. University of Cambridge pdf
  4. Trusted Platform Module on Wikipedia
  5. Qualcomm pointer authentication on ARMv8.3 whitepaper
  6. Android explorations by Nikolay Elenkov
LinkedIn

22 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

тащемта слишком как-то маркетингово, дорогая редакция. тру ньюфаги идут например в arm infocenter или хотя бы на хабр habrahabr.ru/post/309618

А и не было цели завалить всех подробностями ARM-архитектуры. Ссылочка на инфоцентр есть, на хабр, чес слово, забыл добавить. Впрочем, welcome на конференцию, там будет более подробно.

Почему-то о TEE приходится слышать только в контексте Linux и embedded устройств. Имхо такой подход вполне пригоден для десктопов и даже серверов.

Хех, на десктопы Майкрософт пытался внедрить secure boot, таакой хайп поднялся :) А для серверов есть Intel TXT, например

У Microsoft есть Hyper-V, которая близка к TEE, поэтому secure boot не так уж необходим. Но это для серверных версий, а для клиентских secure boot мог бы быть полезен.

Но да, но нет. Secure boot — это штука из подмножества TEE.
Майкрософтовская же защита основана на виртуализации и предназначена для серверов. Соответственно закрывает память с помощью MMU и, вроде, даже прерывания защищает. А как насчет DMA-мастеров на шине? На ARM’овском SoC’е же как правило гораздо больше устройств, которые тоже нужно защищать, причем не только закрытием памяти.

Вообще-то у Intel уже 20 лет как есть SMM — это самый близкий аналог TrustZone.

В принципе — да, но не совсем, да и архитектура другая. Так или иначе, аппаратными средствами пытаются защищаться чуть ли не с самого начала истории процессоров. Привилегированные режимы работы, MMU, отдельные чипы TPM, виртуализация... Вопрос в том, от каких атак это защищает, а от каких — нет. TrustZone — очередной виток нацеленный именно на безопасность.

В realtime embedded от этой фичи бегут как от огня, ибо TEE образует гигантские дыры во времени в производительности операционной системы и приложений. Очень хорошо видно на примере гистограмм загрузки ядер в тяжелых приложениях — там дырки по 100мс, когда процесс или ядро просто висело замороженным, ибо выполнялся trusted код.

ну да, прям кто-то ждёт hard realtime на EL1-EL0 когда есть EL2-EL3 c негарантированным временем возврата контекста :) и ещё меряет загрузку ядра мвахахахаха

Кстате никто не мешает запустить QNX в EL1 secure world! Ах да, забыл, микроядро с закрытым кодом, нихрена не поменяешь... Кёртен негодуэ (последние 20 лет)

Кстате никто не мешает запустить QNX в EL1 secure world! Ах да, забыл, микроядро с закрытым кодом, нихрена не поменяешь...
За это и платят большие деньги — за возможность использовать из коробки и ничего не менять. Все когда-то наигрываются в конструкторы, а потом хотят просто ехать без подпиливания на ходу.

Ну пока что в основных своих рынках QNX заменяла не «конструкторы», а другие коммерческие продукты — VxWorks ну или как в случае с Ford Sync — Windows. Из мобильных применений (Blackberry) QNX уже выперли, из массовых сетевых почти выперли, остался автомотив (думаю ещё лет так на 5-7 в IVI поторчит, и всё) и классические области — industrial, military & aerospace, etc. думаю навсегда за QNX, там где её ценят. Но это, конечно offtopic.
P.S. и «использовать из коробки» — это повеселило, да. я помню сколько QSSL (Blackberrry тогда уже) запросил за допиливание фич QNX Car до состояния «из коробки» как того хотел форд в Sync 3.0

Ну пока что в основных своих рынках QNX заменяла не «конструкторы», а другие коммерческие продукты — VxWorks ну или как в случае с Ford Sync — Windows
Не знаю, огорчит тебя эта информация или нет, но рынки VxWorks и Windows практически так и остались, никто никого не заменял. Были «случайные» перемещения, но не более того. А вот основная доля кастомеров — это как раз наевшиеся линукса.
Из мобильных применений (Blackberry) QNX уже выперли,
Ты пытаешься натягивать бизнес мобильных телефонов BlackBerry и QNX, как мобильную платформу. Наоборот, скорее благодаря усилиям BlackBerry туда зашли. Только телефоны трансформировались в IOT. Решение не дешевое, но покупателей хватает, потому как «наевшихся ардуинкой» становится с каждым днём всё больше.
из массовых сетевых почти выперли
Из ширпотребных роутеров по 2 бакса за коробку? %)
думаю ещё лет так на 5-7 в IVI поторчит, и всё
И кто её заменит? Дважды почивший андроид? Windows? этим предсказаниям уже более 10 лет, а воз и ныне там.
P.S. и «использовать из коробки» — это повеселило, да. я помню сколько QSSL (Blackberrry тогда уже) запросил за допиливание фич QNX Car до состояния «из коробки» как того хотел форд в Sync 3.0
Сервисно-продуктовая модель. Хотите такой же, только с перламутровыми пуговицами — придётся платить. Это платформа, а не проинсталлил, поменял скины и продаешь. Весь аутомотив мир это понимает.
Не знаю, огорчит тебя эта информация или нет, но рынки VxWorks и Windows практически так и остались, никто никого не заменял.
ORLY? В автомотиве Windows и µItron кто вытеснил? не хочу тебя расстраивать, но у тебя устаревшая инфа, бро
Ты пытаешься натягивать бизнес мобильных телефонов BlackBerry и QNX, как мобильную платформу. Наоборот, скорее благодаря усилиям BlackBerry туда зашли.
И с каким треском вышли, как мобильная платформа, ага. Софт на Blackberry z10 — редкосное УГ даже в сравнении с китайскими поделками на патченном на коленке дядюшкой Ляо андроиде. Железка, правда, хороша, да. Кстати на автомотив (mass market) QNX тоже не сам зашел, а благодаря бизнесу Хармана.
«наевшихся ардуинкой» становится с каждым днём всё больше.
Я прям вижу как с ардуины норот переходит на qnx и радуется стоимости лицензии. И вообще, я б с удовольствием прочитал об успехах QNX на фронте IoT, а то в гугле ни одного пресс-релиза по теме c 2014, один сплошной автомотив.
Из ширпотребных роутеров по 2 бакса за коробку? %)
Практически отовсюду, кроме carrier. Да и то, изначально QNX-based IOS XR в NCS6000 — уже на Linux.
И кто её заменит? Дважды почивший андроид? Windows? этим предсказаниям уже более 10 лет, а воз и ныне там.
Тащемта Windows уже закончил :), а Андроид ещё и не начинал. Honda CR-V/Accord и последние модели HKM на андроиде не в счёт, это так — PoC проекты. Только с версии O будет первый полновесный .car релиз, и тогда, боюсь, QNX будет трудно. Самые массовые в перспективе рынки азии не используют QNX. Ну и надо помнить что традиционно автомотив медленный, хотя и это меняется
За это и платят большие деньги — за возможность использовать из коробки и ничего не менять.
...
Это платформа, а не проинсталлил, поменял скины и продаешь.
Но это же... взаимоисключающие параграфы! :)

Майк, ты меня пойми — мне QNX нравится, и я в своё время на 6.0 делал маршрутизатор и мучался с дурацким io-net :) но IMHO закрытость QSSL и дебильная маркетинговая политика до добра не доведёт. А attitude типа «линупс — говно а вот кунипс — огого» это просто максима NIH синдрома.

ORLY? В автомотиве Windows и µItron кто вытеснил? не хочу тебя расстраивать, но у тебя устаревшая инфа, бро
Конечно, у аутсорсера больше инфы, безусловно. На тот момент там и вытеснять нечего было. Винда без акселерации или убогая платформа с дисплеем 128×128?
Софт на Blackberry z10 — редкосное УГ даже в сравнении с китайскими поделками на патченном на коленке дядюшкой Ляо андроиде.
Родной софт очень хорошь, то, что уже делали 3rdparty, это уж на их совести. Причём тут QNX, как мобильная платформа?
Кстати на автомотив (mass market) QNX тоже не сам зашел, а благодаря бизнесу Хармана.
Тоже неправда, их купили из-за возросшего влияния. Да, Харман, подстегнул развитие, но именно развитие, а не создал с нуля.
Я прям вижу как с ардуины норот переходит на qnx и радуется стоимости лицензии.
Когда получается устройство, которое нужно суппортить для массмаркета, многие владельцы таких бизнесов пересматривают свои решения в корне. Стоимость лицензии по сравнению со стоимостью поддержки просто мизерная.
И вообще, я б с удовольствием прочитал об успехах QNX на фронте IoT, а то в гугле ни одного пресс-релиза по теме c 2014, один сплошной автомотив.
Ну оно же гуглится на раз-два. ca.blackberry.com/internet-of-things
Практически отовсюду, кроме carrier. Да и то, изначально QNX-based IOS XR в NCS6000 — уже на Linux.
Я вот удивляюсь, тебе каждый производитель докладывает на чём оно работает? :)
а Андроид ещё и не начинал.
Андроид уже два раза с треском проваливался, даже последние отзывы про хонду такие, что вызывают кривую усмешку, эту безусловно полный провал. Убогая поделка на 5-м андроиде, которую гугль заатсорсили на сторону, да и ещё с проприетарной лицензией (кушать-то хочется, ага). Половина автопроизводителей знаешь что сделали? Правильно, решили не ложить все яйца в корзину и используют наш хайпервайзер, где на одной из машин крутится андроид, вот и всё правда жизни. Никто рисковать не хочет.
Только с версии O будет первый полновесный .car релиз, и тогда, боюсь, QNX будет трудно.
Уже 35 лет так говорят :)
Самые массовые в перспективе рынки азии не используют QNX.
Да ты что? Неужели тебе лично доложили? %) Понимаешь, такая инфа не выставляется на показ. Я тебе назову три компании — Beijing Automotive (Hyundai, Benz), Chery (Tata, Jaguar, Land Rover), Geely (Volvo) а это около 75% всего азиатского рынка и ещё кусок европейского, принадлежащего китайцам. Не стоит пытаться быть аналитиком, не имея всей информации.
Но это же... взаимоисключающие параграфы! :)
Ты явно ещё не накушался линукса. Готовая платформа далека от конструктора собери всё сам. Из коробки всё работает, только вот чем будет отличаться один производитель от другого (привет, андроид!)?
но IMHO закрытость QSSL и дебильная маркетинговая политика до добра не доведёт.
Она выглядит для тебя таковой, а это даже меньше видимой части айсберга. Увы, на мелкосерийных производителей поделок больше ставок нет.
Самые массовые в перспективе рынки азии не используют QNX.
Вот, кстати, по поводу использования. У нас есть поддержка одного старого чипсета, который с моей подачи готовили дропнуть в седьмой версии, которая вот-вот выйдет. Все сейлзы говорили, что кастомеров вообще для этой платформы нет ни одного. Дропнули и пожили ровно один месяц, как оказалось было с десяток кастомеров, которые просто использовали продукт из коробки, ни разу не обратившись в саппорт. Обратной связи нет, когда всё работает. Пришлось возвращать поддержку назад. И автопроизводители не исключение, особенно в глобализованном рынке, когда все владеют всеми в разных пропорциях, такая информация даже не выходит за порог, особенно, если есть большой штат разработчиков, которые могут всё делать сами.
А attitude типа «линупс — говно а вот кунипс — огого» это просто максима NIH синдрома.
Понимаешь, это чистый опыт. Мне за 15 лет ковыряния в ядре линукса настолько это вся эта кухня опротивела, что напрочь отбила охоту развиваться в этом направлении. Поэтому, когда я говорю говно, то за этими словами стоит опыт. Кстати, от ядра линукса я так и не смог убежать, т.к. я его отлично знаю, то помогал кастомерам с переводом их продуктов, когда работал в custom engineering группе. Даже после перехода в services я всё равно так или иначе с этим связан.
При этом, не секрет, что Linux не является защищенной операционной системой, в частности, по требованиям американской Orange book (она же The Common Criteria for Information Technology Security Evaluation).

Да он, как бы, по определению даже не ОС. Дистрибутив — ОС, сам Linux — нет. И я думаю, сертифицированность в области security неодинаковая, если сравнить, например, Ubuntu & RHEL.

доля Linux на персональных компьютерах и ноутбуках в мире едва ли достигает 6%.
Это большой прогресс, пару лет назад было ~1%

На DOU так:
Windows 56.17%
Android 17.25%
Macintosh 10.21%
Linux 7.92%
iOS 7.89%
Windows Phone 0.26%

Если брать только десктопы:
Windows 75.73%
Macintosh 13.92%
Linux 10.22%

Скажите, а где-то есть возможность посмотреть исторические данные? Например, было бы интересно глянуть подобную выкладку по ДОУ год-два-три назад.

Я публиковал тут в комментариях некоторую информацию по этому поводу:
www.facebook.com/...o/posts/10155057475913841

Подписаться на комментарии