Arm cortex a53 linux

NEON на ARM Cortex-A53 (Raspberry Pi 3)

Глядя на то, какое сильное ускорение даёт сборка ПО с дополнительными процессорными инструкциями, я решил проверить NEON на ARM. Скомпилировал cpuminer на Raspberry Pi 3 — сначала без neon-а, а потом с ним.

Никуда не годится. Компилируем с поддержкой NEON: CFLAGS=»-O3 -mfpu=neon» ./configure

Upd: А ещё оно стало зависать при попытке запустить бинарник с Неоном. Может, у меня проц дефектный? А если вручную указать не 4 потока, а —threads 2 и 3, то появляется прирост относительно бинарника без неона (на двух — 2,49 против 1,91), и не зависает.

Пишите в комментариях ваши истории успеха/неуспеха, много ли конкретно у вас даёт прироста производительности этот самый NEON, можно ли сравнивать с SSE?

собирай с march=arm-v8a+crc mtune=cortex-a53 mfpu=crypto-neon-fp-armv

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

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

Как не компиляй твой арм такое тормозное говно

Твой софт — говно (с)
ARM — заебца, но юзерам нужны свистоперделки, а разработчикам гигабайты json’а и xml’ей на каждый чих.

Ну да, и вселенная с её законами не та))

Ещё надо сказать что neon хорош только на Cortex-a8 (даёт наиьольший прирост чем без). На A7 и A15 neon несколько подрезали. Под neon часто компилер генерит не слишком хороший код и наибольший прирост утдаётся получить написав на ассемблере. Но это сильно зависит от задачи. Но односзначно даже при просто компиляции, при включённой векторизации, если завекторизовалось нормально — будет быстрее. К сожалению с векторизацией в последних компиляторах как-то не очень, во времена gcc-3.x было повеселее. Ещё надо учитывать что многие инструкции neon требуют строгого выравнивания, и новый gcc (>= 4.x) если не может выровнять, кладёт болт. Если оптимизация важна, нужно вручную постараться через __attribute__. Там достаточно много тонкостей.

Типичный случай — если gcc не знает заранее, что аргументы функции выровнены, он не будет векторизовать код с этими аргументами, их нужно специально маркировать, и иногда сплясать с бубном. Раньше это всё само делалось компилятором, но видать пришел кто-то умный и сказал, что так низзя и надо заставить народ работать.

вот ты олень ленивый, скопипастил даже по ссылке не сходил, очепятка там, ищи сам.

If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=‘neon’), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.

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

Уверен, что не просто ПИЧОТ при полной нагрузке?

Уверен — бинарник без неона в те же самые 4 потока не вешает систему.

Припекание зависит от количества используемых транзисторов, которое на разных инструкциях отличается.

Интересно. Я думал что там в каждом вычислительном юните встроены все инструкции, а не где-то отдельно. Сейчас замерю на трёх потоках. Upd: с тремя потоками 66-69 градусов, с четырьмя ушло в ребут уже при 64.

Я уверен что проблема в процессоре, потому что при перегреве сначала был бы тротлинг (на RPi он есть). А тут — ребут в первые 5 секунд после запуска бинарника.

Векторизация перпендикулярна floating point, но да, и это тоже. Когда я этим активно занимался всё было гораздо проще — включаешь neon и векторизацию и получаешь ускорение в 5 раз на 1-ядерном Cortex-A8. Сейчас уже всё не так. Консерваторы, блин.

Источник

Установка 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 — устройстве не будет диковинкой! А нужно ли вам это сейчас — решать вам.

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

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

Источник

Загрузка ОС на 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.

Источник