Linux для arm cortex a9

Установка Linux на ARM. Подробная пошаговая инструкция и советы

Установка Linux на ARM — это довольно интересная тема. Даже принимая только то, что это довольно-таки необычно. Почему необычно? П отому что в ARM-процессорах совсем другая архитектура, чем у тех, для которых рассчитано большинство дистрибутивов Линукс.

Для тех , кто не знает, ARM — архитектура маленьких микр оп роцессоров. Если простым языком, то это архитектура процессора у маленьких компьютеров или мобильных телефонов. Поэтому вопрос : вы часто видели Linux на смартфоне (процессоре ARM)?

Основная масса больших и привычных ПК имеют архитектуру х86 или AMD64. Данные процессоры рассчитаны на трудо- и ресурсоемкие задачи:

• редактирование фотографий;
• редактирование музыки или видео;
• работа с базой данных;
• программирование и т.д .

Но в т о ж е время ARMка имеет более низкое энергопотребление при должной производительности, а это как раз очень важно для небольших устройств. И поэтому она распространена в «маленьких» устройствах.

Какие операционные системы подходят для ARM?

В принципе на ARM — устройствах можно запустить любую операционную систему, которая была скомпилирована под данную архитектуру. Поэтому обычные Линукс версии, которые мы уже привыкли наблюдать на своих ПК , просто не подойдут , д аже если они легковесны и подходят по другим параметрам. Но в т о ж е время в сети можно найти приличное количество уже «готовых» дистрибутивов Linux для ARM — процессоров. Ярким представителем является известный всем Android, из менее известных, но популярных — Kali Linux.

Кстати, а вы знали, что популярный Android мегакорпорации Google — это всего лишь «операционка» на основе ядра Linux ? Пр ит ом, что Андроид является самой популярной операционной системой для мобильных телефонов — этот факт, как видите, малоизвестен. Но вообще нужно понимать, что Linux здесь является всего лишь «ядром». А ядро — это всего лишь основной функционал, предполагающий использование устройствами опций аппаратной системы, драйверов, управления, утилиты для командной строки и др. Семейство Linux подразумевает совокупность всех операционных систем, использующих его ядро, но это не есть самостоятельное ядро. Различие всем системам «семейства» придает графическая оболочка, но это совсем другая история. Однако возможность использовать эти ОС без графической оболочки, а только через текстовую командную строку, расширяют сферу их применения. Именно поэтому их можно «заметить» в необычных местах:

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

Итак, из семейства Linux для ARM можно подобрать конфигурации у следующих дистрибутивов:

1. Debian. Это одна из самых старых версии Линукса, большое сообщество, много программ , написанных для этой системы, стабильность работы и мн.др. Его можно «найти» практически везде, также и в ARM — процессорах.
2. Ubuntu. Кто не слышал о б Убунту, тот не слышал о Линукс. С читается , что у него бо л ее продвинутое интерфейсное оформление, чем у Дебиан, да и вообще он сам более продвинутый. Встречается в ARM — процессорах, но совсем недавно анонсирована Ubuntu Phone — специальная ОС для смартфонов, которая будет призвана конкурировать с Android. Проект анонсирован, но пока должного «движения» не замечено.
3. Kali, Arch, Gentoo и др. , и каждый со своей отличительной особенностью , и каждый используется в ARM — системах.

На самом деле , этот список можно продолжать очень долго, потому что прогресс не стоит на месте, а земля наша слави тся умельцами. И многие разработчики «подтачивают» тот или иной дистрибутив Linux под ARM — процессор.

Установка Linux на ARM — устройство

Как правило, приобретая какое-либо устройство на ARM — процессоре, вы его получаете уже с предустановленной ОС. Чаще всего на таких устройствах идет Android. Допустим, вы все равно хотите установить Linux на это ARM — устройство. Тогда у вас есть 2 пути:

1. Полноценная «перепрошивка» на «чистое железо» ;
2. Установка «внутри» или «рядом» с Android (или другой системы, суть от этого не меняется).

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

Советы при установки Linux на ARM — устройство

