ARMv7 — что это на Андроид?
Приветствую. Неважно какое устройство перед нами — смартфон или ПК, у всех них присутствует общие составляющие: процессор, оперативка, постоянная память (как жесткий диск у компьютера). Как у декстопных процессоров, так и у мобильных присутствует своя архитектура.
ARMv7 — что это такое?
Архитектура процессоров в портативных устройствах, например смартфоны, плееры, умные часы и даже роутеры. v7 это просто версия.
Например в телефоне Xperia Ray стоит проц SnapDragon с данной архитектурой, это же относится и к планшету Prestigio PMP558OC.
В данной версии, по сравнению с предыдущей — выше частота, поддержка нескольких физических ядер.
Данный тип процессоров мало кушает энергии и при этом обеспечивает хорошую производительность.
ARM используется во многих смартфонах. А в 2007 году около 98% из более чем миллиарда телефонов, которые продавались, были оснащены по крайней мере одним процессором ARM.
ARMv7 была создана компанией ARM Limited. А другие компании, например NVIDIA, LG, Samsung — покупают лицензию у ARM Limited на выпуск процессоров с такой архитектурой.
То есть ARMv7 — это не модель процессора, это именно его архитектура.
Стоит понимать, что приложения, которые выпущены под ARMv7 — не будут работать на устройствах, где стоит ARMv6. А вот наоборот — работать могут, но вот качество работы может быть разное.
Первым процессорным ядром семейства ARMv7 было именно Cortex-A8, которое использовалось в процах Apple A4 (iPhone 4 и iPad) и Samsung Hummingbird (Samsung Galaxy S и Galaxy Tab).
Флагманские чипы ARMv7 могут иметь частоту свыше 2 ГГц и 8 ядер, что очень неплохо для смартфона.
Все процессоры ARMv7 поддерживают набор инструкций Thumb-2, благодаря которым современные приложения могут работать быстрее.
Как узнать архитектуру процессора на Android?
Теперь о том, как узнать — что у вас вообще? ARMv7 или предыдущая версия? Итак, смотрите — это можно узнать например при помощи утилиты CPU-Z, она показывает много инфы, в том числе и архитектуру (Architecture):
Выше на картинке видим 4x ARM Cortex-A7 @ 1,21 GHz — означает что это проц 4 ядра с частотой 1.21 ГГц, а вот чтобы узнать подробнее про архитектуру, то гуглим инфу по ARM Cortex-A7 и узнаем что это ARMv7:
Тоже самое можно узнать и при помощи проги AnTuTu Benchmark:
Русские Блоги
Android arm64-v8a, armeabi-v7a, armeabi, x86 подробное объяснение
Недавно при упаковке с флаттером я столкнулся с ситуацией, когда упаковка не могла быть напечатана. Я долго проверял причину и обнаружил, что это было вызвано отсутствием конфигурации руки. После того, как она была экипирована, она разыгралась. Я воспользовался этой возможностью, чтобы изучить abi с нуля.
перед началом
Прежде чем начать, вам нужно знать lib, libs и т. Д.
1. lib и libs
Ссылки на те, что помещены в lib, включены в библиотеки.
Файлы, помещенные в библиотеки, будут автоматически включены редактором. Так что не ставьте API в библиотеках.
Содержимое библиотеки lib не будет упаковано в APK, содержимое библиотеки li будет упаковано в APK
Введение в архитектуру
Нет картины без правды: 
Существует только один неизвестный телефон с операционной системой Android 4.3, который использует архитектуру v7. 
Для 64-битных телефонов и 64-битных процессоров
Поскольку новый 64-разрядный процессор в настоящее время включает в себя две архитектуры, а технология процесса не была улучшена (28 нм), в то же время на мобильных телефонах и планшетах площадь чипа строго ограничена и не может быть чрезмерно увеличена, что приводит к среднему распределению 64-разрядных процессоров ARM. Количество транзисторов в каждой архитектуре резко сократилось, то есть из 32-разрядной архитектуры 64-разрядных процессоров для 32-разрядных процессоров с одинаковыми характеристиками они не только не улучшились, но и производительность снизилась в определенном масштабе. Однако производители процессоров должны объяснить потребителям, как лучше продвигать 64-разрядные системы, поэтому производители должны повысить производительность в других аспектах, чтобы компенсировать потери, вызванные сокращением числа транзисторов ЦП. Например: замените более мощный графический процессор, увеличьте пропускную способность памяти, многоядерный виртуальный одноядерный для повышения производительности одноядерного, совместные поставщики программного обеспечения для работы, чтобы изменить веса работы (повысить оценку GPU, снизить вес процессора) и т. Д. Таким образом, приобретая сильные стороны и избегая недостатков и, наконец, попадающих в руки потребителей, они работают с запущенным программным обеспечением, оно действительно улучшилось, пользователи довольны, карманы производителя также выпирают.
Таким образом, битовый процессор ARM64 более точно называется ARM32 + 64 в строгом смысле слова. По сравнению с битовым процессором ARM32, он имеет место для регресса и возможности для улучшения, но именно из-за регрессии, который стимулировал прогресс ARM Определено, что он внесет смелые и смелые изменения, и это должно быть улучшением. Но действительно ли ARM64 полезен для мобильных телефонов? Я могу только сказать, что это действительно бесполезно в данный момент, но это может произойти в будущем. (Собранный в другом месте) Таким образом, в строгом смысле ARM64-битный процессор более точно называется ARM32 + 64. По сравнению с ARM32-битным процессором он имеет некоторые недостатки и возможности для улучшения, но это из-за Эта регрессия подтолкнула ARM к решимости добиться прогресса, что позволило ему внести радикальные изменения, что, по-видимому, является улучшением. Но действительно ли ARM64 полезен для мобильных телефонов? Я могу только сказать, что это действительно бесполезно в данный момент, но это может произойти в будущем. (Искал в другом месте)
Однако Google официально объявил об обязательной 64-битной архитектуре в начале этого года.： 
Еще в январе этого года (2019 г.) Google выпустил уведомление о том, что с 1 августа этого года перечисленные приложения, помимо предоставления 32-разрядных версий, также должны предоставлять 64-разрядные версия.
Следовательно, больше невозможно принудительно использовать только архитектуру armeabi перед проектом.
Что конкретно означает поддержка 64-битной версии?
Если ваше приложение написано полностью на Java или Kotlin и не содержит никакой встроенной поддержки, то это означает, что приложение уже поддерживает 64-битную версию.
Однако в приложении используется любая встроенная поддержка (например, библиотека), поэтому вам необходимо обеспечить разные версии поддержки этих файлов и разных архитектур ЦП.
Следует отметить, что иногда в нашем собственном коде встроенная поддержка действительно не используется, но в нее включены некоторые сторонние библиотеки, используемые в приложении.
В настоящее время наиболее надежным способом является анализ файла APK, созданного окончательной упаковкой, для определения необходимости обеспечения поддержки 64-разрядной архитектуры.
Конфигурация упаковки
Трещина
Эта команда может быть заключена в соответствии с различными правилами, такими как abi, плотность экрана (например, ldpi, hdpi и т. д.)
Включить включено, а исключить не включено. Каждый элемент, включенный в конфигурацию, будет генерировать пакет apk.
Фильтр ndk
Эта инструкция может быть настроена для упаковки только той библиотеки, которую вы настраиваете, и она не будет упакована, если она не настроена, что очень гибко.
Эта конфигурация упакует библиотеку so из трех пакетов armeabi, armeabi-v71, arm64-v8a в apk, в отличие от split, которая будет воспроизводить apk для каждого пакета.
Определение типа архитектуры процессора Android-устройств
Часто при загрузке Андроид-приложений на сайтах предлагающих такую возможность, у пользователей есть возможность выбора файлов для различных архитектур системы. И тут возникают сложности — какую из загрузок нужно скачивать и устанавливать.
Архитектура процессора — это, простыми словами, схема по которой работают части процессора между собой, а также набор команд с помощью которых они «общаются» с другими частями устройства.
Многие разработчики делают универсальные приложения и игры, которые подходят под любые архитектуры процессоров. Но некоторые из них создают несколько версий программ специально «заточенных» под ту или иную архитектуру. При установке такого продукта из Google Play, сервис автоматически определяет все необходимые параметры установки и загружает на пользовательское устройство необходимые файлы. Пользователю не нужно думать над тем какой файл скачать.
Если же установка (по той или иной причине) из Google Play невозможна или нежелательна, пользователь может скачать файл APK на стороннем сайте. С его помощью можно установить приложение или игру «в ручном режиме». Вот тут-то, если на сайте есть несколько вариантов таких файлов, и появляются муки выбора.
На сегодняшний день, сайты предлагающие файлы для установки приложений и игр могут распространять APK-файлы следующих архитектур: armeabi-v7a, arm64-v8a, x86 и x86_64.
Ниже мы несколько более детально рассмотрим разные типы архитектуры для Android-устройств. Вы можете пропустить этот блок и перейти к следующему, но все-таки мы бы рекомендовали ознакомиться с этой информацией для более ясного понимания.
Файлы начинающиеся на «x86» и «arm» не являются взаимно совместимыми — вы должны использовать версию, предназначенную для конкретной архитектуры устройства.
Также, если ваш девайс имеет 32-разрядный процессор, 64-разрядный файл на нем работать не будет. А вот 64-разрядные процессоры обратно совместимы, поэтому на него можно устанавливать 32-разрядный файл.
Исходя из вышесказанного, можно составить такие правила совместимости:
В большинстве случаев телефоны используют архитектуру ARM. Более дешевые устройства используют версию armeabi-v7a, более мощные — версию arm64-v8a. Поэтому, если сомневаетесь в том, какую версию файла выбрать, выбирайте ту, которая имеет отметку «armeabi-v7a».
Определение архитектуры процессора устройства
Теперь, когда мы разобрались с теоретической частью, пора определить — на какой архитектуре разработан ваш телефон или планшет.
Для этого можно воспользоваться инструкцией к устройству (но в ней не всегда можно найти нужную информацию) или же найти данные в интернете. Но лучше всего это сделать с помощью специального приложения.
Самый простой способ!
Droid Hardware Info
Если вышеописанный способ вас чем-то не устраивает или же вы хотите получить более расширенные данные о системе вашего устройства, воспользуйтесь приложением Droid Hardware Info.
Установите эту утилиту в Google Play или с помощью APK-файла (скачав его на сайте Biblprog). Для получения нужной нам информации запустите Droid Hardware Info, перейдите на вкладку «Система» и обратите свое внимание на раздел «Процессор».
Как вам данная инструкция? Все ли понятно? Если у вас появились дополнительные вопросы или же возникли замечания к информации выложенной на данной странице — не стесняйтесь. Напишите в комментариях!
Конец эпохи ARMv7 или же немного о портировании игр
Вступление
Разбор apk
Итак, что такое .apk? APK файл представляет из себя немного модифицированный ZIP архив, который содержит ресурсы игры и игровой движок. Выглядит он примерно так:
Папка lib — ключевая точка при переносе между архитектурами. Она содержит библиотеки движка нашей игры.
* armeabi — armv6 библиотеки (не актуально)
* armeabi-v7a — armv7 библиотеки (при отсутствии папки — отсутствует и поддержка архитектуры)
* arm64-v8a — armv8 x64 библиотеки
Перенос
Шаг #1
Первым делом нам нужно узнать, возможно ли портировать игру. Для этого нужно определить движок игры. К примеру, файл lib/libunity.so — принадлежит Unity Engine, а по наличию папки assets/x-renpy можно догадаться, что игра разработана на RenPy Engine. Если у игры движок не является собственным, то переходим к шагу два.
Шаг #2
Шаг #3
Мы нашли подходящего донора, теперь нам нужно добавить папку lib/armeabi-v7a в наш (name).apk. Добавляем и видим следующее:
В самом начале, как я уже сказал, APK файл представляет из себя немного модифицированный ZIP архив, а после изменения его содержимого он становится обычным ZIP’ом.
Шаг #4
Для того, чтобы ваше устройство могло установить ваш (name).apk файл, его нужно «подписать». Для этого есть несколько различных утилит, к примеру apk-signer.
Шаг #5
Будь добрым человеком, выложи свой порт для общего пользования, к примеру, в топик игры на том же 4PDA. 😉
TrustZone: аппаратная реализация в ARMv7A
Сегодня начинаем исследовать внутреннее устройство TrustZone (это торговая марка компании ARM).
Само название — коммерческое, его придумали маркетологи, чтобы сообщить всему миру о ключевом свойстве этой технологии. По их задумке, мы должны представить какое-то доверенное, защищенное, очень надежное место. Например, дом, где мы, закрыв двери и включив свет, чувствуем себя уютно и в безопасности.
Поэтому я начну с того, что TrustZone — это никакое не «место» в процессоре. Ее нельзя найти на чипе, как кеш или АЛУ. И доверенные программы, на самом деле, не исполняются в какой-то физически выделенной зоне процессора.
Даже если мы посмотрели бы в исходные коды ядра ARM, то не смогли бы четко выделить TrustZone. Скорее, по аналогии с программами, TrustZone — это несколько модулей и набор патчей для почти всех остальных частей процессора.
В этой статье мы рассмотрим, как TrustZone реализуется на аппаратном уровне процессоров ARM Cortex-A (ARMv7A).
В ARMv8A будет примерно то же самое, а вот в ARMv7M все совсем по-другому. В угоду маркетингу, там тоже есть TrustZone, но другая.
Режим
Первый компонент TrustZone — это режим процессора. Он задается битом NS (Non-Secure) в регистре SCR (Secure Configuration Register). Если NS=1, мы в режиме Non-Secure, если NS=0, мы в доверенном, то есть Secure-режиме.
Регистр SCR у Cortex-A5
Независимо от NS, остаются на своих местах все привычные режимы работы процессора. Cамые ходовые из них:
Бит NS влияет на выполнение отдельных функций процессора, запрещает доступ к отдельным блокам и меняет поведение части регистров, как ядра процессора, так и периферийных устройств.
Более того, оказывается, что в нельзя взять и поменять значение бита NS ни в одном из обычных режимов работы процессора — это запрещено. Для смены значения NS предусмотрен церемониал с заходом процессора в отдельный режим Secure Monitor, который не принадлежит однозначно ни к Secure, ни к Non-Secure. Но об этом мы поговорим в следующей статье.
Получается, что NS раздваивает процессор, создает два неравноправных режима работы: Secure и Non-Secure. В каждом режиме, впрочем, есть все, что нужно для исполнения ОС и программ, просто привилегии по доступу к части функций CPU и периферии отличаются.
Режим, а не зона!
Продолжаем снимать завесы.
Доверенный режим исполнения программ — тот, где NS=0, все!
Нет никакого дополнительного конвейера команд, АЛУ, отдельной памяти программ, — ничего такого, что можно представить, услышав название TrustZone. Нет никакой границы этой зоны, команды нарушителей не стремятся «переползти» в доверенную зону, как вирусы сквозь клеточную мембрану.
В общем случае конвейер исполнял команды недоверенной программы (NS=1), а потом (бац!) произошло прерывание, процессор перешел в доверенный режим (NS=0) и тут же исполняет доверенный код.
На самом деле, технология TrustZone дает нам инструментарий, позволяющий предпринять ряд мер (разделить память доверенных и недоверенных программ, разделить доступ к периферии) для создания надежного барьера между Secure и Non-Secure. Но надежность этого барьера будет зависеть и от качества, и полноты реализации доверенного ПО.
Конец снятия завес.
Сигнал NS
Бит NS не просто указывает процессорному ядру, в каком режиме ему работать. Это еще и внешний сигнал, подключенный от процессора почти ко всей периферии.
Как это представить? В общем случае, мы представляем, что периферия к CPU подключена шинами адреса, данных и управления. NS входит в состав сигналов управления для тех процессоров, где TrustZone реализована. Таким образом, от CPU к устройству идут не просто команды Read, Write, а Secure Read, NonSecure Read, Secure Write, NonSecure Write.
Cortex-A чуть чаще, чем всегда поставляется как System On Chip (SoC), поэтому все эти шины скрыты от нас внутри чипа. Однако ряд SoC позволяют вывести сигнал NS наружу, на случай подключения внешней периферии, поддерживающей безопасный режим.
Какая периферия поддерживает Secure/NonSecure доступ? Например, это контроллер прерываний GIC — в ARM это периферийное устройство в составе SoC. В Secure-режиме он позволяет настроить доставку некоторых прерываний в режим Secure FIQ и запретить изменять эту настройку ПО из NonSecure-режима.
Вот что происходит при работе CPU с GIC: при записи регистра GIC в режиме Secure от CPU вместе с адресом регистра и данными идет сигнал NS=0. GIC понимает, что запись доверенная, и дает полный доступ. Если же NS=1, GIC ограничивает доступ к части регистров, как на запись, так и на чтение.
Другие блоки процессора, поддерживающие сигнал NS: контроллеры памяти, часы реального времени (RTC), хранилище ключей, контроллер сброса и управления питанием.
Заметим, что в ARMv7A поддержка TrustZone опциональна, и при создании SoC опция Secure Extensions (читаем: TrustZone) может быть отключена. При этом из чипа удаляются ненужные блоки и связи, в частности, отпадает необходимость в трассировке линии NS по всему чипу. При этом входы NS периферийных устройств подключаются к 0 (по крайней мере, мы можем так это представить). Топология чипа становится проще.
Многопроцессорность
Рассмотрим внутренности работы современного ARM, чтобы понять, как будет работать TrustZone в этом случае.
В процессорах ARM все процессорные ядра, память и периферию соединяет внутренняя шина, которая называется AMBA (https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture). Начиная примерно с ARMv4, в cоставе шины AMBA существует блок коммутации, он подключает блоки, называемые Bus Master, к различным Slave-устройствам.
Только реально крепкий орешек разберется в деталях работы AXI и AMBA, а ведь для полной картины нужно добавить AHB, APB и учесть детали реализации в разных архитектурах. Но общая идея улавливается очень быстро.
Например, процессорное ядро (а точнее, D-cache и I-cache этого процессора) — это Bus Master, а какой-нибудь I2C контроллер — это Slave. Bus Master начинает транзакцию по шине, то есть чтение или запись. Slave — это тот блок, куда пишут или откуда читают. Отсюда, кстати, следует и сам набор мастеров: ядра процессора, контроллеры DMA и периферия со встроенным DMA (как, например, USB host).
Блок коммутации Master Slave мы рассмотрим подробнее. В ARMv7A он называется Interconnect и является элементом реализации AXI (Advanced eXtensible Interface). В ARM926 этот блок имел говорящее название Bus Matrix и был частью реализации интерфейса внутренней шины AHB (Advanced High-Perfomance Bus). По сути — это то же самое.
У нас есть M×Master и N×Slave, и есть матрица коммутации, соединяющая первых со вторыми. В каждый момент времени каждый Master может быть подключен к одному Slave или отключен совсем. Но несколько Master могут быть одновременно активны, если подключены к разным устройствам.
В общем случае не все связи возможны. В частности, дизайнер системы может исключить ненужные связи — например, если нет причин для Ethernet-контроллера (Master), можно писать напрямую в I2C-контроллер (Slave).
Кроме того, некоторые устройства могут быть как Master, так и Slave. Например, USB Host, когда сохраняет данные через DMA в память — Master, а когда мы настраиваем его регистры— Slave.
При этом каждый Master является и источником сигнала NS, а Slave — реципиентом этого сигнала. AXI транслирует через Interconnect сигналы NS от Master к соответствующему Slave, и благодаря этому в SoC могут одновременно происходить как Secure-, так и NonSecure-транзакции.
Периферия
Теперь мы видим, как в ARM Cortex-A поддерживается одновременная работа на внутренней шине нескольких процессорных ядер и множества периферийных устройств, одновременно в режимах Secure и Non-Secure. Еще немного усложним?
При создании SoC разработчик берет блоки от ARM, блоки от сторонних производителей и блоки собственной разработки, соединяет их в единую систему.
От ARM берутся, в том числе
Например, контроллер кеша знает, какие линейки были сохранены в доверенном режиме, а какие — в недоверенном, и будет производить соответствующие транзакции по AXI для сброса данных в физическую память.
Далее, многие блоки процессора покупаются у сторонних (надежных и известных) разработчиков, они одни и те же даже в процессорах разных производителей. Это, например, USB host, SDHC host. Другие блоки разработчик SoC использует во всех своих процессорах, почти не меняя. Это, например, Ethernet MAC, контроллеры I2C, UART, SPI.
Вот эти покупные и свои блоки могут не иметь поддержки TrustZone совсем. Это объяснимо — мы не можем представить, зачем нужно разделять доступ к UART между Secure и Non-Secure. Но вопрос интеграции таких устройств в TrustZone повисает в воздухе.
Вопросы интеграции этих устройств решается производителем SoC самостоятельно. Фактически, производитель должен решить две задачи:
Доступ Bus Master без поддержки TrustZone
Посмотрим, что это значит для Bus Master на примере с видеоконтроллером, берущим данные из памяти и передающим их прямо в HDMI.
Мы хотим обеспечить пресловутый DRM: зашифрованный видеопоток будет поступать из Linux в Secure OS, там расшифровываться и отображаться на экране. Расшифрованные данные будут размещаться в области памяти, доступной только для Secure Read/Write, чтение этой области из Linux (Non-Secure) даст ошибку доступа. Таким образом, мы не дадим Linux скопировать расшифрованный поток. Видеоадаптер с правом Secure-доступа будет беспрепятственно читать расшифрованные видеоданные и отображать на экран.
Чтобы видеоадаптер мог через AXI получать данные из Secure-памяти, он должен осуществлять доступ с NS=0. Однако если DRM нам противен не нужен, предоставлять видеоконтроллеру привилегированный доступ мы можем и не захотеть.
Чтобы контроллер работал так и этак, в системе вводится настройка: тип доступа для каждого Bus Master, не поддерживающего TrustZone. То есть минимум 1 бит на каждый Bus Master. Возможно, это просто один регистр — но это работа для создателя SoC, его ответственность. И это, конечно, источник несовместимости между процессорами разных производителей.
Доступ Bus Slave без поддержки TrustZone
Для такого контроля доступа можно под каждый Bus Slave предусмотреть регистр с 2-4-8 битами, разрешающими или запрещающими доступ к устройству в зависимости от режима доступа.
И тут мы подошли к еще одной теме: а что будет, если Bus Master доступ начал, а Bus Slave его не разрешил?
Ошибка доступа
Если есть ограничение, то будет и нарушение. Если какой-то тип доступа к устройству запрещен, что-то должно произойти, если его осуществить.
На самом деле, не всегда. Например, в том же GIC (контроллер прерываний), запрещенные для Non-Secure операции записи не выполняются (тихо и спокойно), а операции чтения возвращают нули. Ничего не происходит, и это специально так задумано — позволяет запускать одну и ту же ОС (например, Linux) как в Secure-, так и в Non-Secure-режимах.
В Secure-режиме Linux будет настраивать все самостоятельно, в Non-Secure — контроллер будет преднастроен, и Linux сможет настроить только то, что ей осталось разрешено. Но она и глазом не моргнет, не заметит подвоха, потому что GIC никакой ошибки при записи в запрещенную область не выдаст.
А что если мы используем менее хитрые интеллектуальные устройства? Тогда, например, при Non-Secure записи в Secure область памяти произойдет Abort. Abort — это тип исключения ARM, возникающий при невозможности доступа к какому-то устройству или области памяти.
Чаще всего будет происходить Asynchronous Data Abort, или по-русски, асинхронный аборт. Не стоит обсуждать это за ланчем.
Data Abort — потому что он произошел при чтении/записи данных, а не инструкций процессора. Асинхронный он потому, что происходит не сразу в момент ошибки, а через некоторое время после нее. И вот с этого места будет еще подробнее.
Вообще, при нарушении доступа может произойти как синхронный, так и асинхронный аборт.
Например, когда Linux загружает приложение, он может загрузить его не целиком, разместив при этом только часть страниц в физической памяти, а остальные настроить на генерацию Abort в момент доступа. Приложение запустится, и когда дело дойдет до незагруженной в физическую память страницы, произойдет синхронный аборт. Он синхронный потому, что произойдет ровно на той инструкции, которая совершила обращение к памяти. Когда процессор попадет в режим Abort, Linux подгрузит нужную страницу памяти и вернет управление на ту же инструкцию, которая вызвала Abort. Результат — программа продолжит работать «как не бывало».
Но в случае с TrustZone все не так гладко. Некоторые процессоры будут генерировать синхронные исключения, но большинство — будут генерировать для большинства ошибок доступа асинхронный Abort.
Ответим себе на два вопроса:
Почему асинхронный?
Начнем с того, что ARMv7A — архитектура с конвейером команд, где инструкции заранее разбиваются процессором и выполняются не строго последовательно. Исполнение части инструкций может происходить параллельно с другими. Например:
Здесь первая команда сохраняет r1 по адресу r2, а вторая увеличивает r2. После исполнения первой команды, в общем случае, сохранение в память только начнется, и возможно, еще не закончится, когда будет выполнена полностью вторая инструкция.
Далее, у процессора есть cache, в котором записанная ячейка застрянет на неопределенное количество времени, и ошибка доступа потенциально произойдет только в момент синхронизации кеша с памятью.
Потом, даже если область памяти не кешируется: память в ARM делится на Normal, Strongly Ordered и Device Memory, допуская разные вольности со стороны процессора по изменению порядка реальных обращений к памяти и устройствам через AXI. В результате, транзакция через AXI может произойти не сразу из-за того, что доступ к устройству занят другим обращением.
Ну и наконец, если доступ к обычному Bus Slave вызвал Abort, то это будет внешний по отношению к процессорному ядру логический сигнал. Ядро никак не ожидает, что этот сигнал синхронизирован с тем, что происходит сейчас в конвейере команд, и это абсолютно справедливо: ядро даже не может на 100% определить причину такого аборта.
При любом из этих обстоятельств ARM сгенерирует Asynchronous Abort, сообщая нам, что попытка запрещенного доступа была, но, сколько тактов или инструкций назад — он не знает.
Чем плох Asynchronous Abort?
Да тем, что мы не можем определить точку сбоя и не можем ничего исправить. Программа после ошибочного доступа может выполняться не один десяток тактов и за это время удалиться настолько далеко от правильного функционирования, что ее останется только остановить и перезапустить. Возможно, и с полным сбросом процессора, если от работы программы после Abort пострадает какая-нибудь периферия или внутренние структуры ОС.
… и какой из этого можно сделать вывод
При работе с TrustZone поначалу возникает соблазн использовать эту технологию как технологию аппаратной виртуализации. Но из-за Asynchronous Abort это не получится сделать.
Действительно, есть два режима: Secure и Non-Secure. Режим Secure может создать для Non-Secure аналог песочницы, ограничить доступ к периферии.
Однако следующим шагом будет виртуализация части периферии, например, Flash-памяти, с которой работают и гостевая ОС, и гипервизор. И тут мы натыкаемся на то, что невозможно просто так взять и закрыть доступ к устройству для гостевой ОС.
Можно заставить гостевую ОС стучаться в Secure OS для доступа к запрещенным устройствам, и это основной способ разделения устройств между Secure OS и гостевой ОС. Но об этом мы поговорим в следующий раз.
А память-то, память?
А что обстоит с доступом к обычной памяти? Можно ли выделить для Secure-доступа часть системной DDRAM?
ARM позаботилась об этом меньше, чем можно ожидать!
Контроллеры памяти бывают разные, например,
Самый базовый вариант есть почти всегда — доступ к встроенной SRAM настраивается как Secure, а к DDR — как Non-Secure.
Это довольно безопасный способ, потому что все Secure-данные хранятся внутри чипа, не покидают его периметр. Но встроенная SRAM — это жалкие десятки или сотни килобайт, и этого может не хватить для полноценной Secure OS и защищаемых данных.
Более гибкий способ появляется, если производитель SoC по своему усмотрению реализовал контроллер DDR с поддержкой зонирования памяти по критерию NS=0/1. На самом деле, вариантов реализации может быть много, но это не меняет сути.
В целом, такая память предлагает минимум следующее:
По счастью, производители действительно включают в свои SoC подобные контроллеры.
Жаль только, что ARM не позаботилась об этом, и мы имеем самые разные решения.
У этой реализации есть минус: поскольку обычная память программ и данных в ARM кешируется, а контроллер памяти — обычный Bus Slave, мы можем далеко не сразу узнать, что произошла запись по запрещенному адресу. Произойдет асинхронный Abort, и нам останется только убирать обломки программы.
Заключение
В этой статье мы рассмотрели аппаратную реализацию TrustZone в ARMv7A и развеяли некоторые заблуждения, связанные с этой технологией.
