Пользователь
0,0
рейтинг
11 апреля 2013 в 01:36

Разработка → Основы безопасности операционной системы Android. Native user space, ч.1

Вступление


В этой статье я попробую рассмотреть безопасность чуть-чуть повыше ядра, а именно: как работает безопасность в Native user space. Мы коснемся темы процесса загрузки операционной системы и рассмотрим структуру файловой системы Android. Как я уже говорил, я не очень силен в Linux, поэтому если заметите неточности, то исправляйте — меня научите и статью улучшите. Так как эта тема довольно обширная, я решил разбить её на две части. В первой части мы рассмотрим процесс загрузки операционной системы и особенности файловой системы. Всем кому интересно, добро пожаловать!



Список статей

Здесь собраны ссылки на мои статьи из этой темы:
  1. Основы безопасности операционной системы Android. Уровень ядра
  2. Основы безопасности операционной системы Android. Native user space, ч.1
  3. Основы безопасности операционной системы Android. Native user space, ч.2
  4. Основы безопасности операционной системы Android. Безопасность на уровне Application Framework. Binder IPC



Что подразумевается под Native user space

Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel.



Файловая система Android


Для начала давайте рассмотрим структуру файловой системы Android. Хотя Android и базируется на Linux kernel, привычную нашему глазу структуру файловой системы мы здесь не увидим. Давайте запустим эмулятор и посмотрим, что у нас есть. Для этого выполним комманду:

adb shell ls -al

В моем терминале для эмулятора на Android 4.2 я вижу следующий результат:

drwxr-xr-x root     root              2013-04-10 08:13 acct
drwxrwx--- system   cache             2013-04-10 08:13 cache
dr-x------ root     root              2013-04-10 08:13 config
lrwxrwxrwx root     root              2013-04-10 08:13 d -> /sys/kernel/debug
drwxrwx--x system   system            2013-04-10 08:14 data
-rw-r--r-- root     root          116 1970-01-01 00:00 default.prop
drwxr-xr-x root     root              2013-04-10 08:13 dev
lrwxrwxrwx root     root              2013-04-10 08:13 etc -> /system/etc
-rwxr-x--- root     root       244536 1970-01-01 00:00 init
-rwxr-x--- root     root         2487 1970-01-01 00:00 init.goldfish.rc
-rwxr-x--- root     root        18247 1970-01-01 00:00 init.rc
-rwxr-x--- root     root         1795 1970-01-01 00:00 init.trace.rc
-rwxr-x--- root     root         3915 1970-01-01 00:00 init.usb.rc
drwxrwxr-x root     system            2013-04-10 08:13 mnt
dr-xr-xr-x root     root              2013-04-10 08:13 proc
drwx------ root     root              2012-11-15 05:31 root
drwxr-x--- root     root              1970-01-01 00:00 sbin
lrwxrwxrwx root     root              2013-04-10 08:13 sdcard -> /mnt/sdcard
d---r-x--- root     sdcard_r          2013-04-10 08:13 storage
drwxr-xr-x root     root              2013-04-10 08:13 sys
drwxr-xr-x root     root              2012-12-31 03:20 system
-rw-r--r-- root     root          272 1970-01-01 00:00 ueventd.goldfish.rc
-rw-r--r-- root     root         4024 1970-01-01 00:00 ueventd.rc
lrwxrwxrwx root     root              2013-04-10 08:13 vendor -> /system/vendor

Я отмечу здесь только главные директории и те, которые нам пригодятся в будущем. В Интернете можно найти описание и предназаначение других директорий. Можно заметить, что некоторые директории такие же, как и в Linux, например, /dev, /proc, /sys, /mnt, /etc И их предназначение в основном такое же, как и в Linux. Кстати, отметьте, что мы не видим /bin и /lib директорий. Где они скрылись, я расскажу чуть позже.

C другой стороны можно заметить директории, которых в Linux вообще нет. Среди них нас интересуют /data, /system, /cache, /init, /init.rc Давайте рассмотрим их назначение поподробнее.
/system Это главная директория, где хранятся неизменяемые компоненты Android системы. Если проводить аналогию, то эта папка похожа на папку C:\windows\, доступную только для чтения. Т.е. изменять данные в этой директории мы не можем. Как раз здесь можно найти директории /bin и /lib, где хранятся различные исполняемые файлы и shared libraries. Кроме того, здесь же лежат системные приложения, которые встроены в операционку и которые, по умолчанию, нельзя удалить. Содержимое этой директории формируется во время компиляции операционной системы.
/data Т.к. /system у нас доступна только для чтения, то должна быть директория где хранятся изменяемые данные. /data как раз ею и является. Например, в эту директорию в /data/app сохраняются apk файлы устанавливаемых приложений, а в /data/data хранятся их данные (эту директорию мы подробно рассматривали в прошлой статье).
/cache Это просто временное хранилище. Также в эту директорию сохраняются, а потом из неё запускаются системные обновления.