На самом деле , совет будет один. Подумайте , прежде чем устанавливать Linux на свое ARM — устройство, тем более если на нем уже предустановлена производителем ОС. Потому что это не что иное , как хакинг — то есть преднамеренно е вмешательство в работу операционной системы. И никто , кроме вас , разделять риски работы устройства не будет.

Сама технология установки Linux на ARM еще в довольно «сырой» форме. Да, есть какие-то наработки и отдельные дистрибутивы. Есть умельцы, которые делают это и говорят, что это круто. Но в целом материала и стабильности в этом мало. Это не касается тех устройств, в которых Linux предустановлен производителем!

Но в т о ж е время четко вырисовывается тенденция, что за ARM — процессорами будущее. Этому свидетельствует даже тот факт, что первое место в рейтинге суперкомпьютеров ТОП — 500 в 2021 году с большим отрывом по производительности от конкурентов занимает машина на ARM — процессорах!

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Небольшой экскурс в Linux на ARM и ArchLinux на Mele A1000/A2000

Всем привет.
Смотря видео на youtube, как запускают ubuntu на одноплатных компьютерах вроде Mele A1000 или MK802, решил я, что нужно что-то делать с производительностью и заодно запустить ArchLinux на этом устройстве, т.к. этого, почему-то, пока еще никто не сделал.

Проблема производительности

Почему мы видим, что все устройства на ARM и MIPS работают так медленно в качестве десктопных систем? Причин множество:

1. Все устройства разные. Некоторые поддерживают один набор команд, некоторые — другой. У некоторых есть FPU, у некоторых — нет. Некоторые ARMv5, другие ARMv6, третьи ARMv7
2. Неоптимизированность компиляторов.
3. Нерасторопность / бездействие производителей.
4. Сложность поддержки и нерасторопность мейнтейнеров дистрибутивов.

Если для x86 первое практически не имеет значения, т.к. у всех есть FPU и оптимизации под конкретный процессор дают не более 5-10% производительности, то ARM устройства могут получить колоссальный прирост, для Mele это что-то вроде от 30% до 150% на сложных задачах с плавающей точкой (как, например, декодирование видео).
Так как полноценной поддержки в mainline-ядре реальных устройств, а не тестовых плат, практически нет, мы вынуждены пользоваться ядром от производителя, которое хорошо, если третей ветки. Причем зачастую изменения в ядро вносятся через зад, из-за чего мы получаем в меню конфигурации отсутствующие зависимости между опциями и практически невозможность портировать эти изменения на более свежие ядра средствами энтузиастов (это, конечно, не у всех).
Мейнтейнеры дистрибутивов не хотят тратить силы, вычислительную мощность и место на дисках для дополнительных репозиториев, и очень долгое время компилировали все либо с эмуляцией FPU, либо с softfp(позволяет использовать FPU, но совместимо с эмуляцией), и с оптимизациями под ARMv5, но, примерно чуть больше года назад, когда Cortex-A8 пошел в массы, мейнтейнеры задумались и решили попробовать все компилировать с hardware floating point. Так, ubuntu 12.04 стал первым массовым дистрибутивом, в котором появился armhf репозиторий. Это большой прогресс, только это дает Cortex-A8 прирост в 20%-40%, по сравнению с softfp, все приложения теперь собираются под ARMv7, но этого недостаточно.
На сегодняшний день, есть 3 дистрибутива, у которых есть репозитории с hardware floating point: ArchLinux-ARM, Ubuntu и Fedora. Т.к. я люблю ArchLinux, выбор для меня очевиден.

Устройства

«Почему мейнтейнеры собирают пакеты без NEON?», спросите вы:
ARMv7 без набора инструкций NEON (например, Marvell Armada в устройстве CuBox)
Cortex-A8 (ARMv7 + NEON, китайские устройства с Allwinner A10: Mele, MK802, MiniX)
Cortex-A9 без NEON (nVidia Tegra 2 в Toshiba AC100)
Cortex-A9 с NEON
Следует отметить, что VFP в Cortex-A9 уже практический такой же быстрый, как и NEON, и оптимизация под NEON скорее вопрос энергосбережения, нежели производительности.

Что было сделано

• Взят последний U-Boot и ядро из dl.linux-sunxi.org/nightly/latest
• Перекомпилированы важные пакеты с NEON и оптимизациями под Cortex-A8 (glibc, xz, bzip2, gzip, bash, openssl, zlib)
• Перекомпилированы пакеты, до которых у меня дотянулись руки (mplayer2)
• Добавлен видеодрайвер и GLES библиотеки (не уверен на счет работоспособности)
• Все компилировалось Linaro GCC, т.к. он самый оптимизированный под ARM.

CFLAGS:
march=armv7-a -mfloat-abi=hard -mfpu=neon -ftree-vectorize -mvectorize-with-neon-quad -mcpu=cortex-a8 -mtune=cortex-a8 -mthumb -O2 -pipe -fstack-protector —param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2

Не работает аппаратное ускорение видео.
Пока непонятно, работает ли gles, т.к. glxinfo говорит, что direct rendering: yes, glxgears крутятся, но как-то не очень. В качестве сервера использовать можно.

Чтобы запустить интерфейс, нужно зайти по ssh root/root и набрать startx

Если у вас есть желание и возможность помочь, вы любите ArchLinux и хотите видеть его на китайских устройствах на Allwinner, пожалуйста, свяжитесь со мной.

И немножко еще информации: Allwinner работает с XBMC над видеоускорением в XBMC for Android. Будет настоящий STB, а то сейчас как-то даже нет ничего.

Источник

Загрузка ОС на ARM

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

Загрузка ARM в четырех прямоугольниках — под катом.

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

Разновидности процессоров ARM

Если вы знаете про ARM, то этот раздел можно смело пропустить.

В производстве и эксплуатации сейчас встречаются процессоры ARM пяти архитектур: ARMv4, ARMv5, ARMv6, ARMv7 и ARMv8. Компания ARM дает этим архитектурам коммерческие названия, поэтому ARMv4 называется, например, ARM7, ARMv5 – ARM9, а название Cortex имеют процессоры на архитектурах ARMv6, v7, v8. Следующая таблица перечисляет основные разновидности.

Архитектура	Коммерческое название	Распространенные виды	Запуск Linux
ARMv4	ARM7	ARM7TDMI	Нецелесообразно
ARMv5	ARM9	ARM926EJ-S	Да
ARMv6	ARM11	ARM1176JZF-S	Да
Cortex-M0	Cortex-M0	Нет
ARMv7	Cortex-M	Cortex-M3	Нецелесообразно
Cortex-A	Cortex-A9	Да
Cortex-R	Cortex-R4	Да
ARMv8	Cortex-A	Cortex-A53	Да

Например, кнопочные телефоны в основном используют ARM7, а смартфоны – Cortex-A. Современные смартфоны строятся преимущественно на ARMv8, единственных 64-битных. Процессоры ARM7 и ARM9 широко применялись в различных промышленных контроллерах, сетевом оборудовании, а сейчас фокус переходит на использование в них Cortex-A. В различной бытовой технике, мелких электронных приборах, в области безопасности и т.п. применяются микроконтроллеры Cortex-M.

Вообще все устройства ARM можно условно разбить на микроконтроллеры и Application Processor.

• Микроконтроллеры отличаются наличием на кристалле Flash-памяти и рабочего ОЗУ. Применяются для задач относительно малой автоматизации.
• Application Processor преимущественно пользуется внешней памятью — DDRAM и Flash. Мы их дальше будем называть просто — процессоры. Масштаб задач у них больше.

Долгое время одни и те же архитектуры ARM7, ARM9 использовались как для построения процессоров, так и микроконтроллеров. С появлением линейки Cortex произошло разделение, и теперь микроконтроллеры называются Cortex-M, а процессоры Cortex-A и Cortex-R.

Виды ОС

Какие есть варианты запуска ОС:

• на микроконтроллерах обычно запущена маленькая ОС реального времени (RTOS) или просто программа без ОС;
• на процессорах чаще запущена ОС общего применения (Linux, Android), иногда маленькая RTOS, иногда полнофункциональная RTOS (типа vxWORKS).