Чтобы понять, что такое /init файл и для чего нужны непонятные файлы с расширением *.rc, рассмотрим процесс загрузки системы.



Процесс загрузки Android





Давайте рассмотрим несколько шагов процесса загрузки операционной системы Android. Эта картинка взята из книги «Embedded Android», там же можно найти и более детальное описание. Хотя в целом я и понимаю процесс, но для меня это больше магия :)

CPU. Когда вы нажимаете на кнопку включения, на процессор вашего устройства начинает подаваться напряжение. Так как до этого момента процессор был выключен, и так как он не способен сохранять свое состояние без подачи напряжения, то сразу после старта он находится в некотором неинициализированном состоянии. В данном случае процессор считывает из своего специального регистра некоторый жестко зашитый адрес и начинает выполнять инструкции начиная с него. Чаще всего, этот адрес указывает на чип, в который зашит bootloader (загрузчик).
Bootloader. Bootloader инициализирует RAM и загружает в неё Linux kernel. Кроме того Bootloader создает RAMdisk.
Linux kernel. Ядро инициализирует различные подсистемы, встроенные драйвера и монтирует root filesystem (корневую файловую систему). После этого ядро может запускать первую программу.
На этом магия заканчивается и дальше всё становится более-менее понятно.



Init


Первой программой в случае Android является init. Исполняемый файл находится в корневой директории (/init). Именно эту программу стартует ядро после своей загрузки. Её исходники находятся в папке system/core/init/ Давайте в них слегка покопаемся. Нас интересует system/core/init/init.c:

...
int main(int argc, char **argv)
{
    ...
    /* clear the umask */
    umask(0);

        /* Get the basic filesystem setup we need put
         * together in the initramdisk on / and then we will
         * let the rc file figure out the rest.
         */
    mkdir("/dev", 0755);
    mkdir("/proc", 0755);
    mkdir("/sys", 0755);

    mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755");
    mkdir("/dev/pts", 0755);
    mkdir("/dev/socket", 0755);
    mount("devpts", "/dev/pts", "devpts", 0, NULL);
    mount("proc", "/proc", "proc", 0, NULL);
    mount("sysfs", "/sys", "sysfs", 0, NULL);
    ...
    init_parse_config_file("/init.rc");
    ...
}

Вначале мы создаем и монтируем некоторые необходимые для работы директории, а потом парсим файл /init.rc и выполняем то, что распарсили. Формат /init.rc файла очень хорошо описан в readme, там же можно найти и пример. Если кратко, то этот файл представляет собой набор actions (секций — именнованная последовательность комманд). Каждая последовательность команд срабатывает по определенному trigger (триггеру). Например, следующая последовательно — это action, в которой trigger — это fs, а последовательность команд — это набор mount команд:

on fs
    # mount mtd partitions
    # Mount /system rw first to give the filesystem a chance to save a checkpoint
    mount yaffs2 mtd@system /system
    mount yaffs2 mtd@system /system ro remount
    mount yaffs2 mtd@userdata /data nosuid nodev
    mount yaffs2 mtd@cache /cache nosuid nodev

Исходный файл /init.rc находится в system/core/rootdir/init.rc Давайте рассмотрим некоторые основные его части, хотя я вам очень советую просмотреть его полность. После этого многие вещи вам должны стать понятны. Итак, начинается наш файл следующими строками:

import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.trace.rc

Они означают, что кроме init.rc файла нужно также импортировать настройки из файлов init.usb.rc, init.trace.rc и из файла с непонятным именем init.${ro.hardware}.rc Впрочем, ${ro.hardware} — это просто переменная, значение которая определяет тип железа. В случае эмулятора, её значение, например, — goldfish. Далее определяются переменные окружения:

...
on init
    ...
    # setup the global environment
    export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
    export LD_LIBRARY_PATH /vendor/lib:/system/lib
    export ANDROID_BOOTLOGO 1
    export ANDROID_ROOT /system
    export ANDROID_ASSETS /system/app
    export ANDROID_DATA /data
    export ANDROID_STORAGE /storage
    export ASEC_MOUNTPOINT /mnt/asec
    export LOOP_MOUNTPOINT /mnt/obb
    export BOOTCLASSPATH /system/framework/core.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar
    ...