Например, в планшетах и смартфонах используется Android, iOS или вариант Linux. В телекоммуникационном оборудовании может быть Linux или один из вариантов RTOS. В более простом оборудовании может применяться RTOS или программа без ОС.

В дальнейшем мы будем говорить только о запуске ОС (Linux, Android) или RTOS на ARM. По способу запуска “большие” RTOS попадают в одну группу с Linux, а “малые” RTOS объединяются с программами без ОС.

Для запуска Linux хорошо подходят процессоры ARM9, ARM11, Cortex-A. Усеченную версию Linux также можно загрузить на ARM7, Cortex-M4 и Cortex-M7, но это нецелесообразно.

Для запуска малых RTOS подходят микроконтроллеры и процессоры ARM7, ARM9, Cortex-M. В некоторых случаях для RTOS используют начальные модели Cortex-A, например, Cortex-A5. Большинство же процессоров Cortex-A столь сложны, что их возможности можно использовать только совместно с поставляемым производителем Linux/Android SDK, что и определяет выбор в пользу Linux.

Загрузчик ОС

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

Загрузчик обеспечивает загрузку ОС и сервисные функции, такие, как:

• проверка целостности образа ОС перед запуском;
• обновление программ;
• сервисные функции, функции первоначальной инициализации устройства;
• самотестирование.

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

Таким образом, с точки зрения разработчика изделия запуск ОС выглядит следующим образом:

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

Схема “Загрузчик-ОС” очень удобна из практических соображений, ведь загрузчик берет на себя всю низкоуровневую работу:

• инициализирует память перед запуском ОС и загружает ядро ОС в память;
• инициализирует часть периферии;
• часто реализует хранение двух образов ОС: текущего и резервного, или образа для восстановления;
• контролирует образ ОС перед загрузкой;
• дает сервисный режим работы даже при испорченном образе ОС.

Например, для запуска Linux на ARM загрузчик должен инициализировать память, хотя бы один терминал, загрузить образ ядра и Device Tree в память и передать управление на ядро. Все это описано в . Код инициализации ядра Linux не будет делать сам то, что должен делать загрузчик.

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

Рассмотрим работу загрузчика на примере u-boot, загружающего Linux, по шагам.

1. После включения или сброса процессор загружает образ u-boot, хранимый в Flash-памяти, в ОЗУ и передает управление на первую команду этого образа.
2. u-boot инициализирует DDRAM.
3. u-boot инициализирует драйверы загрузочного носителя (ЗН), например, eMMC, NAND Flash.
4. u-boot читает с ЗН область переменных конфигураций. В конфигурации задан скрипт загрузки, который u-boot далее исполняет.
5. u-boot выводит в консоль предложение прервать процесс загрузки и сконфигурировать устройство. Если за 2-3 секунды пользователь этого не сделает, запускается скрипт загрузки.
6. Иногда скрипт начинается с поиска подходящего образа ОС для загрузки на всех доступных носителях. В других случаях ЗН задается в скрипте жестко.
7. Скрипт загружает с ЗН в DDRAM образ ядра Linux (zImage), файл Device Tree с параметрами ядра (*.dtb).
8. Дополнительно скрипт может загрузить в DDRAM образ initrd – маленькой файловой системы с необходимыми для старта драйверами устройств. Современные дистрибутивы Linux иногда используют initrd, а иногда – нет.
9. Разместив загруженные 2 или 3 файла в памяти, скрипт передает управление на первую команду образа zImage (ядро Linux).
10. zImage состоит из распаковщика и сжатого образа ядра. Распаковщик развертывает ядро в памяти, и загрузка ОС начинается.

Запуск загрузчика – предзагрузчик

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

Любое ядро процессора ARM при сбросе начинает исполнение с адреса 0, где записан вектор “reset”. Старые серии процессоров буквально начинали загружаться с внешней памяти, отображенной по нулевому адресу, и тогда первая команда процессора была командной загрузчика. Однако для такой загрузки подходит только параллельная NOR Flash или ROM. Эти типы памяти работают очень просто – при подаче адреса они выдают данные. Характерный пример параллельной NOR Flash – микросхема BIOS в персональных компьютерах.