После этого происходит инициализация переменных, необходимых для работы устройства. Если вас заинтересует эта тема, то вы легко найдете информацию о той или иной комманде. Давайте подробно рассмотрим следующий блок (который я уже приводил в этой статье):

on fs
    # mount mtd partitions
    # Mount /system rw first to give the filesystem a chance to save a checkpoint
    mount yaffs2 mtd@system /system
    mount yaffs2 mtd@system /system ro remount
    mount yaffs2 mtd@userdata /data nosuid nodev
    mount yaffs2 mtd@cache /cache nosuid nodev

MTD — Memory Technology Devices. Если в общих чертах, то MTD — это специальный чип с энергонезависимой (т.е. данные на этом чипе сохраняются после перезагрузки или выключения) flash-памятью (типа NOR или NAND), на который сохраняются образы дисков. В этой статье более подробно рассказывается об этом типе устройств, а также об ограничениях. Специально для этих разновидностей flash-памяти были разработаны специальные файловые системы, например, YAFFS. Одно из самых важных ограничений этих типов памяти заключается в том, что для того чтобы записать данные в сектор, куда уже записаны какие-то данные, вам надо полностью сначала стереть весь сектор. Поэтому производители стали переходить на новый тип блочной flash-памяти (eMMC), на которые можно поставить обычную ext4 файловую систему и избавиться от указанного ограничения. Т.к. я показываю пример init.rc файла для эмулятора, где вся работа эмулируется, то в нем по умолчанию используется файловая система YAFFS2 (думаю, что это пережитки прошлого, т.к. YAFFS2 использовалась для всех устройств до Android 2.2). В реальном устройстве (это как раз один из примеров, когда необходимо использовать init.rc файл для определенного железа) эти комманды будут перезаписаны. Например, в случае устройства herring (Google Nexus S), в файле init.herring.rc эта секция выглядит следующим образом:

on fs
    mkdir /efs 0775 radio radio
    mount yaffs2 mtd@efs /efs noatime nosuid nodev
    chmod 770 /efs/bluetooth
    chmod 770 /efs/imei
    mount_all /fstab.herring
    ...

Где fstab.herring — это файл, содержимое которого выглядит следующим образом:

...
/dev/block/platform/s3c-sdhci.0/by-name/system          /system             ext4      ro                                                    wait
/dev/block/platform/s3c-sdhci.0/by-name/userdata        /data               ext4      noatime,nosuid,nodev,nomblk_io_submit,errors=panic    wait,encryptable=/efs/userdata_footer

Как вы могли заметить, /system, /data, /cache — это просто mounting points (точки монтирования файловой системы), которые указывают либо на MTD устройства (в случае эмулятора), либо на блочные устройства (в случае настоящего устройства), куда записаны соответствующие дисковые образы (system.img, userdata.img и cache.img). Я не уверен, но думаю, что внутри смартфона находится один единственный чип с flash-памятью, разделенный на partitions (тома), в каждый из которых записан соответствующий образ. Этот чип с flash-памятью — то, что мы знаем под именем Internal storage (внутренняя память), объем которой — один из основных параметров смартфона.

Следует заметить, что /system смонтирован read-only (только для чтения). Это означает, что содержимое данного раздела не изменяется в процессе работы устройства, а только когда вы, например, обновляете систему на вашем устройстве (используя системные обновления).

Продолжим рассматривать наш init.rc. По триггеру post-fs-data формируется базовая структура файловой системы /data раздела. Там, в общем всё понятно — набор mkdir, chown, chmod команд.

Далее init.rc запускает несколько демонов. Если вернуться к рисунку в начале статьи, то они перечислены в блоке Native daemons. На этом мы пока остановимся. Как вы могли заметить из рисунка, я не полностью рассмотрел процесс загрузки операционной системы. Некоторые непокрытые этапы я рассмотрю в следующих статья.



Заключение


В следующей части я расскажу, откуда берутся образы system.img, userdata.img и cache.img и рассмотрю безопасность на уровне Native user space. Как всегда приветствуются исправления, дополнения, а так же предложения, о чем написать. И хотя у меня уже есть некоторый план, о чем писать в следующих статья, я готов его подкорректировать.


Ссылки


  1. Working with MTD Devices
  2. «Embedded Android» by Karim Yaghmour
  3. «Android Security Underpinnings» by Marko Gargenta