В современных системах используются другие виды памяти, потому что они дешевле, а объем больше. Это NAND, eMMC, SPI/QSPI Flash. Эти типы памяти уже не работают по принципу: подал адрес — читаешь данные, а значит, для прямого исполнения команд из них не подходят. Даже для простого чтения тут требуется написать драйвер, и мы имеем проблему «курицы и яйца»: драйвер нужно откуда-то заранее загрузить.

По этой причине в современные процессоры ARM интегрировано ПЗУ с предзагрузчиком. ПЗУ отображено в памяти процессора на адрес 0, и именно с него начинает исполнение команд процессор.

В задачи предзагрузчика входят следующие:

• определение конфигурации подключенных устройств;
• определение загрузочного носителя (ЗН);
• инициализация устройств и ЗН;
• чтение загрузчика с ЗН;
• передача управления загрузчику.

Конфигурация предзагрузчика обычно устанавливается одним из двух способов:

• схемотехнически, подключением определенных выводов процессора к земле или шине питания;
• записывается в однократно-программируемую память процессора на этапе производства.

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

Подобный предзагрузчик устанавливается как в процессорах ARM, таких, как Cortex-A, так и в микроконтроллерах, даже таких маленьких, как Cortex-M0. Вместе с предзагрузчиком процедура запуска ОС выглядит так:

Анализ угроз на этом этапе

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

В некоторых случаях предзагрузчик можно прочитать из ROM и проанализировать, но иногда доступ к нему ограничен. Например, предзагрузчик процессора серии Psoc4000 компании Cypress был закрыт несколькими слоями защиты (но был взломан талантливым хакером).

Использования предзагрузчика в большинстве сценариев избежать нельзя. Можно рассматривать его как вариант BIOS, которого в ARM-системах нет.

Сам по себе предзагрузчик в ROM несет в себе угрозу нарушения порядка загрузки и выполнения произвольного кода. Но после того как управление передано загрузчику ОС, предзагрузчик уже безвреден. Мы можем просто не передавать ему управление, перенастроить все обработчики прерываний и так далее.

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

Это в общем случае небезопасно, но встречается только в некоторых микроконтроллерах на архитектуре ARM. На таких микроконтроллерах обычно запускаются программы без ОС или малые RTOS, и дизайнер системы может оценить риски.

Загрузка с TrustZone

В процессоры ARM Cortex-A и Cortex-R встраивается технология TrustZone. Эта технология позволяет на аппаратном уровне выделить два режима исполнения: Secure (Безопасный) и Non-Secure (Гостевой).

Эти процессоры в основном нацелены на рынок смартфонов и планшетных компьютеров, и TrustZone используется для создания в режиме Secure доверенной “песочницы” для исполнения кода, связанного с криптографией, DRM, хранением пользовательских данных.

В режиме Secure при этом запускается специальная ОС, называемая в общем случае TEE (Trusted Execution Environment, доверенная среда исполнения), а нормальная ОС, такая, как Linux, Android, iOS, запускается в режиме Non-Secure. При этом права доступа к некоторым устройствам ограничены для нормальной ОС, поэтому ее еще называют гостевой ОС.

Из-за наложенных ограничений гостевая ОС вынуждена время от времени вызывать функции TEE для исполнения некоторых операций. TEE продолжает существовать параллельно с гостевой ОС все время, и гостевая ОС не может ничего с этим поделать.

Например, гостевая ОС использует функции TEE для:

• включения и выключения ядер процессора (в ARMv8-A это происходит через PSCI — часть ARM Trusted Firmware, а в ARMv7 — по-разному для каждого производителя процессоров);
• хранения ключей, данных банковских карт и т.п.;
• хранения ключей полнодискового шифрования;
• операций с криптографией;
• отображения DRM-контента.

При этом, с точки зрения безопасности, на время таких вызовов управление передается в неизвестный нам, непроверенный код. Мы не можем однозначно сказать, что делают Samsung KNOX или QSEE от Qualcomm.