Update
  • Комментарий от пользователя bmx666 про различные варианты размещения загузчика на MTD устройствах.
  • Комментарий от пользователя SamOwaR про инициализацию CPU на разных SoC
Юрий @zyrik
карма
40,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (29)

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      TARGET_DEVICE для Nexus S действительно crespo. Но нас интересует TARGET_BOOTLOADER_BOARD_NAME. Когда вы выполняете команду lunch full_crespo-eng, система определяет опции, которые надо использовать при компиляции для этой платформы (эти опции находятся в BoardConfig.mk). TARGET_BOOTLOADER_BOARD_NAME находится именно там. Хотя я не очень хорошо знаком с системой компиляции, так что мог что-то напутать.
  • +1
    Радует, что цикл статей не закончился на первой)

    Сам с недавних пор разрабатываю под Android, так что ваши статьи очень кстати. Спасибо.
    • +1
      Я постараюсь, чтобы он продолжался )

      Здесь пару дней назад один автор выбросил цикл статей по asp.net. И хотя я уже давно не интересуюсь этой темой поставил плюсы автору, где только смог, потому что теперь представляю, какую работу он проделал. Как раз там в комментариях был поднят вопрос, как надо делать — выбрасывать ли всё полностью и сразу или писать по чуть-чуть. Так вот мне кажется, что я бы не смог написать всё сразу — просто бы не хватило терпения и запала. А так, даже если и заброшу написание, уже очень много останется информации, которую найти очень сложно (именно поэтому я так часто употребляю «мне кажется», «я думаю» и т.д. — это просто мое представление, как работает система). Просто у меня на одну статью уходит где-то 6-8 часов и это без учета времени ночью и в дороге, когда я обдумываю структуру и различные интересные моменты, которые надо описать.

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

      P.S. А Вы разрабатываете под Андроид или копаетесь с самой операционной системе?
      • 0
        Первоначально просто разрабатывал приложения/игры под Android только на Java. В последнее время ndk стал изучать.
        Планирую в будущем и внутри самой ОС покопаться. Так что ваши статьи складываю в избранное и постепенно осмысливаю, так сказать, почву закладываю для будущих исследований)
  • +1
    Хорошая статья, как раз в тему того, что я сейчас пытаюсь провернуть с китайским планшетом. Не могли бы вы подсказать, что лучше посмотреть на тему начальной загрузки Android-устройств и модификации загрузчика? Суть в чем: есть девайс Gadmei E6 (построен на весьма распространенном чипе Allwinner), я хочу сделать, чтобы он мог грузиться только с microSD карты. Чип в нем устроен как вы описали — начинает загрузку с определенного адреса, потом тащит u-boot, который потом уже загружает систему. На данный момент мне не хватает какой-то структурированной информации о загрузчиках — в интернете все весьма разрозненно и максимум чего я добился — это то, что устройство подвисает на загрузке =)
    К Embedded Android я обязательно обращусь, а что еще можете посоветовать?
    • 0
      К сожалению, моя работа с загрузчиками ограничивается командой fastboot flashall -w :) Так что я не очень силен в этом деле. Но я бы Вам посоветовал взглянуть на вики проекта Linaro. Я думаю, Вы там как раз и обнаружите необходимую информацию. Плюс посмотрите в сторону платформ типа BeagleBoard.
  • +3
    Bootloader инициализирует RAM, а также в зависимости от навороченности bootloader'a можно считывать ядро с NFS, USB-накопителей, eMMC, SATA и т.д. К примеру обычный u-boot позволяет работать с файловой системой ext2 и fat.

    Кстати Андроид можно загрузить разными способами, на большенстве девайсов попадаются такие вариации:
    1. MTD разбит на две части: ядро Linux (uImage, zImage и т.п.) + rootfs, который монтируется в дальнейшем.
    2. MTD разбит на несколько частей: ядро Linux с поддержкой ramdisk (папка root на выходе при компиляции Андроид), которое монтирует в дальнейшем разделы system, cache, userdata. Можно также разбить MTD на две части: ядро (cmdline + ramdisk) + ubifs (разделы system, userdata, cache).
    3. Самый распространенный: в начале на MTD располагаются два boot-образа Android, которые включают в себя: ядро Linux, командную строку (не обязательно), ramdisk (не обязательно). Почти всегда это recovery и обычный boot. Далее на MTD могут быть специальные разделы, где храниться служебная информация, а за ними идут разделы system, cache, userdata.

    Bootloader обычно записывают на другой MTD накопитель, чтобы юзер не превратил аппарат в «кирпич».

    Некоторые производители устанавливают командную строку для загрузки ядра Linux в bootloader, другие включают его в само ядро, третьи в boot-образ Android.

    p.s. это пока всё, что мне удалось узнать про загрузку Андроид.
    • 0
      Спасибо, очень ценный комментарий! Добавил в Update к статье.
    • 0
      Можно ссылку на источник, если таковой имеется?
      • 0
        Каждый производитель делает как захочет, поэтому никаких более менее стандартов в плане загрузчика нет.
        Всё выше перечисленное из собственного опыта: либо ковыряние с различными девайсами, либо разработка собственных решений с нуля.
  • 0
    Спасибо. Очень интересно. Жду продолжения.
  • +2
    Хочу заметить, что большинство ARM процессоров в Android девайсах сами по себе в рабочее состояние не включаются. Поэтому при подаче питания сначала запускается видео-карта (в мобилках видеокарты обычно полноценные APU с заблокированным блоком этого самого APU), с определённого места читает свой собственный бутлоадер, который уже вводит CPU в работу, говорит ему откуда брать его родной бутлоадер и т.д. У nVidia даже есть тулза — nvflash, которая позволяет управлять всем этим процессом.
    • 0
      Я не знаком с такими низкоуровневыми технологиями. Вообще, про загрузку я написал для того, чтобы объяснить, как она происходит в моем понимании, а также показать основные её этапы. Они, в общем-то, необходимы для понимания архитектуры системы. Ну и если бы раньше кто-то что-то подобное написал на Хабре, то я бы ему был очень-очень благодарен, а так приходилось по крупицам собирать знания.

      Спасибо Вам за уточнение, пополнил свои знания ) Хотелось бы спросить, а такой процесс запуска характерен только для SOC на базе nVidia или для других SOC тоже? Может эти требования есть в спецификации архитектуры?
    • 0
      Поэтому при подаче питания сначала запускается видео-карта

      Что-то очень странное вы написали. Возможно трудности перевода? Процессор всегда инициализируется первым, выполняет свой BootROM, который загружает bootloader, который потом загружает ядро операционной системы. Видеокарта тут вторична. Её может инициализировать bootloader, а потом ядро. А часто видеокарты нет вообще, зачем она, например, в роутере?

      Вот тут описан процесс загрузки типичного ARM-процессора. Могу ещё на Freescale i.MX51 доки (выдержки) кинуть, одно время я с ними поковырялся прилично.
      • 0
        Попробуйте инициализировать Raspberry Pi без GPU (:
        • 0
          Raspberry Pi — это микрокомпьютер, а вы писали про ARM-микропроцессор. Это разный вещи.
          И кроме того, да — ничто не мешает инициализировать этот Пи без GPU. Именно так я и делал, когда устанавливал Android на плату с i.MX51. Система загружалась (при чёрном экране), а я через текстовый терминал на последовательном порту смотрел сообщения загрузчика, ядра и Android-а, и пересобирал, перепрошивал, опять смотрел, и так, пока не добился работоспособной (почти) системы.
          • +1
            Еще раз — большинство SOC на ARM в мобильниках инициализируются через GPU внутри. Это факт.
            • 0
              Ну тогда либо давайте ссылку на документацию, либо это не факт, а фейл.
              • +1
                www.raspberrypi.org/phpBB3/viewtopic.php?f=72&t=29944

                Ссылку про тегру и квалком сходу не найду. Бут лоченный на тегре ломают через гпу, ибо там код срабатывает до цпу и можно натворить дел.

                Тащемта гугл ит.
  • +3
    Aux, спасибо что зацепили, пришлось искать документацию, узнал очень много интересного. Это тема для отдельной статьи.
    Но вкратце, действительно можно говорить о том, что на некоторых SoC загрузкой управляет GPU (?!). Только это будет не совсем точно (технически).
    Для Raspberry Pi вот что получается. Есть основной процессор (CPU) ARM1176JZF-S, есть графический сопроцессор (GPU) VideoCore IV® Multimedia Co-Processor, внутри (на территории) которого есть маленький сопроцессор, который управляет начальной загрузкой и также обеспечивает многие системные функци. Тут процесс загрузки описывают так:
    At power-up, the CPU is offline, and a small RISC core on the GPU is responsible for booting the SoC, therefore most of the boot components are actually run on the GPU code, not the CPU.
    На картинке FIG. 1B видно, что внутри Video Processing Core (на который часто ссылаются, как на GPU), есть ещё один блочёк, который тоже называется GPU — собственно та часть, которая обрабатывает 3D-графику и имеет право так называться.
    Таким образом, на мой взгляд, корректным определением было бы такое: «Начальной загрузкой управляет сопроцессор, находящийся в VPU»

    У Qualcomm ещё интересней:
    There are two processors in the MSM 7x30, an ARM9 for the radio and an ARM11 auxiliary applications processor
    и далее
    The ARM9 running REX loads the eMMC «hboot» partition into memory at 0x8D00000 (virtual) and starts the ARM11 auxiliary applications processor executing at this location.
    Таким образом можно сказать, что начальной загрузкой управляет сопроцессор радиомодуля!

    С Tegra-ми инфы больше:
    A co-processor known as the AVP (Audio-Video Processor), or sometimes by its legacy name, COP. This processor implements the initial boot process. This processor need not be the same architecture nor implementation as the main CPU complex; on all current Tegra variants, it is an ARM7TDMI.
    и
    When Tegra is powered on, the AVP executes code from the boot ROM. The main CPU complex is not started.
    Т.е. тут загрузкой занимается сопроцессор, входящий в состав Аудио-Видео-Процессор-а.

    • 0
      Классно! Вы, действительно, провели отличное исследование! Я потом добавлю ссылку на Ваш комментарий в статью. Единственный вопрос, который меня беспокоит, зачем? Может это как-то связано с безопасностью, с залоченными бутлодерами?
      • +1
        зачем? Может это как-то связано с безопасностью, с залоченными бутлодерами?
        Мне тоже очень интересно. На забугорных форумах этот вопрос довольно активно обсуждается, выдвигаются разные версии. Например такая. Что это связано с безопасностью и защитой know-how технологий от чужих глаз. Дело в том, что спецификации ARM ядер доступны всем лицензиатам, а вот проприетарные видеоядра — это тайна за семью печатями, соответственно если производителю нужно что-то «спрятать», то это лучшее место, где это можно сделать. Косвенно эту теорию подтверждает тот факт, что на SoC-ах с открытым (лицензируемым) видеоядром (PowerVR, Manli) процесс загрузки отличается.

        А по поводу настоящей безопасности, то ARM (и некоторые лицензиаты — AMD, Samsung) активно продвигают технологию TrustZone, аппаратно поддерживаемую современными ARM-ядрами. Позволяет, в том числе, и обеспечить безопасную загрузку. Пока она не особо используется, но попытки есть — "Android app taps secure resources via ARM TrustZone" и Samsung Galaxy S3 may be the first smartphone with full ARM TrustZone support for enabling 100% security in everything online.
      • +1
        Почти во всех STB (set-top box) есть secure boot, содержащий RSA ключ. Применяется в основном для проверки подлинности загрузки образа системы/обновления, для работы с библиотеками расшифровки контента (телеканал, данные и т.п. содержащихся в транспортном потоке), иногда RSA ключ используется и в связке со смарт-картой.
  • +1
    Скорее всего вместо
    переформатировать всё устройство
    должно быть «стереть всю страницу». Т.к. по приведённой ссылке написано
    MTD device sectors must be erased before rewriting — which is why they are more commonly called erase-blocks.
    а в http://www.linux-mtd.infradead.org/doc/nand.html
    One major problem for using NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 1-3 writes, depending on the manufacturers specifications.
    • 0
      Спасибо, Вы правы! Поправил в статье.
  • 0
    Спасибо за статью. Как раз в данный момент занимаюсь портированием CyanogenMod 10.1 на новое устройство, возникла проблема с рамдиском-не монтируется системный раздел. Начал разбирать скрипты, в ходе разборки у меня возник впопрос: зависит ли порядок выполнения скриптов от порядка в котором они импортируются?

    То есть, на примере init.rc:

    import /init.usb.rc
    import /init.${ro.hardware}.rc
    import /init.trace.rc
    import /init.carrier.rc

    Сначала выполнится init.usb.rc, затем init.${ro.hardware}.rc и тд. или как?
    • 0
      Насколько я помню, в конец init.rc добавятся последовательно комманды из init.usb.rc, init.${ro.hardware}.rc, init.trace.rc, init.carrier.rc и т.д. Т.е. сначала выполняться комманды из init.rc, а потом последовательно комманды из всех импортируемых файлов.
      • 0
        Спасибо, да, все-таки видимо так оно и есть, судя по:

        import <filename> Parse an init config file, extending the current configuration.

        Я сначала как-то не догадался в readme поискать

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.