Почему же разработчики систем соглашаются на такой режим функционирования? В процессоры с поддержкой TrustZone встроен и механизм Secure Boot в том или ином виде.

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

То есть загрузка ОС становится следующей:

1. стартует предзагрузчик в ROM. Он загружает ключи для проверки подписи TEE из ROM;
2. предзагрузчик загружает в память образ TEE, проверяет подпись. Если проверка прошла успешно, запускается TEE;
3. TEE настраивает режимы Secure и Non-Secure. Далее TEE загружает основной загрузчик ОС и переходит на него в режиме Non-Secure. Сам TEE остается в режиме Secure и ждет;
4. загрузчик основной ОС загружает ОС как обычно;
5. ОС вынуждена время от времени вызывать функции TEE для выполнения некоторых задач.

Однако производитель, как правило, поставляет подписанные образы загрузчика и TEE в составе SDK для процессора и поставляет процессоры, уже “зашитые” ключом производителя. В этом случае предзагрузчик из ROM не станет выполнять любой загрузчик, если он не подписан производителем. Все основные процессоры для смартфонов сейчас поставляются уже “прошитыми” под исполнение собственного TEE перед исполнением загрузчика ОС.

Далее действует лень — c TEE все работает, а без TEE даже не запускается. Разработчики используют SDK с TEE, вызывают закрытый бинарный код из ядра Linux и не волнуются.

Как проверить свой проект на обращения к TrustZone

Может даже показаться, что всей этой TrustZone не существует, по крайней мере, в вашей конкретной разработке. Проверить это совсем несложно.

Дело в том, что все процессоры с TrustZone стартуют в режиме Secure, а только потом переключаются в Normal. Если ваша ОС запущена в режиме Normal, то какая-то Secure OS (TEE) существует в системе и перевела ее в этот режим.

Лакмусовой бумажкой является обращение к TEE для включения кэш-памяти 2-го уровня. По какой-то причине архитектура ARM не позволяет этого делать из Normal World. Поэтому для включения кэша ядру ОС потребуется сделать хоть один вызов к TrustZone. Делается это единственной командой: smc #0, и вы можете поискать ее сами в ядре Linux или Android.

Разумеется, мы и сами поискали, и нашли такие вызовы в коде поддержки ряда процессоров Qualcomm, Samsung, Mediatek, Rockchip, Spreadtrum, HiSilicon, Broadcom, Cavium.

Загрузка ARM Cortex-A и анализ угроз

На схеме пунктиром обозначен путь обращения из ядра ОС в TEE.

В двух блоках — неизвестный нам код. Посмотрим, чем это грозит.

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

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

Гораздо более интересной точкой атаки является TEE, так как его функции вызываются в процессе работы ОС, когда все периферийные устройства работают, а коммуникационные протоколы настроены. Создание шпионской закладки в коде TEE позволяет практически неограниченно следить за пользователем СВТ.

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

• контролировать чтение и запись файлов, модифицировать данные «на лету»;
• перехватывать пользовательский ввод, причем введенные символы перехватываются даже с экранной клавиатуры;
• незаметно внедрять свои данные при коммуникации с удаленными серверами, в том числе по протоколу https, маскируя передачу шпионской информации под обычный зашифрованный Web-трафик.

Несомненно, выявленные возможности – только вершина айсберга, и создание закладок не было целью исследования.

Выводы

Мы рассмотрели процесс загрузки различных микроконтроллеров и процессоров ARM.

У микроконтроллеров наиболее уязвимым местом в процессе загрузки является загрузчик ОС.

Современные процессоры ARM Cortex-A включают в себя TrustZone — и от этого никуда не уйти. TrustZone предполагает запуск перед ОС доверенной среды исполнения TEE.

TEE является самой уязвимой точкой в процессе загрузки ОС на ARM Cortex-A, потому что обращения к TEE приводят к выполнению закрытого системного кода, известного производителю, но скрытого от нас.

Без контроля над TEE невозможно обеспечить безопасность и доверенность исполнения любой ОС на ARM Cortex-A.

Источник