{: data{*I" /lab/:ET{: default{ : lastI"M
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

Проверка подписи загружаемых модулей в Genode

Цель

Реализовать прототип модуля init с функцией контроля целостности загружаемых модулей используя механизм электронной цифровой подписи (ЭЦП). Ознакомится с процессом загрузки ОС, принципами формирования ЭЦП и интегрировать полученные инструменты в систему сборки.

1. Общая информация

Для начала разберемся, что представляет собой ЭЦП [1]:

Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. Использование электронной подписи позволяет осуществить:
- Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему.
- Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев.
- Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом.
- Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.

Для реализации ЭЦП наиболее часто используются асимметричные криптографические алгоритмы. Для подписи генерируются пара ключей: открытый и закрытый. Подпись и проверка выполняются в соответствие со следующей структурной схемой: By Acdx (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons"

Исходя из этого к ключам предъявляются следующие требования:

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

В качестве алгоритмов используемых для ЭЦП в России рекомендуется применять ГОСТ Р 34.10-2012 [2] и ГОСТ Р 34/11-2012 [3] в качестве хеш-функции. В данной лабораторной работе рекомендованными алгоритмами являются ECDSA и SHA256 в качестве хеш-функции. В репозитории sss13 добавлены сторонние открытые библиотеки, реализующие данные алгоритмы micro-ecc [4] и SHA2 [5]. Открытый GOST engine из OpenSSL не использован по причине не возможности динамической линковки процесса init.

В качестве платформы будем использовать Fiasco.OC (base-foc) для архитектуры x86_32. На самом деле мы не будем добавлять никакого платформо-специфичного кода, но формирование загрузочного образа в системе сборки является платформо-зависимым.

Рассмотрим загрузку образа, построенного на базе Genode+Fiasco.OC более подробно:

  1. Загружается загрузчик, в нашем случае GRUB, все модули, указанные в конфигурационном файле загрузчика, загружаются в соответствии со спецификацией Multiboot. Управление передается модулю bootstrap.
  2. bootstrap выполняет часть операций необходимых для старта ядра, такие как:
    • сканирование доступной памяти;
    • перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить);
    • и непосредственно запуск ядра.
  3. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task.
  4. Начинает выполняться модуль core (являющийся root task в Genode), который инициализирует сервисы Genode и запускает модуль init
  5. init последовательно загружает указанные в конфигурации модули (файл config) и запускает их выполнение.

Более подробно модуль init и создании процессов в Genode были рассмотрены в лекции “Genode Architecture”[6] прошлогодней летней школы и в статье “Configuring the init process of Genode”[7] в разделе документации на сайте Genode.

3. Порядок выполнения и рекомендации

  1. Для начала работы необходимо подготовить окружение:
    • форкнуть наш репозиторий на GitHub
    • переключиться на ветку sss13_lab
    • подготовить библиотеки:
      make prepare -C libport PKG=libc
      make prepare -C sss13

    В данном репозитории уже выполнена предварительная подготовка системы сборки и исходного кода. “Заготовка” утилиты для подписи с использованием рекомендованных библиотек находится в sss13/tools/signtools, там же находятся утилиты для добавления значения подписи в конфигурационный файл и генерации ключей.
    Оригинальный исходный код init находится в директориях os/src/init и os/include/init. Для данной работы заготовка исходного кода, скопирована в директории sss13/src/initsig и sss13/include/initsig. Этот исходный код будет использоваться в дальнейшем описании.

  2. Добавить расчет подписи для каждого исполняемого модуля и добавление полученного хеша в конфигурацию на этапе создания образа.
    Необходимо доработать утилиту для подписи sss13/tool/signtools/signfile.ccх[^8]. Эта утилита должна получать на входе имя файла с данными для подписи и имя файла с содержимым закрытыго ключа и выводить в stdout значение подписи в виде строки. Это значение при сборке, с помощью утилиты signfile.py будет вставлено в конфигурационный файл.
    Доступ к загруженным загрузчиком файлам для Genode осуществляется через ROM Session. Но для dataspace, относящегося к открытому файлу, невозможно получить реальный размер файла, размер dataspace всегда кратен размеру страницы памяти (4096 байт). Поэтому для получения хеша, размер файла должен быть дополнен нулями до размера кратного размеру страницы и затем вычислен хеш.
    Используя полученный хеш и закрытый ключ получить подпись. Подпись добавляется в конфигурационный файл на этапе сборки в виде <signature value="xxx">. Пример:
    <start name="timer">
    <resource name="RAM" quantum="20M" />
    <provides><service name="Timer" /></provides>
    <signature value="bc8d2e767f7da92b6216796eaff7ec3883597da0f751b5248baa1dae763a17bfc52b72280b3a74c49ba9c0e459adc3d72d0af58622a60440018d3f0713028650" />
    </start>

  3. Добавить проверку подписи в init
    Для начала рассмотрим исходный код модуля initsig более подробно. Модуль initsig (sss13/src/initsig/main.cc [9]) выполняет следующие действия:
    • инициализацию динамического линкера, если найден ld.lib.so (строки 154-157);
    • регистрацию сигнала, используемого для уведомления init-а об изменении конфигурации (строки 167-169);
    • определение роутинга сервисов (строки 178-186);
    • и создание потомков (строки 188-219), заканчивающееся параллельным стартом всех потомков;
    • оставшийся код отвечает за перезапуск потомков, в случае изменения конфигурации на лету.

    В данный код добавлена обработка исключения InitSig::Child::Signature_failed, которое должен генерировать класс InitSig::Child в случае каких-либо ошибок при проверке ЭЦП.
    За создание потомка отвечает класс InitSig::Child [10], который непосредственно создает процесс, именно в его конструктор стоит добавить проверку ЭЦП. Рассмотрим этот код и определим функционал, который необходимо реализовать:
    - получение значения сигнатуры из конфигурационного файла для данного модуля (строки 486-502);
    - конвертирование сигнатуры из строки в бинарный вид, пригодный для дальнейшего использование в проверке (необходимо реализовать, заготовка в строках 504-506);
    - получение указателя на данные модуля и его длину (необходимо реализовать, строки 508-510);
    - расчет хеша для данных загружаемого модуля (необходимо реализовать, строки 512-514);
    - проверка ЭЦП (необходимо реализовать, строки 522-523);
    - в случае успешной проверки ЭЦП производится создание нового модуля (строки 527-528).

    Открытый ключ в рамках этой лабораторной работы может быть просто вкомпилен в init (sss13/src/initsig/main.cc строка 19).

  4. Тестирование
    • подготовить сборочную директорию для платформы foc_x86_32 и перейти в нее;
    • подключить репозитории libport и sss13;
    • включить генерацию ЭЦП используя спек sign: echo 'SPECS += sign' >> etc/specs.conf;
    • собрать утилиты signtools: make -C ../sss13/tool/signtools
    • установить утилиты в директорию bin: PREFIX=`pwd`/bin make install -C ../sss13/tool/signtool
    • запустить скрипт lab.run: make run/lab;
    • убедиться что проверка подписей работает и подписи валидны;
    • изменить содержимое файла hackme, запустить руками и убедиться, что подпись не сходится:
      cd var/run/
      dhex lab/genode/hackme
      ../../../tool/create_iso iso ISO=lab
      qemu-system-i386 -no-kvm -m 64 -nographic -cdrom lab.iso
    • исправить подпись в конфигурации для измененного файла и проверить еще раз.
  5. Выводы
    Сделать выводы по работе, а именно, какие проблемы имеет эта реализация? Что нужно доработать, чтобы использовать такую реализацию в реальных применениях, какие еще могут быть варианты контроля целостности загружаемых модулей для Genode?

Ссылки

[1]: http://ru.wikipedia.org/wiki/Электронная_подпись
[2]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012)
[3]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012)
[4]: https://github.com/kmackay/micro-ecc
[5]: http://www.aarongifford.com/computers/sha.html
[6]: http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/
[7]: http://genode.org/documentation/developer-resources/init
[8]: тут будет ссылка на гитхаб
[9]: тут будет ссылка на гитхаб
[10]: тут будет ссылка на гитхаб

;T:rawI"pA##Проверка подписи загружаемых модулей в Genode## ###Цель### Реализовать прототип модуля init с функцией контроля целостности загружаемых модулей используя механизм электронной цифровой подписи (ЭЦП). Ознакомится с процессом загрузки ОС, принципами формирования ЭЦП и интегрировать полученные инструменты в систему сборки. ###1. Общая информация### Для начала разберемся, что представляет собой ЭЦП \[1\]: > Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. > Использование электронной подписи позволяет осуществить: > - Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему. > - Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев. > - Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом. > - Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д. Для реализации ЭЦП наиболее часто используются асимметричные криптографические алгоритмы. Для подписи генерируются пара ключей: открытый и закрытый. Подпись и проверка выполняются в соответствие со следующей структурной схемой: ![By Acdx (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons" ](http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/512px-Digital_Signature_diagram.svg.png) Исходя из этого к ключам предъявляются следующие требования: - закрытый ключ должен надежно храниться у производителя ПО. Именно им производится подпись модулей. - открытый ключ сохраняется в устройстве. Нет необходимости защищать этот ключ от чтения, но важно обеспечить не возможность перезаписи открытого ключа. В качестве алгоритмов используемых для ЭЦП в России рекомендуется применять ГОСТ Р 34.10-2012 \[2\] и ГОСТ Р 34/11-2012 \[3\] в качестве хеш-функции. В данной лабораторной работе рекомендованными алгоритмами являются ECDSA и SHA256 в качестве хеш-функции. В репозитории sss13 добавлены сторонние открытые библиотеки, реализующие данные алгоритмы micro-ecc \[4\] и SHA2 \[5\]. Открытый GOST engine из OpenSSL не использован по причине не возможности динамической линковки процесса init. В качестве платформы будем использовать Fiasco.OC (base-foc) для архитектуры x86_32. На самом деле мы не будем добавлять никакого платформо-специфичного кода, но формирование загрузочного образа в системе сборки является платформо-зависимым. Рассмотрим загрузку образа, построенного на базе Genode+Fiasco.OC более подробно: 1. Загружается загрузчик, в нашем случае GRUB, все модули, указанные в конфигурационном файле загрузчика, загружаются в соответствии со спецификацией Multiboot. Управление передается модулю bootstrap. 2. bootstrap выполняет часть операций необходимых для старта ядра, такие как: - сканирование доступной памяти; - перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить); - и непосредственно запуск ядра. 3. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task. 4. Начинает выполняться модуль core (являющийся root task в Genode), который инициализирует сервисы Genode и запускает модуль init 5. init последовательно загружает указанные в конфигурации модули (файл config) и запускает их выполнение. ![](http://genode.org/documentation/developer-resources/img/setup.png) Более подробно модуль init и создании процессов в Genode были рассмотрены в лекции "Genode Architecture"\[6\] прошлогодней летней школы и в статье "Configuring the init process of Genode"\[7\] в разделе документации на сайте Genode. ###3. Порядок выполнения и рекомендации### 1. Для начала работы необходимо подготовить окружение: * форкнуть наш репозиторий на GitHub * переключиться на ветку ``sss13_lab`` * подготовить библиотеки: ``make prepare -C libport PKG=libc`` ``make prepare -C sss13`` В данном репозитории уже выполнена предварительная подготовка системы сборки и исходного кода. "Заготовка" утилиты для подписи с использованием рекомендованных библиотек находится в sss13/tools/signtools, там же находятся утилиты для добавления значения подписи в конфигурационный файл и генерации ключей. Оригинальный исходный код init находится в директориях os/src/init и os/include/init. Для данной работы заготовка исходного кода, скопирована в директории sss13/src/initsig и sss13/include/initsig. Этот исходный код будет использоваться в дальнейшем описании. 2. Добавить расчет подписи для каждого исполняемого модуля и добавление полученного хеша в конфигурацию на этапе создания образа. Необходимо доработать утилиту для подписи sss13/tool/signtools/signfile.ccх[^8]. Эта утилита должна получать на входе имя файла с данными для подписи и имя файла с содержимым закрытыго ключа и выводить в stdout значение подписи в виде строки. Это значение при сборке, с помощью утилиты signfile.py будет вставлено в конфигурационный файл. Доступ к загруженным загрузчиком файлам для Genode осуществляется через ROM Session. Но для dataspace, относящегося к открытому файлу, невозможно получить реальный размер файла, размер dataspace всегда кратен размеру страницы памяти (4096 байт). Поэтому для получения хеша, размер файла должен быть дополнен нулями до размера кратного размеру страницы и затем вычислен хеш. Используя полученный хеш и закрытый ключ получить подпись. Подпись добавляется в конфигурационный файл на этапе сборки в виде ````. Пример: ```` `` `` `` `` `` `` ```` 3. Добавить проверку подписи в init Для начала рассмотрим исходный код модуля initsig более подробно. Модуль initsig (sss13/src/initsig/main.cc \[9\]) выполняет следующие действия: - инициализацию динамического линкера, если найден ld.lib.so (строки 154-157); - регистрацию сигнала, используемого для уведомления init-а об изменении конфигурации (строки 167-169); - определение роутинга сервисов (строки 178-186); - и создание потомков (строки 188-219), заканчивающееся параллельным стартом всех потомков; - оставшийся код отвечает за перезапуск потомков, в случае изменения конфигурации на лету. В данный код добавлена обработка исключения InitSig::Child::Signature_failed, которое должен генерировать класс InitSig::Child в случае каких-либо ошибок при проверке ЭЦП. За создание потомка отвечает класс InitSig::Child \[10\], который непосредственно создает процесс, именно в его конструктор стоит добавить проверку ЭЦП. Рассмотрим этот код и определим функционал, который необходимо реализовать: - получение значения сигнатуры из конфигурационного файла для данного модуля (строки 486-502); - конвертирование сигнатуры из строки в бинарный вид, пригодный для дальнейшего использование в проверке (**необходимо реализовать**, заготовка в строках 504-506); - получение указателя на данные модуля и его длину (**необходимо реализовать**, строки 508-510); - расчет хеша для данных загружаемого модуля (**необходимо реализовать**, строки 512-514); - проверка ЭЦП (**необходимо реализовать**, строки 522-523); - в случае успешной проверки ЭЦП производится создание нового модуля (строки 527-528). Открытый ключ в рамках этой лабораторной работы может быть просто вкомпилен в init (sss13/src/initsig/main.cc строка 19). 4. Тестирование - подготовить сборочную директорию для платформы foc_x86_32 и перейти в нее; - подключить репозитории libport и sss13; - включить генерацию ЭЦП используя спек sign: ``echo 'SPECS += sign' >> etc/specs.conf``; - собрать утилиты signtools: ``make -C ../sss13/tool/signtools`` - установить утилиты в директорию bin: ``PREFIX=`pwd`/bin make install -C ../sss13/tool/signtool`` - запустить скрипт lab.run: ``make run/lab``; - убедиться что проверка подписей работает и подписи валидны; - изменить содержимое файла hackme, запустить руками и убедиться, что подпись не сходится: ``cd var/run/`` ``dhex lab/genode/hackme`` ``../../../tool/create_iso iso ISO=lab`` ``qemu-system-i386 -no-kvm -m 64 -nographic -cdrom lab.iso`` - исправить подпись в конфигурации для измененного файла и проверить еще раз. 5. Выводы Сделать выводы по работе, а именно, какие проблемы имеет эта реализация? Что нужно доработать, чтобы использовать такую реализацию в реальных применениях, какие еще могут быть варианты контроля целостности загружаемых модулей для Genode? ### Ссылки ### \[1\]: [http://ru.wikipedia.org/wiki/Электронная_подпись](http://ru.wikipedia.org/wiki/Электронная_подпись) \[2\]: [http://ru.wikipedia.org/wiki/ГОСТ_Р_34.10-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р_34.10-2012) \[3\]: [http://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-2012) \[4\]: [https://github.com/kmackay/micro-ecc](https://github.com/kmackay/micro-ecc) \[5\]: [http://www.aarongifford.com/computers/sha.html](http://www.aarongifford.com/computers/sha.html) \[6\]: [http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/](http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/) \[7\]: [http://genode.org/documentation/developer-resources/init](http://genode.org/documentation/developer-resources/init) \[8\]: тут будет ссылка на гитхаб \[9\]: тут будет ссылка на гитхаб \[10\]: тут будет ссылка на гитхаб ;T:preI"%E

Проверка подписи загружаемых модулей в Genode

Цель

Реализовать прототип модуля init с функцией контроля целостности загружаемых модулей используя механизм электронной цифровой подписи (ЭЦП). Ознакомится с процессом загрузки ОС, принципами формирования ЭЦП и интегрировать полученные инструменты в систему сборки.

1. Общая информация

Для начала разберемся, что представляет собой ЭЦП [1]:

Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. Использование электронной подписи позволяет осуществить:
- Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему.
- Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев.
- Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом.
- Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.

Для реализации ЭЦП наиболее часто используются асимметричные криптографические алгоритмы. Для подписи генерируются пара ключей: открытый и закрытый. Подпись и проверка выполняются в соответствие со следующей структурной схемой: By Acdx (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons"

Исходя из этого к ключам предъявляются следующие требования:

В качестве алгоритмов используемых для ЭЦП в России рекомендуется применять ГОСТ Р 34.10-2012 [2] и ГОСТ Р 34/11-2012 [3] в качестве хеш-функции. В данной лабораторной работе рекомендованными алгоритмами являются ECDSA и SHA256 в качестве хеш-функции. В репозитории sss13 добавлены сторонние открытые библиотеки, реализующие данные алгоритмы micro-ecc [4] и SHA2 [5]. Открытый GOST engine из OpenSSL не использован по причине не возможности динамической линковки процесса init.

В качестве платформы будем использовать Fiasco.OC (base-foc) для архитектуры x86_32. На самом деле мы не будем добавлять никакого платформо-специфичного кода, но формирование загрузочного образа в системе сборки является платформо-зависимым.

Рассмотрим загрузку образа, построенного на базе Genode+Fiasco.OC более подробно:

  1. Загружается загрузчик, в нашем случае GRUB, все модули, указанные в конфигурационном файле загрузчика, загружаются в соответствии со спецификацией Multiboot. Управление передается модулю bootstrap.
  2. bootstrap выполняет часть операций необходимых для старта ядра, такие как:
    • сканирование доступной памяти;
    • перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить);
    • и непосредственно запуск ядра.
  3. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task.
  4. Начинает выполняться модуль core (являющийся root task в Genode), который инициализирует сервисы Genode и запускает модуль init
  5. init последовательно загружает указанные в конфигурации модули (файл config) и запускает их выполнение.

Более подробно модуль init и создании процессов в Genode были рассмотрены в лекции “Genode Architecture”[6] прошлогодней летней школы и в статье “Configuring the init process of Genode”[7] в разделе документации на сайте Genode.

3. Порядок выполнения и рекомендации

  1. Для начала работы необходимо подготовить окружение:
    • форкнуть наш репозиторий на GitHub
    • переключиться на ветку sss13_lab
    • подготовить библиотеки:
      make prepare -C libport PKG=libc
      make prepare -C sss13

    В данном репозитории уже выполнена предварительная подготовка системы сборки и исходного кода. “Заготовка” утилиты для подписи с использованием рекомендованных библиотек находится в sss13/tools/signtools, там же находятся утилиты для добавления значения подписи в конфигурационный файл и генерации ключей.
    Оригинальный исходный код init находится в директориях os/src/init и os/include/init. Для данной работы заготовка исходного кода, скопирована в директории sss13/src/initsig и sss13/include/initsig. Этот исходный код будет использоваться в дальнейшем описании.

  2. Добавить расчет подписи для каждого исполняемого модуля и добавление полученного хеша в конфигурацию на этапе создания образа.
    Необходимо доработать утилиту для подписи sss13/tool/signtools/signfile.ccх[^8]. Эта утилита должна получать на входе имя файла с данными для подписи и имя файла с содержимым закрытыго ключа и выводить в stdout значение подписи в виде строки. Это значение при сборке, с помощью утилиты signfile.py будет вставлено в конфигурационный файл.
    Доступ к загруженным загрузчиком файлам для Genode осуществляется через ROM Session. Но для dataspace, относящегося к открытому файлу, невозможно получить реальный размер файла, размер dataspace всегда кратен размеру страницы памяти (4096 байт). Поэтому для получения хеша, размер файла должен быть дополнен нулями до размера кратного размеру страницы и затем вычислен хеш.
    Используя полученный хеш и закрытый ключ получить подпись. Подпись добавляется в конфигурационный файл на этапе сборки в виде <signature value="xxx">. Пример:
    <start name="timer">
    <resource name="RAM" quantum="20M" />
    <provides><service name="Timer" /></provides>
    <signature value="bc8d2e767f7da92b6216796eaff7ec3883597da0f751b5248baa1dae763a17bfc52b72280b3a74c49ba9c0e459adc3d72d0af58622a60440018d3f0713028650" />
    </start>

  3. Добавить проверку подписи в init
    Для начала рассмотрим исходный код модуля initsig более подробно. Модуль initsig (sss13/src/initsig/main.cc [9]) выполняет следующие действия:
    • инициализацию динамического линкера, если найден ld.lib.so (строки 154-157);
    • регистрацию сигнала, используемого для уведомления init-а об изменении конфигурации (строки 167-169);
    • определение роутинга сервисов (строки 178-186);
    • и создание потомков (строки 188-219), заканчивающееся параллельным стартом всех потомков;
    • оставшийся код отвечает за перезапуск потомков, в случае изменения конфигурации на лету.

    В данный код добавлена обработка исключения InitSig::Child::Signature_failed, которое должен генерировать класс InitSig::Child в случае каких-либо ошибок при проверке ЭЦП.
    За создание потомка отвечает класс InitSig::Child [10], который непосредственно создает процесс, именно в его конструктор стоит добавить проверку ЭЦП. Рассмотрим этот код и определим функционал, который необходимо реализовать:
    - получение значения сигнатуры из конфигурационного файла для данного модуля (строки 486-502);
    - конвертирование сигнатуры из строки в бинарный вид, пригодный для дальнейшего использование в проверке (необходимо реализовать, заготовка в строках 504-506);
    - получение указателя на данные модуля и его длину (необходимо реализовать, строки 508-510);
    - расчет хеша для данных загружаемого модуля (необходимо реализовать, строки 512-514);
    - проверка ЭЦП (необходимо реализовать, строки 522-523);
    - в случае успешной проверки ЭЦП производится создание нового модуля (строки 527-528).

    Открытый ключ в рамках этой лабораторной работы может быть просто вкомпилен в init (sss13/src/initsig/main.cc строка 19).

  4. Тестирование
    • подготовить сборочную директорию для платформы foc_x86_32 и перейти в нее;
    • подключить репозитории libport и sss13;
    • включить генерацию ЭЦП используя спек sign: echo 'SPECS += sign' >> etc/specs.conf;
    • собрать утилиты signtools: make -C ../sss13/tool/signtools
    • установить утилиты в директорию bin: PREFIX=`pwd`/bin make install -C ../sss13/tool/signtool
    • запустить скрипт lab.run: make run/lab;
    • убедиться что проверка подписей работает и подписи валидны;
    • изменить содержимое файла hackme, запустить руками и убедиться, что подпись не сходится:
      cd var/run/
      dhex lab/genode/hackme
      ../../../tool/create_iso iso ISO=lab
      qemu-system-i386 -no-kvm -m 64 -nographic -cdrom lab.iso
    • исправить подпись в конфигурации для измененного файла и проверить еще раз.
  5. Выводы
    Сделать выводы по работе, а именно, какие проблемы имеет эта реализация? Что нужно доработать, чтобы использовать такую реализацию в реальных применениях, какие еще могут быть варианты контроля целостности загружаемых модулей для Genode?

Ссылки

[1]: http://ru.wikipedia.org/wiki/Электронная_подпись
[2]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012)
[3]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012)
[4]: https://github.com/kmackay/micro-ecc
[5]: http://www.aarongifford.com/computers/sha.html
[6]: http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/
[7]: http://genode.org/documentation/developer-resources/init
[8]: тут будет ссылка на гитхаб
[9]: тут будет ссылка на гитхаб
[10]: тут будет ссылка на гитхаб

;T: post@ I"/use-cases/;T{;{ ;I"R Use cases

Here will be stored article about usage uKernel projects in real life.

L4Linux based Gateway

;T; I"nHere will be stored article about usage uKernel projects in real life. [L4Linux based Gateway](gateway/);T; I"

Here will be stored article about usage uKernel projects in real life.

L4Linux based Gateway

;T; @I"/css/skin/;T{;{;I"p/* Skin "iSimple" by Renat Rafikov */ body { background:#f2f2f2; font-family:arial, sans-serif; } a { color:#0085c5; } a:hover { text-decoration:none; } a:visited { color:#4a00c5; } ul li, ol li { padding:0 0 0.4em 0; } .container { max-width:1300px; margin:0 auto; } .header { margin:1px 0 0.5em 0; padding:1.5em 3% 0 3%; } .logo { float:left; display:inline-block; font-size:18px; text-shadow:1px 1px 1px #ffffff; } .menu_main { width:50%; float:right; text-align:right; margin:0.3em 0 0 0; font-size:12px; } .menu_main a, .menu_main a:hover { color:#0085c5; } .menu_main li { display:inline-block; margin:0 0 0 4px; } .menu_main li.active, .menu_main li.active a { color:#000; text-decoration:none; cursor:default; } .info { padding:0 1% 1em 1%; } .hero { background:#fff; border:1px solid #fff; -webkit-border-radius:5px; -moz-border-radius:5px; border-radius:5px; -webkit-box-shadow:#8b8b8b 0px 0px 5px inset; -moz-box-shadow:#8b8b8b 0px 0px 5px inset; box-shadow:#8b8b8b 0px 0px 5px inset; padding:15px 0 15px 2%; margin:0 0 15px 0; } .hero h1 { font-size:24px; font-size:18px; color:#3d3d3d; } .article { background:#fff; border:1px solid #cbcbcb; -webkit-border-radius:5px; -moz-border-radius:5px; border-radius:5px; -webkit-box-shadow:#8b8b8b 0px 0px 3px; -moz-box-shadow:#8b8b8b 0px 0px 3px; box-shadow:#8b8b8b 0px 0px 3px; padding:15px 0 15px 2%; } .footer { padding:1em 3% 3em 3%; color:#717171; font-size:12px; } .copyright { width:49%; float:left; text-shadow:1px 1px 1px #ffffff; } .menu_bottom { width:50%; float:right; text-align:right; margin:0; padding:0; font-size:12px; } .menu_bottom a, .menu_bottom a:hover { color:#0085c5; } .menu_bottom li { display:inline-block; margin:0 0 0 4px; } .menu_bottom li.active, .menu_bottom li.active a { color:#666; text-decoration:none; cursor:default; } h1 { font-size:22px; } h1, h2, h3, h4 { font-weight:normal; } h5, h6 { font-weight:bold; } .form label { display:inline-block; padding:0 0 4px 0; } a.button, .button { border:0; text-align:center; text-decoration:none; -webkit-border-radius:4px; -moz-border-radius:4px; border-radius:4px; -webkit-box-shadow:#999 0px 0px 1px; -moz-box-shadow:#999 0px 0px 1px; box-shadow:#999 0px 0px 1px; background:#4aa6d6; background:-webkit-gradient(linear, 0 0, 0 bottom, from(#1f7daa), to(#4aa6d6)); background:-webkit-linear-gradient(#1f7daa, #4aa6d6); background:-moz-linear-gradient(#1f7daa, #4aa6d6); background:-ms-linear-gradient(#1f7daa, #4aa6d6); background:-o-linear-gradient(#1f7daa, #4aa6d6); background:linear-gradient(#1f7daa, #4aa6d6); color:#fff; padding:10px 20px; font-family:verdana, sans-serif; text-shadow:1px 1px 1px #12455d; display:inline-block; } a.button:hover, .button:hover { color:#fff; background:-webkit-gradient(linear, 0 0, 0 bottom, from(#4aa6d6), to(#1f7daa)); background:-webkit-linear-gradient(#4aa6d6, #1f7daa); background:-moz-linear-gradient(#4aa6d6, #1f7daa); background:-ms-linear-gradient(#4aa6d6, #1f7daa); background:-o-linear-gradient(#4aa6d6, #1f7daa); background:linear-gradient(#4aa6d6, #1f7daa); } a.button:active, .button:active { color:#093950; text-shadow:1px 1px 1px #7ac8f0; -webkit-box-shadow:#093950 0px 2px 3px inset; -moz-box-shadow:#093950 0px 2px 3px inset; box-shadow:#093950 0px 2px 3px inset; } .table { width:100%; } .table th { padding:5px 7px; font-weight:bold; text-align:left; font-size:0.9em; border-bottom:1px solid #ddd; } .table td { padding:9px 7px; border-left:1px solid #ddd; } .table tr td:first-child {border-left:0;} .table tr { border-bottom:1px solid #fbfbfb; } .table tr:nth-child(even) { background:#F2F2F2; } .table tr:last-child { border:0; } .warning { border:1px solid #ec252e; background:#ec252e; color:#fff; padding:8px 14px; background:-webkit-gradient(linear, 0 0, 0 bottom, from(#ec252e), to(#F05057)); background:-webkit-linear-gradient(#ec252e, #F05057); background:-moz-linear-gradient(#ec252e, #F05057); background:-ms-linear-gradient(#ec252e, #F05057); background:-o-linear-gradient(#ec252e, #F05057); background:linear-gradient(#ec252e, #F05057); -webkit-border-radius:8px; -moz-border-radius:8px; border-radius:8px; } .success { border:1px solid #6e9e30; color:#fff; background:#0bbe2e; padding:8px 14px; background:-webkit-gradient(linear, 0 0, 0 bottom, from(#6e9e30), to(#87c03b)); background:-webkit-linear-gradient(#6e9e30, #87c03b); background:-moz-linear-gradient(#6e9e30, #87c03b); background:-ms-linear-gradient(#6e9e30, #87c03b); background:-o-linear-gradient(#6e9e30, #87c03b); background:linear-gradient(#6e9e30, #87c03b); -webkit-border-radius:8px; -moz-border-radius:8px; border-radius:8px; } .message { border:1px solid #2180ff; color:#1f49bf; background:#bcd9ff; padding:8px 14px; -webkit-border-radius:8px; -moz-border-radius:8px; border-radius:8px; } @media only screen and (max-width:480px) { /* Smartphone custom styles */ } @media only screen and (max-width:768px) { /* Tablet custom styles */ };T; @; @I"/css/style/;T{;{;I"/ /* "Simpliste" template. Renat Rafikov. http://cssr.ru/simpliste/ */ @import url('reset.css'); @import url('skin.css'); /* Columns ------- .col_33 | .col_33 | .col_33 .clearfix ------- .col_75 | .col_25 .clearfix ------- .col_66 | .col_33 .clearfix ------- .col_50 | .col_50 .clearfix ------- .col_100 ------- */ .col_25 { width:23%; margin:0 2% 0 0; float:left; } .col_33 { width:31%; margin:0 2% 0 0; float:left; } .col_50 { width:48%; margin:0 2% 0 0; float:left; } .col_66 { width:64%; margin:0 2% 0 0; float:left; } .col_75 { width:73%; margin:0 2% 0 0; float:left; } .col_100 { width:98%; margin:0 2% 0 0; } .col_25.wrap { width:25%; margin:0;} .col_33.wrap { width:33%; margin:0;} .col_50.wrap { width:50%; margin:0;} .col_66.wrap { width:66%; margin:0;} .col_75.wrap { width:75%; margin:0;} .col_100.wrap { width:100%; margin:0;} /* End columns */ /* Helper classes */ .center {text-align:center;} .left {text-align:left;} .right {text-align:right;} .img_floatleft {float:left; margin:0 10px 5px 0;} .img_floatright {float:right; margin:0 0 5px 10px;} .img {max-width:100%;} /* End helper classes */ a.button { color:auto; } @media only screen and (max-width:480px) { /* Smartphone */ .header { margin-bottom:0; } .logo{ display:block; float:none; text-align:center; } .menu_main { width:100%; text-align:center; float:none; padding:0; margin:1em 0 0 0; } .menu_main a { display:inline-block; padding:7px; } .copyright { width:100%; float:none; text-align:center; } .footer { padding-bottom:0; } .menu_bottom { width:100%; float:none; text-align:center; margin:1em 0 0 0; padding:0; } .menu_bottom a { display:inline-block; padding:6px; } .form textarea { width:100%; } .form label { padding:10px 0 8px 0; } } @media only screen and (max-width:768px) { /* Tablet */ .col_25, .col_33, .col_66, .col_50 , .col_75 { width:98%; float:none; } .form label { padding:10px 0 8px 0; } } @media print { /* Printer */ * { background:transparent !important; color:black !important; text-shadow:none !important; filter:none !important; -ms-filter:none !important; } a, a:visited { color:#444 !important; text-decoration:underline; } a[href]:after { content:" (" attr(href) ")"; } abbr[title]:after { content:" (" attr(title) ")"; } pre, blockquote { border:1px solid #999; page-break-inside:avoid; } thead { display:table-header-group; } tr, img { page-break-inside:avoid; } img { max-width:100% !important; } @page { margin:0.5cm; } p, h2, h3 { orphans:3; widows:3; } h2, h3{ page-break-after:avoid; } .header, .footer, .form {display:none;} .col_33, .col_66, .col_50 { width:98%; float:none; } };T; @; @I"/css/reset/;T{;{;I") /* CSS reset. Based on HTML5 boilerplate reset http://html5boilerplate.com/ */ article, aside, details, figcaption, figure, footer, header, hgroup, nav, section { display:block; } audio[controls], canvas, video { display:inline-block; *display:inline; *zoom:1; } html { font-size: 100%; -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; } body { margin: 0; font-size: 14px; line-height: 1.4; } body, button, input, select, textarea { font-family:sans-serif; } a:focus { outline:thin dotted; } a:hover, a:active { outline:0; } abbr[title] { border-bottom:1px dotted; } b, strong { font-weight:bold; } blockquote { margin:1em 40px; } dfn { font-style:italic; } hr { display:block; height:1px; border:0; border-top:1px solid #ccc; margin:1em 0; padding:0; } ins { background:#ff9; color:#000; text-decoration:none; } mark { background:#ff0; color:#000; font-style:italic; font-weight:bold; } pre, code, kbd, samp { font-family:monospace, monospace; _font-family:'courier new', monospace; font-size:1em; } pre { white-space:pre; white-space:pre-wrap; word-wrap:break-word; } q { quotes:none; } q:before, q:after { content:""; content:none; } small { font-size:85%; } sub, sup { font-size:75%; line-height:0; position:relative; vertical-align:baseline; } sup { top:-0.5em; } sub { bottom:-0.25em; } ul, ol { margin:1em 0; padding:0 0 0 2em; } dd { margin:0 0 0 40px; } nav ul, nav ol { list-style:none; margin:0; padding:0; } img { border:0; -ms-interpolation-mode:bicubic; } svg:not(:root) { overflow:hidden;} figure { margin:0; } form { margin:0; } fieldset { border:0; margin:0; padding:0; } legend { border:0; *margin-left:-7px; padding:0; } label { cursor:pointer; } button, input, select, textarea { font-size:100%; margin:0; vertical-align:baseline; *vertical-align:middle; } button, input { line-height:normal; *overflow:visible; } button, input[type="button"], input[type="reset"], input[type="submit"] { cursor:pointer; -webkit-appearance:button; } input[type="checkbox"], input[type="radio"] { box-sizing:border-box; } input[type="search"] { -moz-box-sizing:content-box; -webkit-box-sizing:content-box; box-sizing:content-box; } button::-moz-focus-inner, input::-moz-focus-inner { border:0; padding:0; } textarea { overflow:auto; vertical-align:top; } input:valid, textarea:valid { } input:invalid, textarea:invalid { background-color:#f0dddd; } table { border-collapse:collapse; border-spacing:0; } .hidden { display:none; visibility:hidden; } .clearfix:before, .clearfix:after { content:""; display:table; } .clearfix:after { clear:both; } .clearfix { zoom:1; } /* End CSS reset */;T; @; @I"/;T{;{ ;I" Open Source Contribution from ksys labs.

Hello

Hello friends, Here is a place for public projects of ksys labs

We're hosting our Open Source projects at GitHub

Open Source Contribution:

Microkernel based projects:

L4Re (Addition) aPplications

OMAP3 support for L4Linux

Genode Framework Fork

Hardenning

Other:

Public projects:

Secure Mobile device project

Book of knowledge:

Tutorials

Use cases

How-to

;T; I"

Hello

Hello friends, Here is a place for public projects of ksys labs

We're hosting our Open Source projects at GitHub

Open Source Contribution:

Microkernel based projects:

L4Re (Addition) aPplications

OMAP3 support for L4Linux

Genode Framework Fork

Hardenning

Other:

Public projects:

Secure Mobile device project

Book of knowledge:

Tutorials

Use cases

How-to

;T; I"

Hello

Hello friends, Here is a place for public projects of ksys labs

We're hosting our Open Source projects at GitHub

Open Source Contribution:

Microkernel based projects:

L4Re (Addition) aPplications

OMAP3 support for L4Linux

Genode Framework Fork

Hardenning

Other:

Public projects:

Secure Mobile device project

Book of knowledge:

Tutorials

Use cases

How-to

;T; @"I" /sgnx/;T{;{ ;I"* Samsung Galaxy Nexus

Introduction

We’re currently working on two projects

  • Removing untrusted proprietary binaries from the android distribution
  • Virtualizing Android on top of the Genode framework

The primary development device for this project is the Samsung Galaxy Nexus phone.

Virtualization

Samsung Galaxy Nexus is based on the Texas Instruments OMAP4 CPU which is an ARMv7 core and thus incapable of hardware-assisted virtualization. We rely on paravirtualization therefore. A modified version of linux (L4Linux) is running on top of the Fiasco.OC L4 microkernel and the Genode Framework. Virtualization and moving drivers from linux to Genode gives us several advantages.

  • Running different OS (Android, Ubuntu) simultaneosly without rebooting
  • Putting untrusted code into containers like Qubes OS
  • Reusing the same L4Linux and Android userland on different phones, reducing update time
  • Using L4 IPC protects against stack smashing attacks against device drivers

A picture of the Galaxy Nexus phone running three instances of linux simultaneously.

2175944.jpg

Genode Support for Samsung Galaxy Nexus

repository

The tuna-hacks branch contains the WIP support for the Galaxy Nexus. Here is the list of our changes.

  • OMAP4 Framebuffer support for Galaxy Nexus (currently just using the framebuffer preconfigured by the SBL bootloader and changing the memory address and color space)
  • OMAP4 I2C support
  • OMAP4 GPIO MUX support
  • Melfas 144 Touchscreen Driver
  • L4Android fixes for linux kernel 3.5

To build a demo, use the “astarasikov/run/tuna-l4android35.run”. Refer to the general Genode building guide and do a “make run/tuna-l4android35” to build the system. Make sure to prepare an initial ramdisk image and edit the path to it in the tuna-l4android35.run file.

Alternatively, use a prebuilt demo image [still uploading] and refer to the u-boot section on the details about booting this image.

U-boot port

Detailed description is on the page gnex_uboot

To be able to run custom OS without reflashing the phone, we have ported the u-boot bootloader to the Galaxy Nexus phone. It currently has the following features

  • Acting as a replacement for Samsung SBL bootloader
  • Booting instead of linux kernel from Samsung SBL bootloader
  • Booting ANDROID! boot.img format images
  • Booting custom kernels from emmc (/sdcard)

U-boot source code

Take a look at the video showing u-boot booting Android without Samsung SBL bootloader!

U-boot demo

To build an image that can be flashed to the kernel partition (as opposed to replacing the SBL bootloader), edit the include/configs/omap4_tuna.h and comment out the #define TUNA_SPL_BUILD

If you put the u-boot instead of the kernel partition, put put the kernel in either u-boot or android image format to /boot/vmlinux.uimg inside the android system partition.

U-boot also supports booting custom kernels from the emmc (/sdcard partition). The kernel has to be put to /boot/vmlinux.uimg on /sdcard or /data/media/boot/vmlinux.uimg in the device root. Hold down the volume down key to boot a custom kernel

Currently u-boot has issues with reading EXT4 file system, large files (>10MB) mostly fail to load. So if you need them, check out the tuna_fosdem_hacks, format the cache partition to ext2, and put the kernel to /media/boot/vmlinux.uimg on the cache partition.

RIL (Radio Information Layer)

Overview

For a number of reasons, we wanted to replace the proprietary modem binaries with an open source implementation

  • It is impossible to put a closed binary into TCB (trusted computing base).
  • Having source code would allow to split modem-specific code into a separate daemon shared by multiple virtualized linuxes.

The modem inside Samsung Galaxy Nexus and Samsung Galaxy S2 is the Infenion XMM6260 modem running a custom baseband firmware from Samsung. The physical transport is different on these devices (S2 uses USB EHCI, while Nexus is using HCI which is a special kind of a fast serial port). Software-wise, the modem and the RIL exchange the packets of a HDLC-encoded data. These packages do not contain standard GSM AT commands, but the proprietary binary commands of the Samsung IPC protocol. XMM6260 uses SIPCv4 protocol.

The Replicant project already had a working implementation for the older phones (namely, the non-galaxy Nexus) so all we had to do was to write the firmware loader for the modem.

We’re nice guys and have contributed our work back to Replicant so now there’s full modem support with open-source drivers.

Since Replicant is under heavy development, we have a ‘stable’ mirror of the code in our repository which is tested to compile and work successfully.

Samsung IPC Library

libsamsung-ipc

Here is our patched libsamsung-ipc library which is implementing the SIPC protocol support and is not tied to a particular RIL implementation (Android, Ofono etc)

Our contribution includes:

  • Samsung Galaxy S2 support for XMM6260
  • Samsung Galaxy Nexus support for XMM6260
  • Fixing numerous bugs in EFS/RFS subsystem (IMEI, SIM contacts)

Samsung RIL

samsung-ril

Our additions include.

  • USSD Support for Galaxy Nexus
  • UTF8 (UCS2) support for USSD (tested with cyrillic russian messages)
  • GPRS Fixes and support for Galaxy Nexus
  • RSSI (signal strength) indicatior fixes

Samsung RIL Client

samsung ril client

RIL Client is a library which allows the GPS, NFC and Sound drivers to access the modem for certain power-management features. Our library is based on the Replicatn library, with the following additions.

  • Sound support for Galaxy Nexus
  • Stub routines to allow NFC and GPS drivers work
  • Can serve a drop-in replacement for the proprietary RIL client, while being compatible with all the proprietary binaries which depend on RIL.

GPS Proxy

As a part of the project to isolate trusted and untrusted stuff, we have implemented a daemon and the library that proxify the GPS interface for the Android OS. The rationale behind developing them was that reverse-engineering the Sirf Star 4 driver was unrealistic.

RPC Library. THe RPC Library can exchange arbitrary binary messages in both directions via a single socket. It is similiar to MSGPack, but much simpler. It uses select() calls to avoid polling.

GPS Proxy

The GPS proxy consists of a proxy library that implements the GPS interface and the daemon which loads the proprietary GPS binary. The proxy library and the daemon communicate via a socket using the RPC Library. The idea is that the untrusted binary driver can be run in an isolated l4linux container while being isolated from the trusted Android instance by an RPC transport. Using fixed-size RPC messages serves as a protection from stack smashing techiques.

;T; I"Introduction ==================== We're currently working on two projects * Removing untrusted proprietary binaries from the android distribution * Virtualizing Android on top of the Genode framework The primary development device for this project is the Samsung Galaxy Nexus phone. Virtualization --------------------- Samsung Galaxy Nexus is based on the Texas Instruments OMAP4 CPU which is an ARMv7 core and thus incapable of hardware-assisted virtualization. We rely on paravirtualization therefore. A modified version of linux (L4Linux) is running on top of the Fiasco.OC L4 microkernel and the Genode Framework. Virtualization and moving drivers from linux to Genode gives us several advantages. * Running different OS (Android, Ubuntu) simultaneosly without rebooting * Putting untrusted code into containers like Qubes OS * Reusing the same L4Linux and Android userland on different phones, reducing update time * Using L4 IPC protects against stack smashing attacks against device drivers A picture of the Galaxy Nexus phone running three instances of linux simultaneously. 2175944.jpg Genode Support for Samsung Galaxy Nexus --------------------- [repository](https://github.com/Ksys-labs/genode.git) The tuna-hacks branch contains the WIP support for the Galaxy Nexus. Here is the list of our changes. * OMAP4 Framebuffer support for Galaxy Nexus (currently just using the framebuffer preconfigured by the SBL bootloader and changing the memory address and color space) * OMAP4 I2C support * OMAP4 GPIO MUX support * Melfas 144 Touchscreen Driver * L4Android fixes for linux kernel 3.5 To build a demo, use the “astarasikov/run/tuna-l4android35.run”. Refer to the general Genode building guide and do a “make run/tuna-l4android35” to build the system. Make sure to prepare an initial ramdisk image and edit the path to it in the tuna-l4android35.run file. Alternatively, use a prebuilt demo image [still uploading] and refer to the u-boot section on the details about booting this image. U-boot port ==================== Detailed description is on the page [gnex_uboot](/gnex_uboot) To be able to run custom OS without reflashing the phone, we have ported the u-boot bootloader to the Galaxy Nexus phone. It currently has the following features * Acting as a replacement for Samsung SBL bootloader * Booting instead of linux kernel from Samsung SBL bootloader * Booting ANDROID! boot.img format images * Booting custom kernels from emmc (/sdcard) [U-boot source code](https://github.com/Ksys-labs/uboot-tuna.git) Take a look at the video showing u-boot booting Android without Samsung SBL bootloader! [U-boot demo](http://youtu.be/tcrNbwwPBkI) To build an image that can be flashed to the kernel partition (as opposed to replacing the SBL bootloader), edit the **include/configs/omap4_tuna.h** and comment out the **#define TUNA_SPL_BUILD** If you put the u-boot instead of the kernel partition, put put the kernel in either u-boot or android image format to **/boot/vmlinux.uimg** inside the android system partition. U-boot also supports booting custom kernels from the emmc (/sdcard partition). The kernel has to be put to /boot/vmlinux.uimg on /sdcard or /data/media/boot/vmlinux.uimg in the device root. Hold down the volume down key to boot a custom kernel Currently u-boot has issues with reading EXT4 file system, large files (>10MB) mostly fail to load. So if you need them, check out the **tuna_fosdem_hacks**, format the cache partition to ext2, and put the kernel to /media/boot/vmlinux.uimg on the cache partition. RIL (Radio Information Layer) ==================== Overview --------------------- For a number of reasons, we wanted to replace the proprietary modem binaries with an open source implementation * It is impossible to put a closed binary into TCB (trusted computing base). * Having source code would allow to split modem-specific code into a separate daemon shared by multiple virtualized linuxes. The modem inside Samsung Galaxy Nexus and Samsung Galaxy S2 is the Infenion XMM6260 modem running a custom baseband firmware from Samsung. The physical transport is different on these devices (S2 uses USB EHCI, while Nexus is using HCI which is a special kind of a fast serial port). Software-wise, the modem and the RIL exchange the packets of a HDLC-encoded data. These packages do not contain standard GSM AT commands, but the proprietary binary commands of the Samsung IPC protocol. XMM6260 uses SIPCv4 protocol. The [Replicant](http://replicant.us/) project already had a working implementation for the older phones (namely, the non-galaxy Nexus) so all we had to do was to write the firmware loader for the modem. We're nice guys and have contributed our work back to Replicant so now there's full modem support with open-source drivers. Since Replicant is under heavy development, we have a 'stable' mirror of the code in our repository which is tested to compile and work successfully. Samsung IPC Library --------------------- [libsamsung-ipc](https://github.com/Ksys-labs/libsamsung-ipc.git) Here is our patched libsamsung-ipc library which is implementing the SIPC protocol support and is not tied to a particular RIL implementation (Android, Ofono etc) Our contribution includes: * Samsung Galaxy S2 support for XMM6260 * Samsung Galaxy Nexus support for XMM6260 * Fixing numerous bugs in EFS/RFS subsystem (IMEI, SIM contacts) Samsung RIL --------------------- [samsung-ril](https://github.com/Ksys-labs/samsung-ril.git) Our additions include. * USSD Support for Galaxy Nexus * UTF8 (UCS2) support for USSD (tested with cyrillic russian messages) * GPRS Fixes and support for Galaxy Nexus * RSSI (signal strength) indicatior fixes Samsung RIL Client --------------------- [samsung ril client](https://github.com/Ksys-labs/samsung-ril-client.git) RIL Client is a library which allows the GPS, NFC and Sound drivers to access the modem for certain power-management features. Our library is based on the Replicatn library, with the following additions. * Sound support for Galaxy Nexus * Stub routines to allow NFC and GPS drivers work * Can serve a drop-in replacement for the proprietary RIL client, while being compatible with all the proprietary binaries which depend on RIL. GPS Proxy ==================== As a part of the project to isolate trusted and untrusted stuff, we have implemented a daemon and the library that proxify the GPS interface for the Android OS. The rationale behind developing them was that reverse-engineering the Sirf Star 4 driver was unrealistic. [RPC Library](https://github.com/Ksys-labs/libstc-rpc.git). THe RPC Library can exchange arbitrary binary messages in both directions via a single socket. It is similiar to MSGPack, but much simpler. It uses select() calls to avoid polling. [GPS Proxy](https://github.com/Ksys-labs/gps-proxy.git) The GPS proxy consists of a proxy library that implements the GPS interface and the daemon which loads the proprietary GPS binary. The proxy library and the daemon communicate via a socket using the RPC Library. The idea is that the untrusted binary driver can be run in an isolated l4linux container while being isolated from the trusted Android instance by an RPC transport. Using fixed-size RPC messages serves as a protection from stack smashing techiques.;T; I"

Introduction

We’re currently working on two projects

The primary development device for this project is the Samsung Galaxy Nexus phone.

Virtualization

Samsung Galaxy Nexus is based on the Texas Instruments OMAP4 CPU which is an ARMv7 core and thus incapable of hardware-assisted virtualization. We rely on paravirtualization therefore. A modified version of linux (L4Linux) is running on top of the Fiasco.OC L4 microkernel and the Genode Framework. Virtualization and moving drivers from linux to Genode gives us several advantages.

A picture of the Galaxy Nexus phone running three instances of linux simultaneously.

2175944.jpg

Genode Support for Samsung Galaxy Nexus

repository

The tuna-hacks branch contains the WIP support for the Galaxy Nexus. Here is the list of our changes.

To build a demo, use the “astarasikov/run/tuna-l4android35.run”. Refer to the general Genode building guide and do a “make run/tuna-l4android35” to build the system. Make sure to prepare an initial ramdisk image and edit the path to it in the tuna-l4android35.run file.

Alternatively, use a prebuilt demo image [still uploading] and refer to the u-boot section on the details about booting this image.

U-boot port

Detailed description is on the page gnex_uboot

To be able to run custom OS without reflashing the phone, we have ported the u-boot bootloader to the Galaxy Nexus phone. It currently has the following features

U-boot source code

Take a look at the video showing u-boot booting Android without Samsung SBL bootloader!

U-boot demo

To build an image that can be flashed to the kernel partition (as opposed to replacing the SBL bootloader), edit the include/configs/omap4_tuna.h and comment out the #define TUNA_SPL_BUILD

If you put the u-boot instead of the kernel partition, put put the kernel in either u-boot or android image format to /boot/vmlinux.uimg inside the android system partition.

U-boot also supports booting custom kernels from the emmc (/sdcard partition). The kernel has to be put to /boot/vmlinux.uimg on /sdcard or /data/media/boot/vmlinux.uimg in the device root. Hold down the volume down key to boot a custom kernel

Currently u-boot has issues with reading EXT4 file system, large files (>10MB) mostly fail to load. So if you need them, check out the tuna_fosdem_hacks, format the cache partition to ext2, and put the kernel to /media/boot/vmlinux.uimg on the cache partition.

RIL (Radio Information Layer)

Overview

For a number of reasons, we wanted to replace the proprietary modem binaries with an open source implementation

The modem inside Samsung Galaxy Nexus and Samsung Galaxy S2 is the Infenion XMM6260 modem running a custom baseband firmware from Samsung. The physical transport is different on these devices (S2 uses USB EHCI, while Nexus is using HCI which is a special kind of a fast serial port). Software-wise, the modem and the RIL exchange the packets of a HDLC-encoded data. These packages do not contain standard GSM AT commands, but the proprietary binary commands of the Samsung IPC protocol. XMM6260 uses SIPCv4 protocol.

The Replicant project already had a working implementation for the older phones (namely, the non-galaxy Nexus) so all we had to do was to write the firmware loader for the modem.

We’re nice guys and have contributed our work back to Replicant so now there’s full modem support with open-source drivers.

Since Replicant is under heavy development, we have a ‘stable’ mirror of the code in our repository which is tested to compile and work successfully.

Samsung IPC Library

libsamsung-ipc

Here is our patched libsamsung-ipc library which is implementing the SIPC protocol support and is not tied to a particular RIL implementation (Android, Ofono etc)

Our contribution includes:

Samsung RIL

samsung-ril

Our additions include.

Samsung RIL Client

samsung ril client

RIL Client is a library which allows the GPS, NFC and Sound drivers to access the modem for certain power-management features. Our library is based on the Replicatn library, with the following additions.

GPS Proxy

As a part of the project to isolate trusted and untrusted stuff, we have implemented a daemon and the library that proxify the GPS interface for the Android OS. The rationale behind developing them was that reverse-engineering the Sirf Star 4 driver was unrealistic.

RPC Library. THe RPC Library can exchange arbitrary binary messages in both directions via a single socket. It is similiar to MSGPack, but much simpler. It uses select() calls to avoid polling.

GPS Proxy

The GPS proxy consists of a proxy library that implements the GPS interface and the daemon which loads the proprietary GPS binary. The proxy library and the daemon communicate via a socket using the RPC Library. The idea is that the untrusted binary driver can be run in an isolated l4linux container while being isolated from the trusted Android instance by an RPC transport. Using fixed-size RPC messages serves as a protection from stack smashing techiques.

;T; @(I" /how-to/;T{;{ ;I" How-to

Here will be set of articles like ‘How to build a <..>’ or ‘How to run <..>’

How to use GDB to debug L4Re and L4Linux

;T; I"Here will be set of articles like 'How to build a <..>' or 'How to run <..>' [How to use GDB to debug L4Re and L4Linux](gdb_fiasco/);T; I"

Here will be set of articles like ‘How to build a <..>’ or ‘How to run <..>’

How to use GDB to debug L4Re and L4Linux

;T; @.I"/sitemap/;T{;{;I" http://ksyslabs.org/ 2014-11-03 http://ksyslabs.org/css/reset.css 2013-07-27 http://ksyslabs.org/css/skin.css 2013-07-27 http://ksyslabs.org/css/style.css 2013-07-27 http://ksyslabs.org/how-to/ 2014-01-14 http://ksyslabs.org/how-to/gdb_fiasco/ 2014-01-14 http://ksyslabs.org/robots.txt 2013-07-27 http://ksyslabs.org/sgnx/ 2013-07-27 http://ksyslabs.org/sitemap.xml 2013-07-27 http://ksyslabs.org/tutorials/ 2014-01-14 http://ksyslabs.org/tutorials/genode_nookhdp/ 2013-07-27 http://ksyslabs.org/tutorials/porting_genode_to_cubieboard/ 2013-07-27 http://ksyslabs.org/ukernels/genode_fork/ 2013-07-27 http://ksyslabs.org/ukernels/gnex_uboot/ 2013-07-27 http://ksyslabs.org/ukernels/hardenning/ 2014-01-28 http://ksyslabs.org/ukernels/hardenning/en/build/ 2014-01-14 http://ksyslabs.org/ukernels/hardenning/ru/build/ 2014-01-14 http://ksyslabs.org/ukernels/l4linux_usb-otg_wifi/ 2013-07-27 http://ksyslabs.org/ukernels/l4reap/ 2014-01-14 http://ksyslabs.org/ukernels/lab/ 2013-07-29 http://ksyslabs.org/upload/a10_diagram.png 2013-07-27 http://ksyslabs.org/upload/a10_mem.png 2013-07-27 http://ksyslabs.org/upload/cubieboard.png 2013-07-27 http://ksyslabs.org/upload/reaping-mach_25922_sm.gif 2013-07-27 http://ksyslabs.org/use-cases/ 2014-01-14 http://ksyslabs.org/use-cases/gateway/ 2013-07-27 ;T; I"<%= xml_sitemap %> ;T; @4I"/use-cases/gateway/;T{;{ ;I"e] Gateway

Gateway

This example shows the use network between two L4Linux on Genode. We have two instances of L4linux and two network interfaces.

                       +----------------+              +----------------+
                       |   L4Linux 1    |              |   L4Linux 2    |
  +-------+            |----------------|              |----------------|          +-------+
  | NIC 1 |       +----+                +----+    +----+                +----+     | NIC 2 |
  |-------|       |Nic |                |Nic |    |Nic |                |Nic |     |-------|
  |       |<------+clnt|                |srv |<---+clnt|                |clnt+---->|       |
  |       |       |eth0|                |eth1|    |eth0|                |eth1|     |       |
  +-------+       +----+                +----+    +----+                +----+     +-------+
                       +----------------+              +----------------+

The first issue is that the current version of Genode dde_ipxe cannot use two instances NIC driver. We’ve extend the NIC driver configuration and required NIC interface can be selected via . The second part of this issue is IRQ remapping for PCI devices in Genode. PCI IRQ can be remapped via ACPI or MSI. But Genode's ACPI driver is broken. MSI isn't implemented yet. We have temporary hacked this issue via moving PCI IRQ handling to PCI driver.

Second issue is second NIC interface in L4Linux. We have wrote driver for l4linux which implemented NIC service and extend Genode’s net driver for l4linux for working with more that one NIC interface.

Sources for this example is available in l4linux-net branch on our Genode fork at Github.

Example of configuration is available in iloskutov/run/l4linux2.run

About this configuration:

        <start name="nic_drv.1">
                <binary name="nic_drv"/>
                <config>
                        <nic device="00:03.0"/>
                </config>
                <resource name="RAM" quantum="8M"/>
                <provides><service name="Nic"/></provides>
        </start>
        <start name="nic_drv.2">
                <binary name="nic_drv"/>
                <config>
                        <nic device="00:04.0"/>
                </config>
                <resource name="RAM" quantum="8M"/>
                <provides><service name="Nic"/></provides>
        </start>

We configure which NIC use via <nic device=“00:04.0”/> , where 00:04.0 is address of NIC device on PCI bus.

  1. L4Linux’s configuration
        <start name="l4linux.1">
                <binary name="l4linux-srv"/>
                <resource name="RAM" quantum="200M"/>
                <config args="mem=128M console=tty1 console=ttyS0 l4x_rd=initrd.gz l4x_cpus=1 l4x_cpus_map=0"/>
                <provides>
                        <service name="Nic"/>
                </provides>
                <route>
                        <service name="Input">       <child name="linux.1.fb"/> </service>
                        <service name="Framebuffer"> <child name="linux.1.fb"/> </service>
                        <service name="Nic">         <child name="nic_drv.1"/> </service> 
                        <service name="Terminal">    <child name="linux.1.log"/> </service>
                        <any-service> <parent/> <any-child/> </any-service>
                </route>
        </start>
        <start name="l4linux.2">
                <binary name="l4linux-clnt"/>
                <resource name="RAM" quantum="200M"/>
                <config args="mem=128M console=tty1 console=ttyS0 l4x_rd=initrd.gz l4x_cpus=1 l4x_cpus_map=1 genode_net.if_nums=2"/>
                <route>
                        <service name="Input">       <child name="linux.2.fb"/> </service>
                        <service name="Framebuffer"> <child name="linux.2.fb"/> </service>
                        <service name="Nic">
                                <if-arg key="label" value="eth0"/> <child name="nic_drv.2"/>
                        </service>
                        <service name="Nic">
                                <if-arg key="label" value="eth1"/> <child name="l4linux.1"/>
                        </service>
                        <service name="Terminal">    <child name="linux.2.log"/> </service>
                        <any-service> <parent/> <any-child/> </any-service>
                </route>
        </start>

The first l4linux provides Nic service. For enable it add CONFIG_NET_NIC_SRV=y to l4linux configuration, see iloskutov/src/l4linux-srv/x8632/linux_config.x8632 The second l4linux uses two Nic interfaces. For enable it add genode_net.if_nums=2 to linux command line. For route Nic interfaces is used if-arg mechanism, lines 23-28

Building

Pull sources from Github and switch to l4linux-net branch.

git clone git://github.com/Ksys-labs/genode.git ksyslabs-genode cd ksyslabs-genode git checkout l4linux-net Prepare modules base-foc, libport, dde_ipxe and ports-foc

make prepare -C base-foc
make prepare -C libport
make prepare -C dde_ipxe
make prepare -C ports-foc

Create build directory:

./tool/create_builddir foc_x8632 BUILD_DIR=build.foc_x8632 cd build.foc_x86_32

Modify etc/build.conf. Uncomment repositories gems, libport, dde_ipxe and ports-foc and add REPOSITORIES += $(GENODE_DIR)/iloskutov

Running

make run/l4linux2

Testing internal network

Configure eth1 in both l4linux and try to ping from one to other.

;T; I"Gateway ========== This example shows the use network between two L4Linux on Genode. We have two instances of L4linux and two network interfaces. ~~~ +----------------+ +----------------+ | L4Linux 1 | | L4Linux 2 | +-------+ |----------------| |----------------| +-------+ | NIC 1 | +----+ +----+ +----+ +----+ | NIC 2 | |-------| |Nic | |Nic | |Nic | |Nic | |-------| | |<------+clnt| |srv |<---+clnt| |clnt+---->| | | | |eth0| |eth1| |eth0| |eth1| | | +-------+ +----+ +----+ +----+ +----+ +-------+ +----------------+ +----------------+ ~~~ {:.language} The first issue is that the current version of Genode dde_ipxe cannot use two instances NIC driver. We've extend the NIC driver configuration and required NIC interface can be selected via . The second part of this issue is IRQ remapping for PCI devices in Genode. PCI IRQ can be remapped via ACPI or MSI. But Genode's ACPI driver is broken. MSI isn't implemented yet. We have temporary hacked this issue via moving PCI IRQ handling to PCI driver. Second issue is second NIC interface in L4Linux. We have wrote driver for l4linux which implemented NIC service and extend Genode's net driver for l4linux for working with more that one NIC interface. Sources for this example is available in l4linux-net branch on our [Genode fork](https://github.com/Ksys-labs/genode/tree/l4linux-net) at Github. Example of configuration is available in iloskutov/run/l4linux2.run About this configuration: ~~~ ~~~ {:.language-xml} We configure which NIC use via , where 00:04.0 is address of NIC device on PCI bus. 2. L4Linux's configuration ~~~ ~~~ {:.language-xml} The first l4linux provides Nic service. For enable it add CONFIG_NET_NIC_SRV=y to l4linux configuration, see iloskutov/src/l4linux-srv/x86_32/linux_config.x86_32 The second l4linux uses two Nic interfaces. For enable it add genode_net.if_nums=2 to linux command line. For route Nic interfaces is used if-arg mechanism, lines 23-28 Building ========== Pull sources from Github and switch to l4linux-net branch. git clone git://github.com/Ksys-labs/genode.git ksyslabs-genode cd ksyslabs-genode git checkout l4linux-net Prepare modules base-foc, libport, dde_ipxe and ports-foc ~~~ make prepare -C base-foc make prepare -C libport make prepare -C dde_ipxe make prepare -C ports-foc ~~~ {:.language-text} Create build directory: ./tool/create_builddir foc_x86_32 BUILD_DIR=build.foc_x86_32 cd build.foc_x86_32 Modify etc/build.conf. Uncomment repositories gems, libport, dde_ipxe and ports-foc and add REPOSITORIES += $(GENODE_DIR)/iloskutov Running ========== make run/l4linux2 Testing internal network ========== Configure eth1 in both l4linux and try to ping from one to other.;T; I"R

Gateway

This example shows the use network between two L4Linux on Genode. We have two instances of L4linux and two network interfaces.

                       +----------------+              +----------------+
                       |   L4Linux 1    |              |   L4Linux 2    |
  +-------+            |----------------|              |----------------|          +-------+
  | NIC 1 |       +----+                +----+    +----+                +----+     | NIC 2 |
  |-------|       |Nic |                |Nic |    |Nic |                |Nic |     |-------|
  |       |<------+clnt|                |srv |<---+clnt|                |clnt+---->|       |
  |       |       |eth0|                |eth1|    |eth0|                |eth1|     |       |
  +-------+       +----+                +----+    +----+                +----+     +-------+
                       +----------------+              +----------------+

The first issue is that the current version of Genode dde_ipxe cannot use two instances NIC driver. We’ve extend the NIC driver configuration and required NIC interface can be selected via . The second part of this issue is IRQ remapping for PCI devices in Genode. PCI IRQ can be remapped via ACPI or MSI. But Genode's ACPI driver is broken. MSI isn't implemented yet. We have temporary hacked this issue via moving PCI IRQ handling to PCI driver.

Second issue is second NIC interface in L4Linux. We have wrote driver for l4linux which implemented NIC service and extend Genode’s net driver for l4linux for working with more that one NIC interface.

Sources for this example is available in l4linux-net branch on our Genode fork at Github.

Example of configuration is available in iloskutov/run/l4linux2.run

About this configuration:

        <start name="nic_drv.1">
                <binary name="nic_drv"/>
                <config>
                        <nic device="00:03.0"/>
                </config>
                <resource name="RAM" quantum="8M"/>
                <provides><service name="Nic"/></provides>
        </start>
        <start name="nic_drv.2">
                <binary name="nic_drv"/>
                <config>
                        <nic device="00:04.0"/>
                </config>
                <resource name="RAM" quantum="8M"/>
                <provides><service name="Nic"/></provides>
        </start>

We configure which NIC use via <nic device=“00:04.0”/> , where 00:04.0 is address of NIC device on PCI bus.

  1. L4Linux’s configuration
        <start name="l4linux.1">
                <binary name="l4linux-srv"/>
                <resource name="RAM" quantum="200M"/>
                <config args="mem=128M console=tty1 console=ttyS0 l4x_rd=initrd.gz l4x_cpus=1 l4x_cpus_map=0"/>
                <provides>
                        <service name="Nic"/>
                </provides>
                <route>
                        <service name="Input">       <child name="linux.1.fb"/> </service>
                        <service name="Framebuffer"> <child name="linux.1.fb"/> </service>
                        <service name="Nic">         <child name="nic_drv.1"/> </service> 
                        <service name="Terminal">    <child name="linux.1.log"/> </service>
                        <any-service> <parent/> <any-child/> </any-service>
                </route>
        </start>
        <start name="l4linux.2">
                <binary name="l4linux-clnt"/>
                <resource name="RAM" quantum="200M"/>
                <config args="mem=128M console=tty1 console=ttyS0 l4x_rd=initrd.gz l4x_cpus=1 l4x_cpus_map=1 genode_net.if_nums=2"/>
                <route>
                        <service name="Input">       <child name="linux.2.fb"/> </service>
                        <service name="Framebuffer"> <child name="linux.2.fb"/> </service>
                        <service name="Nic">
                                <if-arg key="label" value="eth0"/> <child name="nic_drv.2"/>
                        </service>
                        <service name="Nic">
                                <if-arg key="label" value="eth1"/> <child name="l4linux.1"/>
                        </service>
                        <service name="Terminal">    <child name="linux.2.log"/> </service>
                        <any-service> <parent/> <any-child/> </any-service>
                </route>
        </start>

The first l4linux provides Nic service. For enable it add CONFIG_NET_NIC_SRV=y to l4linux configuration, see iloskutov/src/l4linux-srv/x8632/linux_config.x8632 The second l4linux uses two Nic interfaces. For enable it add genode_net.if_nums=2 to linux command line. For route Nic interfaces is used if-arg mechanism, lines 23-28

Building

Pull sources from Github and switch to l4linux-net branch.

git clone git://github.com/Ksys-labs/genode.git ksyslabs-genode cd ksyslabs-genode git checkout l4linux-net Prepare modules base-foc, libport, dde_ipxe and ports-foc

make prepare -C base-foc
make prepare -C libport
make prepare -C dde_ipxe
make prepare -C ports-foc

Create build directory:

./tool/create_builddir foc_x8632 BUILD_DIR=build.foc_x8632 cd build.foc_x86_32

Modify etc/build.conf. Uncomment repositories gems, libport, dde_ipxe and ports-foc and add REPOSITORIES += $(GENODE_DIR)/iloskutov

Running

make run/l4linux2

Testing internal network

Configure eth1 in both l4linux and try to ping from one to other.

;T; @9I" /l4reap/;T{;{ ;I"p L4Reap, L4Re (additionl) aPplications
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

text

We’ve ported and customized several software projects to run on top of L4Re.

L4Reap Repository

The list of software includes:

  • freetype2
  • libsigc++
  • libwhefs
  • libxml2
  • openssl
  • disko
;T; I"![text](/upload/reaping-mach_25922_sm.gif) We've ported and customized several software projects to run on top of L4Re. [L4Reap Repository](https://github.com/Ksys-labs/L4Reap.git) ## The list of software includes: * freetype2 * libsigc++ * libwhefs * libxml2 * openssl * disko;T; I"

text

We’ve ported and customized several software projects to run on top of L4Re.

L4Reap Repository

The list of software includes:

;T; @?I"/l4linux_usb-otg_wifi/;T{;{ ;I" OMAP3 L4Linux usb-otg with wifi
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

Overview

L4Reap is a modified version of L4Linux created to run on TI OMAP3 (Gumstix Overo, IGEP). The goal of this project is to make a certain number of hardware resources accessible and usable from whithin a paravirtualized environment.

List of Supported Hardware

  • Libertas WiFi module
  • USB OTG Ethernet Gadget

Build Instructions

Cross Toolchain

L4Reap is known to work with CodeSourcery 2011.03 toolchain for ARM:

arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

We assume that toolchain is set up and available as arm-linux-gcc, arm-linux-ld, etc.

Setup

mkdir build
export L4DIR=`pwd`
export L4BUI=$L4DIR/build 
svn co http://svn.tudos.org/repos/oc/tudos/trunk/@40 src
git clone git://github.com/Ksys-labs/L4Reap.git

Building

Building Fiasco.OC Kernel

make BUILDDIR=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco
make -C $L4BUI/kernel config

Choose following options from menu:

Target configuration  ---> 
  Architecture (ARM processor family)  --->
  Platform (TI OMAP)  -->
  OMAP Platform (Beagle Board)  --->
make O=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco

Build L4Re

mkdir $L4BUI/l4
make O=$L4BUI/l4 -C $L4DIR/src/l4 config

Choose following options from menu:

  Target Architecture (ARM architecture)  --->                            
     CPU variant (ARMv7A type CPU)  --->
     Platform Selection (Beagleboard)  --->   

make O=$L4BUI/l4 -C $L4DIR/src/l4

Build L4Linux

make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- l4reap_defconfig
echo CONFIG_L4_OBJ_TREE=\"$L4BUI/l4\" >> $L4BUI/l4reap/.config
make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux-

Creating a Bootable Image

make O=$L4BUI/l4 -C $L4DIR/src/l4 \
  MODULES_LIST=$L4DIR/L4Reap/files/modules.list \
  MODULE_SEARCH_PATH=$L4DIR/L4Reap/files:$L4BUI/kernel:$L4BUI/l4reap \
  E=l4reap uimage

Running

Booting from MMC:

mmc rescan 0
fatload mmc 0 80000000 l4img
bootm 80000000

Bugs and Limitations

The system does not survive:

  • OTG unplugging
  • ifconfig usb0 down
  • Hi, I’m a new item!
;T; I" Overview ==================== L4Reap is a modified version of L4Linux created to run on TI OMAP3 (Gumstix Overo, IGEP). The goal of this project is to make a certain number of hardware resources accessible and usable from whithin a paravirtualized environment. List of Supported Hardware --------------------- * Libertas WiFi module * USB OTG Ethernet Gadget Build Instructions ==================== Cross Toolchain --------------------- L4Reap is known to work with CodeSourcery 2011.03 toolchain for ARM: ~~~ arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ~~~ We assume that toolchain is set up and available as arm-linux-gcc, arm-linux-ld, etc. Setup --------------------- ~~~ mkdir build export L4DIR=`pwd` export L4BUI=$L4DIR/build svn co http://svn.tudos.org/repos/oc/tudos/trunk/@40 src git clone git://github.com/Ksys-labs/L4Reap.git ~~~ {:.language-text} Building --------------------- Building Fiasco.OC Kernel ~~~ make BUILDDIR=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco make -C $L4BUI/kernel config ~~~ {:.language-text} Choose following options from menu: ~~~ Target configuration ---> Architecture (ARM processor family) ---> Platform (TI OMAP) --> OMAP Platform (Beagle Board) ---> make O=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco ~~~ {:.language-text} Build L4Re ~~~ mkdir $L4BUI/l4 make O=$L4BUI/l4 -C $L4DIR/src/l4 config ~~~ {:.language-text} Choose following options from menu: ~~~ Target Architecture (ARM architecture) ---> CPU variant (ARMv7A type CPU) ---> Platform Selection (Beagleboard) ---> make O=$L4BUI/l4 -C $L4DIR/src/l4 ~~~ {:.language-text} Build L4Linux ~~~ make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- l4reap_defconfig echo CONFIG_L4_OBJ_TREE=\"$L4BUI/l4\" >> $L4BUI/l4reap/.config make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- ~~~ {:.language-text} Creating a Bootable Image --------------------- ~~~ make O=$L4BUI/l4 -C $L4DIR/src/l4 \ MODULES_LIST=$L4DIR/L4Reap/files/modules.list \ MODULE_SEARCH_PATH=$L4DIR/L4Reap/files:$L4BUI/kernel:$L4BUI/l4reap \ E=l4reap uimage ~~~ {:.language-text} Running ==================== Booting from MMC: ~~~ mmc rescan 0 fatload mmc 0 80000000 l4img bootm 80000000 ~~~ {:.language-text} Bugs and Limitations ==================== The system does not survive: * OTG unplugging * ifconfig usb0 down * Hi, I'm a new item!;T; I"L

Overview

L4Reap is a modified version of L4Linux created to run on TI OMAP3 (Gumstix Overo, IGEP). The goal of this project is to make a certain number of hardware resources accessible and usable from whithin a paravirtualized environment.

List of Supported Hardware

Build Instructions

Cross Toolchain

L4Reap is known to work with CodeSourcery 2011.03 toolchain for ARM:

arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

We assume that toolchain is set up and available as arm-linux-gcc, arm-linux-ld, etc.

Setup

mkdir build
export L4DIR=`pwd`
export L4BUI=$L4DIR/build 
svn co http://svn.tudos.org/repos/oc/tudos/trunk/@40 src
git clone git://github.com/Ksys-labs/L4Reap.git

Building

Building Fiasco.OC Kernel

make BUILDDIR=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco
make -C $L4BUI/kernel config

Choose following options from menu:

Target configuration  ---> 
  Architecture (ARM processor family)  --->
  Platform (TI OMAP)  -->
  OMAP Platform (Beagle Board)  --->
make O=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco

Build L4Re

mkdir $L4BUI/l4
make O=$L4BUI/l4 -C $L4DIR/src/l4 config

Choose following options from menu:

  Target Architecture (ARM architecture)  --->                            
     CPU variant (ARMv7A type CPU)  --->
     Platform Selection (Beagleboard)  --->   

make O=$L4BUI/l4 -C $L4DIR/src/l4

Build L4Linux

make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- l4reap_defconfig
echo CONFIG_L4_OBJ_TREE=\"$L4BUI/l4\" >> $L4BUI/l4reap/.config
make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux-

Creating a Bootable Image

make O=$L4BUI/l4 -C $L4DIR/src/l4 \
  MODULES_LIST=$L4DIR/L4Reap/files/modules.list \
  MODULE_SEARCH_PATH=$L4DIR/L4Reap/files:$L4BUI/kernel:$L4BUI/l4reap \
  E=l4reap uimage

Running

Booting from MMC:

mmc rescan 0
fatload mmc 0 80000000 l4img
bootm 80000000

Bugs and Limitations

The system does not survive:

;T; @EI"#/upload/reaping-mach_25922_sm/;T{;{I"/upload/a10_mem/;T{;{I"/upload/cubieboard/;T{;{I"/upload/a10_diagram/;T{;{I"/tutorials/genode_nookhdp/;T{;{ ;I"Y Porting Genode Framework to B&N Nook HD+

Rationale

So, why the Nook HD+? While I have alrealy ported Genode to the Samsung Galaxy Nexus phone for the FOSDEM 2013 demo session, I decided to give another device a try for the following reasons:

  • As a tablet, it has much less hardware (at least, no phone) to support in order to be a daily driver
  • Some peripherals and hardware setup varies between it and the Nexus, so it may help exposing new bugs or hardcodery
  • It has the microSD slot connected to OMAP4 mmc0 with standard voltage setup (the VMODE bit). This is extremely useful because it allows to directly use the Genode MMC driver and it is easy to setup a MBR/VFAT filesystem on the microSD. Galaxy Nexus, on the contrary, has no external memory card slot, and to access the internal memory, it is necessary to implement a small change in the MMC driver and implement the EFI GPT partition parser
  • It has a Full HD display, and I have passion for hi-res screens. Besides, hi-res is a way to stress-test memory subsystem and framebuffer performance
  • Because I can

U-boot

Booting custom software on a commercial device is usually connected with some obstacles, like breaking the chain of trust. A typical approach (which I have utilized for many devices, including Acer Iconia A500, Samsung Galaxy S2 and Samsung Galaxy Nexus) is porting the u-boot bootloader to be an intermediate chainloader, flashed instead of the linux kernel.

The B&N Nook HD+ does feature the signed kernel-based chain of trust for the internal EMMC memory, but it allows booting unsigned MLO, xloader and u-boot from the external microSD card. That is to say, there already exists the u-boot port, but to make it boot Genode, numerous changes were needed.

First, I’ve obtained the android cwm recovery image for the sd card from the B&N Nook HD+ forum on xda-developers.com [credits go to the forum members verygreen and fat-tire]. After writing the image to the SD card and fixing partition layout in fdisk, I ended up with a VFAT partition containing the MLO, u-boot.bin and uImage. The MLO is the header file for the omap4 CPU which combines the memory initialization table with the x-loader bootloader. The u-boot.bin is the almost vanilla B&N u-boot which initializes the display and boots the uImage [which in the case of sd booting is also u-boot]. We’ll be replacing the uImage with the customized u-boot.

You can obtain the source code for my u-boot from https://github.com/astarasikov/uboot-bn-nook-hd-fastboot and below is the list of problems I’ve solved:

  • Removing the [unneeded for us] emmc and sd boot options.
  • Enabling fastboot. The bootloader listens on usb for the fastboot connection. “fastboot continue” allows to boot the “kernel” and “ramdisk” files from the sd card
  • Fixed display initialization. Turns out, the code in the uImage was broken, and did not reinit the display properly. The reasons were that it lacked one power GPIO (which would cause it to never come up after reset on some hardware revisions, my tablet being one of the unlucky ones), and the typo in one of the frame sync borders (which caused all font symbols to be one pixel tall). The display initialization code was scattered around 4 files, contained hardcoded definitions for another board. The framebuffer initialization was done in the MMC driver (sic!).
  • Fixed booting “ANDROID!” boot images over fastboot with the “booti” command. The code contained many incorrect assumptions about the image layout.
  • Moved the u-boot base in RAM and increased the fastboot buffer to allow downloading huge images (up to 496M). This allows me to boot Genode images with the built-in ramdisk with the root file system while I’ve not completed the GPT support
  • Enabled the framebuffer console for debugging

Genode

I had to do some changes to make Genode run. I’ll briefly discuss some notable items.

Fiasco.OC cross-compiling

Recently, Genode crew have updated to the latest revision of the Fiasco.OC microkernel and it seems to contain some hardcoded cross-compiler name for ARM. I was reluctant to either fix it or download the ‘proper’ compiler (especially knowing that the one from the Genode toolchain does work for omap4).

So, here is what I’ve done:

  • Made a new directory and added it to the PATH variable (append “export PATH=/path/to/that/very/dir/:$PATH” to your .bashrc if you have no slightest idea what I’m talking about)
  • Made symbolic links for the fake “arm-linux” toolchain pointing to genode with “for i in ls /usr/local/genode-gcc/bin/genode-arm*;do ln -s $i ${i//*genode-arm/arm-linux} ;done”

Increasing nitpicker memory quota.

Currently nitpicker [window manager providing virtual framebuffers] is hardcoded for some 1024x768 screens (I believe because no one, even at genode, seriously considers using Genode as a daily driver today), so we need to fix the memory limit constant in the following way:

-- a/os/include/nitpicker_session/connection.h
++ b/os/include/nitpicker_session/connection.h
@@ -43,8 +43,8 @@ namespace Nitpicker {
                                char argbuf[ARGBUF_SIZE];
                                argbuf[0] = 0;



Adding LCD support to omap4 framebuffer

Currently, omap4 framebuffer only supports the TV interface for HDMI. To make it reset and configure the LCD interface (which is used in smartphones and tablets), we need to add some register definitions [and fix the incorrect definition of the base address register while we’re at it] to the code according to the omap4 DSS subsystem manual.

diff --git a/os/src/drivers/framebuffer/omap4/dispc.h b/os/src/drivers/framebuffer/omap4/dispc.h
index 23f80df..ea9f602 100644
-- a/os/src/drivers/framebuffer/omap4/dispc.h
++ b/os/src/drivers/framebuffer/omap4/dispc.h
@@ -18,8 +18,14 @@ struct Dispc : Genode::Mmio
         */
        struct Control1 : Register<0x40, 32>
        {

                struct Tv_enable : Bitfield<1, 1> { };
 





                struct Go_tv : Bitfield<6, 1>
                {
                        enum { HW_UPDATE_DONE    = 0x0,   /* set by HW after updating */
@@ -46,11 +52,17 @@ struct Dispc : Genode::Mmio
                struct Width  : Bitfield<0, 11>  { };
                struct Height : Bitfield<16, 11> { };
        };





 
        /**
         * Configures base address of the graphics buffer
         */



 
        /**
         * Configures the size of the graphics window
diff --git a/os/src/drivers/framebuffer/omap4/driver.h b/os/src/drivers/framebuffer/omap4/driver.h
index d754a97..53517a3 100644


@@ -203,6 +203,7 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        }
        _dispc.write<Dispc::Gfx_attributes::Format>(pixel_format);

        _dispc.write<Dispc::Gfx_ba1>(phys_base);
 
        _dispc.write<Dispc::Gfx_size::Sizex>(width(mode) - 1);

Hacking in Nook HD+ display support.

I wanted to make the display work in a quick and dirty way, so I’ve commented out the HDMI init code and replaced with a simple code that reconfigured the framebuffer address for the LCD (we piggyback on the u-boot to initialize the screen). Remember, kids, never ever think of doing this in production. I am deeply ashamed of havind done that. Either way, I’ll show you the code, and the framebuffer driver badly wants some changes:

  • Adding proper LCD initailization
  • Configurable resolution via the config
  • Support for DSI/DPI interface initialization and custom panel drivers
  • Rotation and HW blitting
  • Ok, enough talk, here’s the patch
diff --git a/os/src/drivers/framebuffer/omap4/driver.h b/os/src/drivers/framebuffer/omap4/driver.h
index 53517a3..9287cdc 100644
-- a/os/src/drivers/framebuffer/omap4/driver.h
++ b/os/src/drivers/framebuffer/omap4/driver.h
@@ -76,6 +76,7 @@ class Framebuffer::Driver
 
                static size_t width(Mode mode)
                {

                        switch (mode) {
                        case MODE_1024_768: return 1024;
                        }
@@ -84,6 +85,7 @@ class Framebuffer::Driver
 
                static size_t height(Mode mode)
                {

                        switch (mode) {
                        case MODE_1024_768: return 768;
                        }
@@ -117,12 +119,17 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
                                Framebuffer::addr_t         phys_base)
 {
        /* enable display core clock and set divider to 1 */

        _dispc.write<Dispc::Divisor::Lcd>(1);
        _dispc.write<Dispc::Divisor::Enable>(1);



 
        /* set load mode */
        _dispc.write<Dispc::Config1::Load_mode>(Dispc::Config1::Load_mode::DATA_EVERY_FRAME);
 

        _hdmi.write<Hdmi::Video_cfg::Start>(0);
 
        if (!_hdmi.issue_pwr_pll_command(Hdmi::Pwr_ctrl::ALL_OFF, _delayer)) {
@@ -196,6 +203,10 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        _dispc.write<Dispc::Size_tv::Height>(height(mode) - 1);
 
        _hdmi.write<Hdmi::Video_cfg::Start>(1);




 
        Dispc::Gfx_attributes::access_t pixel_format = 0;
        switch (format) {
@@ -212,6 +223,7 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        _dispc.write<Dispc::Global_buffer>(0x6d2240);
        _dispc.write<Dispc::Gfx_attributes::Enable>(1);
 

        _dispc.write<Dispc::Gfx_attributes::Channelout>(Dispc::Gfx_attributes::Channelout::TV);
        _dispc.write<Dispc::Gfx_attributes::Channelout2>(Dispc::Gfx_attributes::Channelout2::PRIMARY_LCD);
 
@@ -223,6 +235,9 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
                PERR("Go_tv timed out");
                return false;
        }



 
        return true;
 }

Configuration file

Genode is configured via the XML configuration file. Here are some notes We’re using the dde_kit usb_drv driver to provide stubs for networking and input drivers The nic_bridge proxifies the networking for two l4linux instances nitpicker and nit_fb are used to split the display into virtual framebuffers both nic_bridge and nit_fb are using the Genode concepts of the service interfaces and service routing. We’re configuring the services in such a way that they’re using the specific service if needed, and rely on the parent to provide the default service if we dont’ care. For example, take a look at how nic_bridge is configured. The usb_drv features the “provides” section that declares which interfaces the service is allowed to provide. These may be used in the “route” section of the client services. By default, Genode features a deny-all policy, so if you don’t configure something, you have no access to it. usb_drv has some memory leak (or had back in winter and I was lazy to look into it) so I’ve increased the RAM quota and hoped it would survive. It did.

 <start name="usb_drv">
  <resource name="RAM" quantum="40M"/>
  <provides>
   <service name="Input"/>
   <service name="Nic"/>
  </provides>
  <config>
   <hid/>
   <nic mac="2e:60:90:0c:4e:01" />
  </config>
 </start>

 <start name="nic_bridge">
  <resource name="RAM" quantum="2M"/>
  <provides><service name="Nic"/></provides>
  <route>
   <service name="Nic"> <child name="usb_drv"/> </service>
   <any-service> <parent/> <any-child/> </any-service>
  </route>
 </start>

Compiling and running

So, how about trying it out yourself?

Install the Genode toolchain (consult the Genode website and sourceforge project) and create the symlinks as explained above.

Get the u-boot source code

git clone git://github.com/astarasikov/uboot-bn-nook-hd-fastboot.git

Compile U-boot.

I recommend using the codesourcery 2010q1-188 toolchain (because not all toolchains produce working code)

export PATH=/path/to/codesourcery/toolchain/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-
U_BOARD=bn_ovation
make clean
make distclean
make ${U_BOARD}_config
make -j8 
./tools/mkimage -A arm -O linux -T kernel -C none -a 0x88000000 -e 0x88000000 -n foo -d u-boot.bin uImage

Get the genode framework source code

git clone git://github.com/astarasikov/genode.git
git checkout nook_staging

Now, for each directory in the genode tree (base-foc, and non-base directories), go to them and execute “make prepare” to download the required libraries. Well, libports is heavily broken and many packages (openssl, zlib, any more?) fail to download. You can skip libports and qt4 for now.

Prepare the build directory

./tool/create_builddir foc_panda BUILD_DIR=/my/build/dir

Edit the /my/build/dir/etc/build.conf

Uncomment the “REPOSITORIES += “ entries to allow building l4linux and nitpicker

Add the “MAKE += -j8” to the file to build in parallel utilizing all CPU cores.

Add “SPECS += uboot” to the /my/build/dir/etc/specs.conf to force creating the raw image.bin.gz binary.

Compile the Genode framework

cd /my/build/dir
make run/nookhdp_l4linux

Actually running the image

Now, you may wonder how to run the image. The tablet must be in the fastboot mode. Genode expects itself to be loaded at 0x81000000, and the u-boot does make a stupid assumption that linux kernel must be shifted 0x8000 bytes (i.e., 2 pages) from the base address. It should be fixed eventually, but for now, we’re manually substracting the offset from the boot address

gunzip var/run/nookhdp_l4linux/image.bin.gz
fastboot -b 0x80ff8000 boot var/run/nookhdp_l4linux/image.bin

Results

Here is a picture of the Genode running. You can see the screen split into four parts with the help of the Nitpicker window manager. Each screen chunk is a virtual framebuffer provided by the Nit_fb service. Genode is running the Launchpad server (top right corner), the LOG written to the framebuffer (bottom left) and two instances of L4Linux.

Genode on Nook HD+ Photo

So, now it does not do much useful work, but remember it was an overnight proof of concept hacked together with the sole purpose of demonstrating the capabilities of Genode Framework, and this tutorial is basically a collection of anti-patterns.

Future plans

  • Since I want to have a fully-functional port on both the Nook HD+ and Samsung Galaxy Nexus, here are some areas of interest for me and anyone who would like to contribute
  • Upstream OMAP4 and I.MX53 I2C drivers (we at Ksys Labs have written them almost a year ago and they’re working fine, but had no time to suggest them to Genode Labs)
  • Upstream GPIOMUX interface for OMAP4
  • Rework and upstream voltage regulator and TWL6030 code
  • Improve OMAP4 Framebuffer Driver
  • EFI GPT Partition table parsing
  • EXT2 file system driver
  • File System to Block interface adapter for Genode (for doing loop mounts)
  • TWL6040 Sound Codec support
  • Virtual SDHCI driver for L4Linux (for prototyping wifi)
  • Ressurect and fix the MUSB OTG driver for DDE_LINUX
  • Nook HD+ Touchscreen support
  • Refactor and upstream Google Nexus touchscreen
  • Multitouch support in Genode and L4Android
  • GPIO Buttons driver
  • Battery drivers
  • Charging driver
  • HSI Serial for OMAP4 (for Nexus modem)
  • PWM and backlight support for OMAP4
  • Sensors (Accelerometer, Gyroscope, Light)
  • UI for observing hardware state and controlling drivers
  • Basic power management
  • Native Genode linux port (without l4linux and Fiasco.OC). Besides dropping the huge messy pile of L4 support code from linux, this will allow to break the dependency on Fiasco.OC and switch to the native port (base-hw)
;T; I"G# Rationale # So, why the Nook HD+? While I have alrealy ported Genode to the Samsung Galaxy Nexus phone for the FOSDEM 2013 demo session, I decided to give another device a try for the following reasons: * As a tablet, it has much less hardware (at least, no phone) to support in order to be a daily driver * Some peripherals and hardware setup varies between it and the Nexus, so it may help exposing new bugs or hardcodery * It has the microSD slot connected to OMAP4 mmc0 with standard voltage setup (the VMODE bit). This is extremely useful because it allows to directly use the Genode MMC driver and it is easy to setup a MBR/VFAT filesystem on the microSD. Galaxy Nexus, on the contrary, has no external memory card slot, and to access the internal memory, it is necessary to implement a small change in the MMC driver and implement the EFI GPT partition parser * It has a Full HD display, and I have passion for hi-res screens. Besides, hi-res is a way to stress-test memory subsystem and framebuffer performance * Because I can # U-boot # Booting custom software on a commercial device is usually connected with some obstacles, like breaking the chain of trust. A typical approach (which I have utilized for many devices, including Acer Iconia A500, Samsung Galaxy S2 and Samsung Galaxy Nexus) is porting the u-boot bootloader to be an intermediate chainloader, flashed instead of the linux kernel. The B&N Nook HD+ does feature the signed kernel-based chain of trust for the internal EMMC memory, but it allows booting unsigned MLO, xloader and u-boot from the external microSD card. That is to say, there already exists the u-boot port, but to make it boot Genode, numerous changes were needed. First, I've obtained the android cwm recovery image for the sd card from the B&N Nook HD+ forum on xda-developers.com [credits go to the forum members verygreen and fat-tire]. After writing the image to the SD card and fixing partition layout in fdisk, I ended up with a VFAT partition containing the MLO, u-boot.bin and uImage. The MLO is the header file for the omap4 CPU which combines the memory initialization table with the x-loader bootloader. The u-boot.bin is the almost vanilla B&N u-boot which initializes the display and boots the uImage [which in the case of sd booting is also u-boot]. We'll be replacing the uImage with the customized u-boot. You can obtain the source code for my u-boot from https://github.com/astarasikov/uboot-bn-nook-hd-fastboot and below is the list of problems I've solved: * Removing the [unneeded for us] emmc and sd boot options. * Enabling fastboot. The bootloader listens on usb for the fastboot connection. "fastboot continue" allows to boot the "kernel" and "ramdisk" files from the sd card * Fixed display initialization. Turns out, the code in the uImage was broken, and did not reinit the display properly. The reasons were that it lacked one power GPIO (which would cause it to never come up after reset on some hardware revisions, my tablet being one of the unlucky ones), and the typo in one of the frame sync borders (which caused all font symbols to be one pixel tall). The display initialization code was scattered around 4 files, contained hardcoded definitions for another board. The framebuffer initialization was done in the MMC driver (sic!). * Fixed booting "ANDROID!" boot images over fastboot with the "booti" command. The code contained many incorrect assumptions about the image layout. * Moved the u-boot base in RAM and increased the fastboot buffer to allow downloading huge images (up to 496M). This allows me to boot Genode images with the built-in ramdisk with the root file system while I've not completed the GPT support * Enabled the framebuffer console for debugging # Genode # I had to do some changes to make Genode run. I'll briefly discuss some notable items. ## Fiasco.OC cross-compiling ## Recently, Genode crew have updated to the latest revision of the Fiasco.OC microkernel and it seems to contain some hardcoded cross-compiler name for ARM. I was reluctant to either fix it or download the 'proper' compiler (especially knowing that the one from the Genode toolchain does work for omap4). So, here is what I've done: * Made a new directory and added it to the PATH variable (append "export PATH=/path/to/that/very/dir/:$PATH" to your .bashrc if you have no slightest idea what I'm talking about) * Made symbolic links for the fake "arm-linux" toolchain pointing to genode with "for i in `ls /usr/local/genode-gcc/bin/genode-arm*`;do ln -s $i ${i//*genode-arm/arm-linux} ;done" ## Increasing nitpicker memory quota. ## Currently nitpicker [window manager providing virtual framebuffers] is hardcoded for some 1024x768 screens (I believe because no one, even at genode, seriously considers using Genode as a daily driver today), so we need to fix the memory limit constant in the following way:
-- a/os/include/nitpicker_session/connection.h
++ b/os/include/nitpicker_session/connection.h
@@ -43,8 +43,8 @@ namespace Nitpicker {
                                char argbuf[ARGBUF_SIZE];
                                argbuf[0] = 0;



## Adding LCD support to omap4 framebuffer ## Currently, omap4 framebuffer only supports the TV interface for HDMI. To make it reset and configure the LCD interface (which is used in smartphones and tablets), we need to add some register definitions [and fix the incorrect definition of the base address register while we're at it] to the code according to the omap4 DSS subsystem manual.
diff --git a/os/src/drivers/framebuffer/omap4/dispc.h b/os/src/drivers/framebuffer/omap4/dispc.h
index 23f80df..ea9f602 100644
-- a/os/src/drivers/framebuffer/omap4/dispc.h
++ b/os/src/drivers/framebuffer/omap4/dispc.h
@@ -18,8 +18,14 @@ struct Dispc : Genode::Mmio
         */
        struct Control1 : Register<0x40, 32>
        {

                struct Tv_enable : Bitfield<1, 1> { };
 





                struct Go_tv : Bitfield<6, 1>
                {
                        enum { HW_UPDATE_DONE    = 0x0,   /* set by HW after updating */
@@ -46,11 +52,17 @@ struct Dispc : Genode::Mmio
                struct Width  : Bitfield<0, 11>  { };
                struct Height : Bitfield<16, 11> { };
        };





 
        /**
         * Configures base address of the graphics buffer
         */



 
        /**
         * Configures the size of the graphics window
diff --git a/os/src/drivers/framebuffer/omap4/driver.h b/os/src/drivers/framebuffer/omap4/driver.h
index d754a97..53517a3 100644


@@ -203,6 +203,7 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        }
        _dispc.write<Dispc::Gfx_attributes::Format>(pixel_format);

        _dispc.write<Dispc::Gfx_ba1>(phys_base);
 
        _dispc.write<Dispc::Gfx_size::Sizex>(width(mode) - 1);

## Hacking in Nook HD+ display support. ## I wanted to make the display work in a quick and dirty way, so I've commented out the HDMI init code and replaced with a simple code that reconfigured the framebuffer address for the LCD (we piggyback on the u-boot to initialize the screen). Remember, kids, never ever think of doing this in production. I am deeply ashamed of havind done that. Either way, I'll show you the code, and the framebuffer driver badly wants some changes: * Adding proper LCD initailization * Configurable resolution via the config * Support for DSI/DPI interface initialization and custom panel drivers * Rotation and HW blitting * Ok, enough talk, here's the patch
diff --git a/os/src/drivers/framebuffer/omap4/driver.h b/os/src/drivers/framebuffer/omap4/driver.h
index 53517a3..9287cdc 100644
-- a/os/src/drivers/framebuffer/omap4/driver.h
++ b/os/src/drivers/framebuffer/omap4/driver.h
@@ -76,6 +76,7 @@ class Framebuffer::Driver
 
                static size_t width(Mode mode)
                {

                        switch (mode) {
                        case MODE_1024_768: return 1024;
                        }
@@ -84,6 +85,7 @@ class Framebuffer::Driver
 
                static size_t height(Mode mode)
                {

                        switch (mode) {
                        case MODE_1024_768: return 768;
                        }
@@ -117,12 +119,17 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
                                Framebuffer::addr_t         phys_base)
 {
        /* enable display core clock and set divider to 1 */

        _dispc.write<Dispc::Divisor::Lcd>(1);
        _dispc.write<Dispc::Divisor::Enable>(1);



 
        /* set load mode */
        _dispc.write<Dispc::Config1::Load_mode>(Dispc::Config1::Load_mode::DATA_EVERY_FRAME);
 

        _hdmi.write<Hdmi::Video_cfg::Start>(0);
 
        if (!_hdmi.issue_pwr_pll_command(Hdmi::Pwr_ctrl::ALL_OFF, _delayer)) {
@@ -196,6 +203,10 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        _dispc.write<Dispc::Size_tv::Height>(height(mode) - 1);
 
        _hdmi.write<Hdmi::Video_cfg::Start>(1);




 
        Dispc::Gfx_attributes::access_t pixel_format = 0;
        switch (format) {
@@ -212,6 +223,7 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        _dispc.write<Dispc::Global_buffer>(0x6d2240);
        _dispc.write<Dispc::Gfx_attributes::Enable>(1);
 

        _dispc.write<Dispc::Gfx_attributes::Channelout>(Dispc::Gfx_attributes::Channelout::TV);
        _dispc.write<Dispc::Gfx_attributes::Channelout2>(Dispc::Gfx_attributes::Channelout2::PRIMARY_LCD);
 
@@ -223,6 +235,9 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
                PERR("Go_tv timed out");
                return false;
        }



 
        return true;
 }
# Configuration file # Genode is configured via the XML configuration file. Here are some notes We're using the dde_kit usb_drv driver to provide stubs for networking and input drivers The nic_bridge proxifies the networking for two l4linux instances nitpicker and nit_fb are used to split the display into virtual framebuffers both nic_bridge and nit_fb are using the Genode concepts of the service interfaces and service routing. We're configuring the services in such a way that they're using the specific service if needed, and rely on the parent to provide the default service if we dont' care. For example, take a look at how nic_bridge is configured. The usb_drv features the "provides" section that declares which interfaces the service is allowed to provide. These may be used in the "route" section of the client services. By default, Genode features a deny-all policy, so if you don't configure something, you have no access to it. usb_drv has some memory leak (or had back in winter and I was lazy to look into it) so I've increased the RAM quota and hoped it would survive. It did. ~~~ ~~~ # Compiling and running # So, how about trying it out yourself? Install the Genode toolchain (consult the Genode website and sourceforge project) and create the symlinks as explained above. ## Get the u-boot source code ## ~~~ git clone git://github.com/astarasikov/uboot-bn-nook-hd-fastboot.git ~~~ ## Compile U-boot. ## I recommend using the codesourcery 2010q1-188 toolchain (because not all toolchains produce working code) ~~~ export PATH=/path/to/codesourcery/toolchain/bin:$PATH export ARCH=arm export CROSS_COMPILE=arm-none-eabi- U_BOARD=bn_ovation make clean make distclean make ${U_BOARD}_config make -j8 ./tools/mkimage -A arm -O linux -T kernel -C none -a 0x88000000 -e 0x88000000 -n foo -d u-boot.bin uImage ~~~ ## Get the genode framework source code ## ~~~ git clone git://github.com/astarasikov/genode.git git checkout nook_staging ~~~ Now, for each directory in the genode tree (base-foc, and non-base directories), go to them and execute "make prepare" to download the required libraries. Well, libports is heavily broken and many packages (openssl, zlib, any more?) fail to download. You can skip libports and qt4 for now. ## Prepare the build directory ## ~~~ ./tool/create_builddir foc_panda BUILD_DIR=/my/build/dir ~~~ ## Edit the /my/build/dir/etc/build.conf ## Uncomment the "REPOSITORIES += " entries to allow building l4linux and nitpicker Add the "MAKE += -j8" to the file to build in parallel utilizing all CPU cores. Add "SPECS += uboot" to the /my/build/dir/etc/specs.conf to force creating the raw image.bin.gz binary. ## Compile the Genode framework ## ~~~ cd /my/build/dir make run/nookhdp_l4linux ~~~ ## Actually running the image ## Now, you may wonder how to run the image. The tablet must be in the fastboot mode. Genode expects itself to be loaded at 0x81000000, and the u-boot does make a stupid assumption that linux kernel must be shifted 0x8000 bytes (i.e., 2 pages) from the base address. It should be fixed eventually, but for now, we're manually substracting the offset from the boot address ~~~ gunzip var/run/nookhdp_l4linux/image.bin.gz fastboot -b 0x80ff8000 boot var/run/nookhdp_l4linux/image.bin ~~~ # Results # Here is a picture of the Genode running. You can see the screen split into four parts with the help of the Nitpicker window manager. Each screen chunk is a virtual framebuffer provided by the Nit_fb service. Genode is running the Launchpad server (top right corner), the LOG written to the framebuffer (bottom left) and two instances of L4Linux. ![Genode on Nook HD+ Photo](http://1.bp.blogspot.com/-dVb27vINvL4/UY3TleeUTtI/AAAAAAAAB00/0PYnc7E4Aw8/s640/DSC01196.JPG) So, now it does not do much useful work, but remember it was an overnight proof of concept hacked together with the sole purpose of demonstrating the capabilities of Genode Framework, and this tutorial is basically a collection of anti-patterns. # Future plans # * Since I want to have a fully-functional port on both the Nook HD+ and Samsung Galaxy Nexus, here are some areas of interest for me and anyone who would like to contribute * Upstream OMAP4 and I.MX53 I2C drivers (we at Ksys Labs have written them almost a year ago and they're working fine, but had no time to suggest them to Genode Labs) * Upstream GPIOMUX interface for OMAP4 * Rework and upstream voltage regulator and TWL6030 code * Improve OMAP4 Framebuffer Driver * EFI GPT Partition table parsing * EXT2 file system driver * File System to Block interface adapter for Genode (for doing loop mounts) * TWL6040 Sound Codec support * Virtual SDHCI driver for L4Linux (for prototyping wifi) * Ressurect and fix the MUSB OTG driver for DDE_LINUX * Nook HD+ Touchscreen support * Refactor and upstream Google Nexus touchscreen * Multitouch support in Genode and L4Android * GPIO Buttons driver * Battery drivers * Charging driver * HSI Serial for OMAP4 (for Nexus modem) * PWM and backlight support for OMAP4 * Sensors (Accelerometer, Gyroscope, Light) * UI for observing hardware state and controlling drivers * Basic power management * Native Genode linux port (without l4linux and Fiasco.OC). Besides dropping the huge messy pile of L4 support code from linux, this will allow to break the dependency on Fiasco.OC and switch to the native port (base-hw);T; I",N

Rationale

So, why the Nook HD+? While I have alrealy ported Genode to the Samsung Galaxy Nexus phone for the FOSDEM 2013 demo session, I decided to give another device a try for the following reasons:

U-boot

Booting custom software on a commercial device is usually connected with some obstacles, like breaking the chain of trust. A typical approach (which I have utilized for many devices, including Acer Iconia A500, Samsung Galaxy S2 and Samsung Galaxy Nexus) is porting the u-boot bootloader to be an intermediate chainloader, flashed instead of the linux kernel.

The B&N Nook HD+ does feature the signed kernel-based chain of trust for the internal EMMC memory, but it allows booting unsigned MLO, xloader and u-boot from the external microSD card. That is to say, there already exists the u-boot port, but to make it boot Genode, numerous changes were needed.

First, I’ve obtained the android cwm recovery image for the sd card from the B&N Nook HD+ forum on xda-developers.com [credits go to the forum members verygreen and fat-tire]. After writing the image to the SD card and fixing partition layout in fdisk, I ended up with a VFAT partition containing the MLO, u-boot.bin and uImage. The MLO is the header file for the omap4 CPU which combines the memory initialization table with the x-loader bootloader. The u-boot.bin is the almost vanilla B&N u-boot which initializes the display and boots the uImage [which in the case of sd booting is also u-boot]. We’ll be replacing the uImage with the customized u-boot.

You can obtain the source code for my u-boot from https://github.com/astarasikov/uboot-bn-nook-hd-fastboot and below is the list of problems I’ve solved:

Genode

I had to do some changes to make Genode run. I’ll briefly discuss some notable items.

Fiasco.OC cross-compiling

Recently, Genode crew have updated to the latest revision of the Fiasco.OC microkernel and it seems to contain some hardcoded cross-compiler name for ARM. I was reluctant to either fix it or download the ‘proper’ compiler (especially knowing that the one from the Genode toolchain does work for omap4).

So, here is what I’ve done:

Increasing nitpicker memory quota.

Currently nitpicker [window manager providing virtual framebuffers] is hardcoded for some 1024x768 screens (I believe because no one, even at genode, seriously considers using Genode as a daily driver today), so we need to fix the memory limit constant in the following way:

-- a/os/include/nitpicker_session/connection.h
++ b/os/include/nitpicker_session/connection.h
@@ -43,8 +43,8 @@ namespace Nitpicker {
                                char argbuf[ARGBUF_SIZE];
                                argbuf[0] = 0;



Adding LCD support to omap4 framebuffer

Currently, omap4 framebuffer only supports the TV interface for HDMI. To make it reset and configure the LCD interface (which is used in smartphones and tablets), we need to add some register definitions [and fix the incorrect definition of the base address register while we’re at it] to the code according to the omap4 DSS subsystem manual.

diff --git a/os/src/drivers/framebuffer/omap4/dispc.h b/os/src/drivers/framebuffer/omap4/dispc.h
index 23f80df..ea9f602 100644
-- a/os/src/drivers/framebuffer/omap4/dispc.h
++ b/os/src/drivers/framebuffer/omap4/dispc.h
@@ -18,8 +18,14 @@ struct Dispc : Genode::Mmio
         */
        struct Control1 : Register<0x40, 32>
        {

                struct Tv_enable : Bitfield<1, 1> { };
 





                struct Go_tv : Bitfield<6, 1>
                {
                        enum { HW_UPDATE_DONE    = 0x0,   /* set by HW after updating */
@@ -46,11 +52,17 @@ struct Dispc : Genode::Mmio
                struct Width  : Bitfield<0, 11>  { };
                struct Height : Bitfield<16, 11> { };
        };





 
        /**
         * Configures base address of the graphics buffer
         */



 
        /**
         * Configures the size of the graphics window
diff --git a/os/src/drivers/framebuffer/omap4/driver.h b/os/src/drivers/framebuffer/omap4/driver.h
index d754a97..53517a3 100644


@@ -203,6 +203,7 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        }
        _dispc.write<Dispc::Gfx_attributes::Format>(pixel_format);

        _dispc.write<Dispc::Gfx_ba1>(phys_base);
 
        _dispc.write<Dispc::Gfx_size::Sizex>(width(mode) - 1);

Hacking in Nook HD+ display support.

I wanted to make the display work in a quick and dirty way, so I’ve commented out the HDMI init code and replaced with a simple code that reconfigured the framebuffer address for the LCD (we piggyback on the u-boot to initialize the screen). Remember, kids, never ever think of doing this in production. I am deeply ashamed of havind done that. Either way, I’ll show you the code, and the framebuffer driver badly wants some changes:

diff --git a/os/src/drivers/framebuffer/omap4/driver.h b/os/src/drivers/framebuffer/omap4/driver.h
index 53517a3..9287cdc 100644
-- a/os/src/drivers/framebuffer/omap4/driver.h
++ b/os/src/drivers/framebuffer/omap4/driver.h
@@ -76,6 +76,7 @@ class Framebuffer::Driver
 
                static size_t width(Mode mode)
                {

                        switch (mode) {
                        case MODE_1024_768: return 1024;
                        }
@@ -84,6 +85,7 @@ class Framebuffer::Driver
 
                static size_t height(Mode mode)
                {

                        switch (mode) {
                        case MODE_1024_768: return 768;
                        }
@@ -117,12 +119,17 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
                                Framebuffer::addr_t         phys_base)
 {
        /* enable display core clock and set divider to 1 */

        _dispc.write<Dispc::Divisor::Lcd>(1);
        _dispc.write<Dispc::Divisor::Enable>(1);



 
        /* set load mode */
        _dispc.write<Dispc::Config1::Load_mode>(Dispc::Config1::Load_mode::DATA_EVERY_FRAME);
 

        _hdmi.write<Hdmi::Video_cfg::Start>(0);
 
        if (!_hdmi.issue_pwr_pll_command(Hdmi::Pwr_ctrl::ALL_OFF, _delayer)) {
@@ -196,6 +203,10 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        _dispc.write<Dispc::Size_tv::Height>(height(mode) - 1);
 
        _hdmi.write<Hdmi::Video_cfg::Start>(1);




 
        Dispc::Gfx_attributes::access_t pixel_format = 0;
        switch (format) {
@@ -212,6 +223,7 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
        _dispc.write<Dispc::Global_buffer>(0x6d2240);
        _dispc.write<Dispc::Gfx_attributes::Enable>(1);
 

        _dispc.write<Dispc::Gfx_attributes::Channelout>(Dispc::Gfx_attributes::Channelout::TV);
        _dispc.write<Dispc::Gfx_attributes::Channelout2>(Dispc::Gfx_attributes::Channelout2::PRIMARY_LCD);
 
@@ -223,6 +235,9 @@ bool Framebuffer::Driver::init(Framebuffer::Driver::Mode   mode,
                PERR("Go_tv timed out");
                return false;
        }



 
        return true;
 }

Configuration file

Genode is configured via the XML configuration file. Here are some notes We’re using the dde_kit usb_drv driver to provide stubs for networking and input drivers The nic_bridge proxifies the networking for two l4linux instances nitpicker and nit_fb are used to split the display into virtual framebuffers both nic_bridge and nit_fb are using the Genode concepts of the service interfaces and service routing. We’re configuring the services in such a way that they’re using the specific service if needed, and rely on the parent to provide the default service if we dont’ care. For example, take a look at how nic_bridge is configured. The usb_drv features the “provides” section that declares which interfaces the service is allowed to provide. These may be used in the “route” section of the client services. By default, Genode features a deny-all policy, so if you don’t configure something, you have no access to it. usb_drv has some memory leak (or had back in winter and I was lazy to look into it) so I’ve increased the RAM quota and hoped it would survive. It did.

 <start name="usb_drv">
  <resource name="RAM" quantum="40M"/>
  <provides>
   <service name="Input"/>
   <service name="Nic"/>
  </provides>
  <config>
   <hid/>
   <nic mac="2e:60:90:0c:4e:01" />
  </config>
 </start>

 <start name="nic_bridge">
  <resource name="RAM" quantum="2M"/>
  <provides><service name="Nic"/></provides>
  <route>
   <service name="Nic"> <child name="usb_drv"/> </service>
   <any-service> <parent/> <any-child/> </any-service>
  </route>
 </start>

Compiling and running

So, how about trying it out yourself?

Install the Genode toolchain (consult the Genode website and sourceforge project) and create the symlinks as explained above.

Get the u-boot source code

git clone git://github.com/astarasikov/uboot-bn-nook-hd-fastboot.git

Compile U-boot.

I recommend using the codesourcery 2010q1-188 toolchain (because not all toolchains produce working code)

export PATH=/path/to/codesourcery/toolchain/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-
U_BOARD=bn_ovation
make clean
make distclean
make ${U_BOARD}_config
make -j8 
./tools/mkimage -A arm -O linux -T kernel -C none -a 0x88000000 -e 0x88000000 -n foo -d u-boot.bin uImage

Get the genode framework source code

git clone git://github.com/astarasikov/genode.git
git checkout nook_staging

Now, for each directory in the genode tree (base-foc, and non-base directories), go to them and execute “make prepare” to download the required libraries. Well, libports is heavily broken and many packages (openssl, zlib, any more?) fail to download. You can skip libports and qt4 for now.

Prepare the build directory

./tool/create_builddir foc_panda BUILD_DIR=/my/build/dir

Edit the /my/build/dir/etc/build.conf

Uncomment the “REPOSITORIES += “ entries to allow building l4linux and nitpicker

Add the “MAKE += -j8” to the file to build in parallel utilizing all CPU cores.

Add “SPECS += uboot” to the /my/build/dir/etc/specs.conf to force creating the raw image.bin.gz binary.

Compile the Genode framework

cd /my/build/dir
make run/nookhdp_l4linux

Actually running the image

Now, you may wonder how to run the image. The tablet must be in the fastboot mode. Genode expects itself to be loaded at 0x81000000, and the u-boot does make a stupid assumption that linux kernel must be shifted 0x8000 bytes (i.e., 2 pages) from the base address. It should be fixed eventually, but for now, we’re manually substracting the offset from the boot address

gunzip var/run/nookhdp_l4linux/image.bin.gz
fastboot -b 0x80ff8000 boot var/run/nookhdp_l4linux/image.bin

Results

Here is a picture of the Genode running. You can see the screen split into four parts with the help of the Nitpicker window manager. Each screen chunk is a virtual framebuffer provided by the Nit_fb service. Genode is running the Launchpad server (top right corner), the LOG written to the framebuffer (bottom left) and two instances of L4Linux.

Genode on Nook HD+ Photo

So, now it does not do much useful work, but remember it was an overnight proof of concept hacked together with the sole purpose of demonstrating the capabilities of Genode Framework, and this tutorial is basically a collection of anti-patterns.

Future plans

;T; @WI"-/tutorials/porting_genode_to_cubieboard/;T{;{ ;I"^ Портирование Genode OS Framework на новую аппаратную платформу

Портирование Genode OS Framework на новую аппаратную платформу

Данная статья рассказывает о Genode OS Framework и процессе портирования его на новую аппаратную платформу на базе процессора архитектуры ARM. В качестве ядра для Genode используется Fiasco.OC.

text

И так, что такое Genode OS Framework? Это фреймворк для построения операционной системы на базе микроядра. Genode предоставляет единый API, позволяющий использовать различные микроядра для построения ОС. На данный момент поддерживаются следующие микроядра: Codezero, Fiasco, Fiasco.OC, Nova, OKL4, Pistachio. Также поддерживается работа на ядре Linux. Кроме этого, возможен запуск без использования сторонних ядер (base-hw) на некоторых платформах на базе архитектуры ARM.
Эти ядра поддерживают разные архитектуры процессоров и могут использовать некоторое аппаратные возможности. Например, ядро Fiasco.OC может работать на большом количестве архитектур, таких как: x86, amd64, ARM (доступны и другие архитектуры, но они не поддерживаются в Genode на данный момент), а ядро Nova является микрогипервизором для архитектуры x86 и позволяет использовать аппаратную виртуализацию. Благодаря использованию фреймворка Genode мы можем без изменений исходного кода компилировать приложение для использования на любом из поддерживаемых ядер. Более подробную информацию о Genode можно получить из документации, размещенной на сайте проекта, а также из материалов, прочитаных Norman Feske для “Летней школы системного программирования Ksys labs

В настоящее время Genode+FIasco.OC для архитектуры ARM поддерживает следующие платформы: Realview PBXA9, Versatile Express A9X4, Pandaboard (TI OMAP4), Freescale iMX53, Arndale (Samsung Exynos 5).
В качестве платформы для портирования был использован мини-ПК Cubieboard на базе SoC Allwinner A10. Эта платформа интересна по ряду причин:
- не слишком устаревшая архитектура Cortex-A8;
- наличие исходного кода загрузчика U-Boot, ядра Linux и ”утекшей” в сеть документации в виде руководства пользователя;
- большой набор переферии (SATA, HDMI, и др.);
- наличие большого количества недорогих “hackable” устройств на этом чипе (Cubieboard, Mele A1000/A2000, и другие).

Рассмотрим этот SoC более подробно.

text
Рисунок 1 - Функциональная диаграмма

CPU: ARM Cortex-A8 с частотой до 1Ghz с поддержкой NEON, VFPv3, Trustzone
GPU: Mali 400 MP с поддержкой Open GL ES 2.0
VPU: CedarX с поддержкой FullHD видео.
Переферия: 4xUSB Host, USB OTG, 4xSD/MMC, 8xUART, 4xSPI, 3xI2C, GPIO, SATA, HDMI, LCD-интерфейс и другие

Ядро Fiasco.OC поддерживает архитектуру процессоров Cortex-A8. Это значит, что для портирования его на новую платформу нужно только добавить поддержку платформы, так называемый Board Support PAckage ([BSP] (http://ru.wikipedia.org/wiki/Board_Support_Package)). Исходный код BSP расположен в директории kernel/fiasco/src/kern/arm/bsp.
В состав BSP для архитектуры ARM в Fiasco.OC входит:
- драйвер контроллера прерываний;
- драйвер таймера;
- драйвер UART;
- реализация сброса.
Кроме этого, в состав BSP входит конфигурация распределения памяти.
Память в A10, согласно руководству пользователя, распределяется следующим образом:

text

Для того, чтобы ОС могла использовать память, она должна знать физические адреса и размер необходимых регионов памяти. Эти параметры задаются в классе Mem_layout, файл mem_layout-arm-sun4i.cpp:

EXTENSION class Mem_layout
{
public:
  enum Virt_layout_sun4i : Address {
    Timer_map_base       = Devices1_map_base + 0x020C00,
    Intc_map_base        = Devices1_map_base + 0x020400,
    Uart_base            = Devices1_map_base + 0x028000,

    Watchdog_map_base    = Timer_map_base    + 0x90,
  };

  enum Phys_layout_sun4i : Address {
    Devices1_phys_base   = 0x01c00000,

    Sdram_phys_base      = 0x40000000,
    Flush_area_phys_base = 0xe0000000,
  };
};

Контроллер прерываний необходим для обработки событий от различных источников прерываний. Драйвер контроллера прерываний должен реализовать такие операции как: конфигурирование контроллера, маскирование прерываний, функцию обработки. Код драйвера в файле pic-arm-sun4i.cpp.

Таймер необходим для генерации событий,таких как: конец тайм-слота или таймаут IPC. В A10 имеется 6 таймеров. В качестве таймера для переодических прерываний используется таймер Timer0. Кроме таймеров общего назначения в состав SoC также входят Watchdog и RTC с будильником.
Для использования таймера в режиме системного он должен генерировать прерывание каждую 1 мс. Инициализация таймера и необходимые функции реализованы в файле timer-arm-sun4i.cpp.

Драйвер UART используется ядром для вывода отладочных сообщений и доступа к отладчику ядра JDB. В Fiasco.OC инициализация модуля UART отсутсвует, считается, что его уже настроил загрузчик, в нашем случае - U-Boot. Код драйвера UART находится в файлах uart-arm-sun4i.cpp и kernel/fiasco/src/lib/uart/uart_sun4i.cc.

Для выполнения полного сброса процессора применяется Watchdog таймера, назначением которого является сброс системы при зацикливании кода. Реализация находится в файле reset-arm-sun4i.cpp.

После выполнения этих действий мы получаем BSP для выбраного процессора.

Рассмотрим процесс загрузки Genode+Fiasco.OC на архитектуре ARM:

  1. При старте ROM-boot ищет загрузчик на SD-карте или загружается с NAND при отсутсвии SD-карты.
  2. U-Boot, выполняя стартовые скрипты, загружает образ Genode в виде ELF или u-boot-image.
  3. Загруженный модуль содержит в себе ядро Fiasco.OC и все остальные исполняемые файлы, такие как: sigma0, root task (в Genode это модуль core) и пользовательские программы.
  4. Первым стартует bootstrap, который выполняет часть операций неоходимых для старта ядра, такие как: — сканирование доступной памяти (выполняется не для всех архитектур, на ARM значение доступной памяти задается в конфигурации на платформу); — перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить); — и непосредственно запуск ядра.
  5. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task.
  6. Начинает выполняться модуль core (являющийся root task), который инициализирует сервисы Genode и позволяет запускать необходимые нам приложения, используя конфигурационный файл.

Соответсвенно для запуска bootstrap на Cubieboard он должен знать об этой платформе, поэтому добавляем нужную конфигурацию l4/mk/platforms/cubieboard.conf и l4/pkg/bootstrap/server/src/platform/sun4i.cc. Кроме этого необходимо реализовать драйвер UART для вывода информации о загрузке в консоль.

Заключительный этап портирования — добавление необходимых файлов конфигурации в сборочную систему Genode. Изменения можно посмотреть в соответвующем коммите в репозитории. Хорошее описание системы сборки было рассмотрено в лекции “Genode OS Framework Programming Environment”.

Исходные коды находятся на Github https://github.com/Ksys-labs/genode в ветке tutorials. Модифицированная версия Fiasco.OC в репозитории https://github.com/Ksys-labs/foc в ветке r47-sun4i, эти исходные коды уже содержат необходимые патчи и скачиваются с помощью системы сборки Genode.

Для сборки необходимо клонировать исходный код:

git clone git://github.com/Ksys-labs/genode.git
git checkout tutorials
cd genode

Собрать тулчейн для ARM:

./tools/tool_chain arm

И скачать ядро Fiasco.OC:

make prepare -C base-foc

Теперь все готово для запуска.

  1. Создаем директорию для сборки, используя команду:
./tools/create_builddir foc_cubieboard BUILD_DIR=_build.foc_cubieboard
cd _build.foc_cubieboard
  1. Добавляем репозиторий hello_tutorial для сбоки простейшего сценария, которому не требуются отсутсвующие пока драйверы.
echo 'REPOSITORIES += $(GENODE_DIR)/hello_tutorial' >> etc/build.conf
  1. Включаем генерацию файла u-boot-image
echo 'SPECS += uboot' >> etc/spec.conf
  1. Cобираем образ
make run/hello

После непродолжительной сборки получаем образ в виде: ELF (hello.elf) и u-boot-image (uImage) в директории var/run/hello. После запуска на устройстве, в подключенной консоле, можно увидеть процесс загрузки и выполняющиеся приложения из hello tutorial:

L4 Bootstrapper
  Build: #4 Чт. апр. 18 22:48:37 MSK 2013, 4.7.2
  Scanning up to 1024 MB RAM
  Memory size is 1024MB (40000000 - 80000000)
  RAM: 0000000040000000 - 000000007fffffff: 1048576kB
  Total RAM: 1024MB
  mod07: 4117e000-411b8e3c: genode/timer
  mod06: 41148000-4117ddc0: genode/hello_server
  mod05: 4111c000-41147c28: genode/hello_client
  mod04: 410d6000-4111b738: genode/init
  mod03: 410d5000-410d51a4: genode/config
  mod02: 4106e000-410d431c: genode/core
  mod01: 41064000-4106d374: sigma0
  mod00: 41015000-41063d20: /home/vanner/projects/genode-iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
  Moving up to 8 modules behind 41100000
  moving module 00 { 41015000-41063d1f } -> { 412a4000-412f2d1f } [322848]
  moving module 01 { 41064000-4106d373 } -> { 412f3000-412fc373 } [37748]
  moving module 02 { 4106e000-410d431b } -> { 412fd000-4136331b } [418588]
  moving module 03 { 410d5000-410d51a3 } -> { 411b9000-411b91a3 } [420]
  moving module 04 { 410d6000-4111b737 } -> { 411ba000-411ff737 } [284472]
  moving module 05 { 4111c000-41147c27 } -> { 41100000-4112bc27 } [179240]
  moving module 06 { 41148000-4117ddbf } -> { 4112c000-41161dbf } [220608]
  moving module 07 { 4117e000-411b8e3b } -> { 41162000-4119ce3b } [241212]
  moving module 03 { 411b9000-411b91a3 } -> { 4119d000-4119d1a3 } [420]
  moving module 04 { 411ba000-411ff737 } -> { 4119e000-411e3737 } [284472]
  Scanning /home/vanner/projects/genode-iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco -serial_esc 
  Scanning sigma0
  Scanning genode/core
  Relocated mbi to [0x4100e000-0x4100e19c]
  Loading -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
  Loading sigma0
  Loading genode/core
  find kernel info page...
  found kernel info page at 0x40002000
Regions of list 'regions'
    [ 40001000,  400019ff] {      a00} Kern   -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
    [ 40002000,  40060fff] {    5f000} Kern   -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
    [ 40090000,  4009673b] {     673c} Sigma0 sigma0
    [ 40098000,  4009e17b] {     617c} Sigma0 sigma0
    [ 40100000,  4024743f] {   147440} Root   genode/core
    [ 41000000,  410143f3] {    143f4} Boot   bootstrap
    [ 4100e000,  4100e299] {      29a} Root   Multiboot info
    [ 41100000,  411e3737] {    e3738} Root   Module
  API Version: (87) experimental
  Sigma0 config    ip:40090100 sp:41013d24
  Roottask config  ip:4014af84 sp:00000000
  Starting kernel -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco at 40001198
Hello from Startup::stage2
Boot_alloc: size=0x180
Boot_alloc: allocated extra memory block @0xf13e1000 (size=400)
Boot_alloc: @ 0xf13e1000
Boot_alloc: remaining free block @ 0xf13e1180 (size=280)
Cache config: ON
ID_PFR[01]:  00001131 00000011 ID_[DA]FR0: 00000400 00000000
ID_MMFR[04]: 01100003 20000000 01202000 00000211
FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 3, v: c, i: 41, t: hard, p: dbl/sngl
Startup::stage2 finished
SERIAL ESC: allocated IRQ 1 for serial uart
Not using serial hack in slow timer handler.
Welcome to Fiasco.OC (arm)!
L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden
Rev: 8991035 compiled with gcc 4.7.2 for sun4i    []
Build: #3 Чт. апр. 18 22:48:33 MSK 2013

Calibrating timer loop... done.
SIGMA0: Hello!
  KIP @ 40002000
  allocated 4KB for maintenance structures
SIGMA0: Dump of all resource maps
RAM:------------------------
[0:40000000;40000fff]
[0:40061000;4008ffff]
[0:40097000;40097fff]
[0:4009f000;400fffff]
[4:40100000;40247fff]
[0:40248000;4100dfff]
[4:4100e000;4100efff]
[0:4100f000;410fffff]
[4:41100000;411e3fff]
[0:411e4000;7effffff]
IOMEM:----------------------
[0:0;3fffffff]
[0:80000000;ffffffff]

KIP @ 40002000
    magic: 4be6344c
  version: 87014444
         sigma0  esp: 41013d24  eip: 40090100
         sigma1  esp: 00000000  eip: 00000000
           root  esp: 00000000  eip: 4014af84
MBI @ 4100e000
 mod[3] [4119d000,4119d1a4) config
 mod[4] [4119e000,411e3738) init
 mod[5] [41100000,4112bc28) hello_client
 mod[6] [4112c000,41161dc0) hello_server
 mod[7] [41162000,4119ce3c) timer
:ram_alloc: Allocator 40230784 dump:
 Block: [50000000,5000001c) size=0000001c avail=00000000 max_avail=00000000
 Block: [5000001c,50000038) size=0000001c avail=00000000 max_avail=00000000
 Block: [50000038,50000054) size=0000001c avail=00000000 max_avail=00000000
 Block: [50000054,50000070) size=0000001c avail=00000000 max_avail=2effff58
 Block: [50000070,5000008c) size=0000001c avail=00000000 max_avail=00000000
 Block: [5000008c,500000a8) size=0000001c avail=00000000 max_avail=2effff58
 Block: [500000a8,7f000000) size=2effff58 avail=2effff58 max_avail=2effff58
 => mem_size=788529152 (752 MB) / mem_avail=788528984 (751 MB)
:region_alloc: Allocator 402318f4 dump:
 Block: [00001000,40000000) size=3ffff000 avail=3ffff000 max_avail=3ffff000
 Block: [7f000000,bfff0000) size=40ff0000 avail=40ff0000 max_avail=40ff0000
 Block: [bfff1000,c0000000) size=0000f000 avail=0000f000 max_avail=0000f000
 => mem_size=2164252672 (2063 MB) / mem_avail=2164252672 (2063 MB)
:io_mem: Allocator 40230be0 dump:
 Block: [00000000,40000000) size=40000000 avail=40000000 max_avail=40000000
 Block: [40001000,40002000) size=00001000 avail=00001000 max_avail=40000000
 Block: [40003000,40061000) size=0005e000 avail=0005e000 max_avail=0005e000
 Block: [40090000,40097000) size=00007000 avail=00007000 max_avail=0005e000
 Block: [40098000,4009f000) size=00007000 avail=00007000 max_avail=80ffffff
 Block: [7f000000,ffffffff) size=80ffffff avail=80ffffff max_avail=80ffffff
 => mem_size=3238449151 (3088 MB) / mem_avail=3238449151 (3088 MB)
:io_port: Allocator 4023103c dump:
:irq: Allocator 40231498 dump:
 Block: [00000000,00000100) size=00000100 avail=00000100 max_avail=00000100
 => mem_size=256 (0 MB) / mem_avail=256 (0 MB)
:rom_fs: Rom_fs 402321a8 dump:
 Rom: [4119e000,411e3738) init
 Rom: [41100000,4112bc28) hello_client
 Rom: [4119d000,4119d1a4) config
 Rom: [4112c000,41161dc0) hello_server
 Rom: [40002000,40003000) l4v2_kip
 Rom: [40002000,40003000) kip
 Rom: [41162000,4119ce3c) timer
:core ranges: Allocator 40233f08 dump:
 Block: [40100000,40248000) size=00148000 avail=00148000 max_avail=00148000
 Block: [41100000,411e4000) size=000e4000 avail=000e4000 max_avail=2f000000
 Block: [50000000,7f000000) size=2f000000 avail=2f000000 max_avail=2f000000
 => mem_size=790806528 (754 MB) / mem_avail=790806528 (754 MB)
int main(): --- create local services ---
int main(): --- start init ---
int main(): transferred 751 MB to init
int main(): --- init created, waiting for exit condition ---
[init] Could not open file "ld.lib.so"
[init -> hello_server] Hello::Root_component::Root_component(Genode::Rpc_entrypoint*, Genode::Allocator*): Creating root component.
[init -> hello_server] virtual Hello::Session_component* Hello::Root_component::_create_session(const char*): creating hello session.
[init -> hello_client] virtual void Hello::Session_client::say_hello(): Saying Hello.
[init -> hello_server] virtual void Hello::Session_component::say_hello(): I am here... Hello.
[init -> hello_client] int main(): Added 2 + 5 = 7
[init -> hello_client] virtual void Hello::Session_client::say_hello(): Saying Hello.
[init -> hello_server] virtual void Hello::Session_component::say_hello(): I am here... Hello.
[init -> hello_client] int main(): Added 2 + 5 = 7
...
;T; I"P### Портирование Genode OS Framework на новую аппаратную платформу Данная статья рассказывает о [Genode OS Framework](http://genode.org/) и процессе портирования его на новую аппаратную платформу на базе процессора архитектуры ARM. В качестве ядра для Genode используется [Fiasco.OC](http://os.inf.tu-dresden.de/fiasco/). ![text](/upload/cubieboard.png) И так, что такое Genode OS Framework? Это фреймворк для построения операционной системы на базе микроядра. Genode предоставляет единый API, позволяющий использовать различные микроядра для построения ОС. На данный момент поддерживаются следующие микроядра: Codezero, Fiasco, Fiasco.OC, Nova, OKL4, Pistachio. Также поддерживается работа на ядре Linux. Кроме этого, возможен запуск без использования сторонних ядер (base-hw) на некоторых платформах на базе архитектуры ARM.
Эти ядра поддерживают разные архитектуры процессоров и могут использовать некоторое аппаратные возможности. Например, ядро Fiasco.OC может работать на большом количестве архитектур, таких как: x86, amd64, ARM (доступны и другие архитектуры, но они не поддерживаются в Genode на данный момент), а ядро Nova является микрогипервизором для архитектуры x86 и позволяет использовать аппаратную виртуализацию. Благодаря использованию фреймворка Genode мы можем без изменений исходного кода компилировать приложение для использования на любом из поддерживаемых ядер. Более подробную информацию о Genode можно получить из документации, размещенной на сайте проекта, а также из материалов, прочитаных Norman Feske для “[Летней школы системного программирования Ksys labs](http://ksyslabs.ru/index.php?nn=36)” В настоящее время Genode+FIasco.OC для архитектуры ARM поддерживает следующие платформы: Realview PBXA9, Versatile Express A9X4, Pandaboard (TI OMAP4), Freescale iMX53, Arndale (Samsung Exynos 5).
В качестве платформы для портирования был использован мини-ПК [Cubieboard](http://cubieboard.org/) на базе SoC [Allwinner A10](http://linux-sunxi.org/A10). Эта платформа интересна по ряду причин:
- не слишком устаревшая архитектура Cortex-A8;
- наличие исходного кода загрузчика U-Boot, ядра Linux и ”утекшей” в сеть документации в виде руководства пользователя;
- большой набор переферии (SATA, HDMI, и др.);
- наличие большого количества недорогих “hackable” устройств на этом чипе (Cubieboard, Mele A1000/A2000, и другие). Рассмотрим этот SoC более подробно. ![text](/upload/a10_diagram.png)
Рисунок 1 - Функциональная диаграмма CPU: ARM Cortex-A8 с частотой до 1Ghz с поддержкой NEON, VFPv3, Trustzone
GPU: Mali 400 MP с поддержкой Open GL ES 2.0
VPU: CedarX с поддержкой FullHD видео.
Переферия: 4xUSB Host, USB OTG, 4xSD/MMC, 8xUART, 4xSPI, 3xI2C, GPIO, SATA, HDMI, LCD-интерфейс и другие
Ядро Fiasco.OC поддерживает архитектуру процессоров Cortex-A8. Это значит, что для портирования его на новую платформу нужно только добавить поддержку платформы, так называемый Board Support PAckage ([BSP] (http://ru.wikipedia.org/wiki/Board_Support_Package)). Исходный код BSP расположен в директории kernel/fiasco/src/kern/arm/bsp.
В состав BSP для архитектуры ARM в Fiasco.OC входит:
- драйвер контроллера прерываний;
- драйвер таймера;
- драйвер UART;
- реализация сброса.
Кроме этого, в состав BSP входит конфигурация распределения памяти.
Память в A10, согласно руководству пользователя, распределяется следующим образом: ![text](/upload/a10_mem.png)
Для того, чтобы ОС могла использовать память, она должна знать физические адреса и размер необходимых регионов памяти. Эти параметры задаются в классе Mem_layout, файл mem_layout-arm-sun4i.cpp: ~~~ EXTENSION class Mem_layout { public: enum Virt_layout_sun4i : Address { Timer_map_base = Devices1_map_base + 0x020C00, Intc_map_base = Devices1_map_base + 0x020400, Uart_base = Devices1_map_base + 0x028000, Watchdog_map_base = Timer_map_base + 0x90, }; enum Phys_layout_sun4i : Address { Devices1_phys_base = 0x01c00000, Sdram_phys_base = 0x40000000, Flush_area_phys_base = 0xe0000000, }; }; ~~~ Контроллер прерываний необходим для обработки событий от различных источников прерываний. Драйвер контроллера прерываний должен реализовать такие операции как: конфигурирование контроллера, маскирование прерываний, функцию обработки. Код драйвера в файле pic-arm-sun4i.cpp. Таймер необходим для генерации событий,таких как: конец тайм-слота или таймаут IPC. В A10 имеется 6 таймеров. В качестве таймера для переодических прерываний используется таймер Timer0. Кроме таймеров общего назначения в состав SoC также входят Watchdog и RTC с будильником.
Для использования таймера в режиме системного он должен генерировать прерывание каждую 1 мс. Инициализация таймера и необходимые функции реализованы в файле timer-arm-sun4i.cpp. Драйвер UART используется ядром для вывода отладочных сообщений и доступа к отладчику ядра JDB. В Fiasco.OC инициализация модуля UART отсутсвует, считается, что его уже настроил загрузчик, в нашем случае - U-Boot. Код драйвера UART находится в файлах uart-arm-sun4i.cpp и kernel/fiasco/src/lib/uart/uart_sun4i.cc. Для выполнения полного сброса процессора применяется Watchdog таймера, назначением которого является сброс системы при зацикливании кода. Реализация находится в файле reset-arm-sun4i.cpp. После выполнения этих действий мы получаем BSP для выбраного процессора. Рассмотрим процесс загрузки Genode+Fiasco.OC на архитектуре ARM: 1. При старте ROM-boot ищет загрузчик на SD-карте или загружается с NAND при отсутсвии SD-карты. 2. U-Boot, выполняя стартовые скрипты, загружает образ Genode в виде ELF или u-boot-image. 3. Загруженный модуль содержит в себе ядро Fiasco.OC и все остальные исполняемые файлы, такие как: sigma0, root task (в Genode это модуль core) и пользовательские программы. 4. Первым стартует bootstrap, который выполняет часть операций неоходимых для старта ядра, такие как: — сканирование доступной памяти (выполняется не для всех архитектур, на ARM значение доступной памяти задается в конфигурации на платформу); — перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить); — и непосредственно запуск ядра. 7. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task. 8. Начинает выполняться модуль core (являющийся root task), который инициализирует сервисы Genode и позволяет запускать необходимые нам приложения, используя конфигурационный файл. Соответсвенно для запуска bootstrap на Cubieboard он должен знать об этой платформе, поэтому добавляем нужную конфигурацию l4/mk/platforms/cubieboard.conf и l4/pkg/bootstrap/server/src/platform/sun4i.cc. Кроме этого необходимо реализовать драйвер UART для вывода информации о загрузке в консоль. Заключительный этап портирования — добавление необходимых файлов конфигурации в сборочную систему Genode. Изменения можно посмотреть в соответвующем коммите в репозитории. Хорошее описание системы сборки было рассмотрено в лекции "Genode OS Framework Programming Environment". Исходные коды находятся на Github [https://github.com/Ksys-labs/genode](https://github.com/Ksys-labs/genode) в ветке **tutorials**. Модифицированная версия Fiasco.OC в репозитории [https://github.com/Ksys-labs/foc](https://github.com/Ksys-labs/foc) в ветке **r47-sun4i**, эти исходные коды уже содержат необходимые патчи и скачиваются с помощью системы сборки Genode. Для сборки необходимо клонировать исходный код: ~~~ git clone git://github.com/Ksys-labs/genode.git git checkout tutorials cd genode ~~~ Собрать тулчейн для ARM: ~~~ ./tools/tool_chain arm ~~~ И скачать ядро Fiasco.OC: ~~~ make prepare -C base-foc ~~~ Теперь все готово для запуска. 1. Создаем директорию для сборки, используя команду: ~~~ ./tools/create_builddir foc_cubieboard BUILD_DIR=_build.foc_cubieboard cd _build.foc_cubieboard ~~~ 2. Добавляем репозиторий hello_tutorial для сбоки простейшего сценария, которому не требуются отсутсвующие пока драйверы. ~~~ echo 'REPOSITORIES += $(GENODE_DIR)/hello_tutorial' >> etc/build.conf ~~~ 3. Включаем генерацию файла u-boot-image ~~~ echo 'SPECS += uboot' >> etc/spec.conf ~~~ 4. Cобираем образ ~~~ make run/hello ~~~ После непродолжительной сборки получаем образ в виде: ELF (hello.elf) и u-boot-image (uImage) в директории var/run/hello. После запуска на устройстве, в подключенной консоле, можно увидеть процесс загрузки и выполняющиеся приложения из hello tutorial: ~~~ L4 Bootstrapper Build: #4 Чт. апр. 18 22:48:37 MSK 2013, 4.7.2 Scanning up to 1024 MB RAM Memory size is 1024MB (40000000 - 80000000) RAM: 0000000040000000 - 000000007fffffff: 1048576kB Total RAM: 1024MB mod07: 4117e000-411b8e3c: genode/timer mod06: 41148000-4117ddc0: genode/hello_server mod05: 4111c000-41147c28: genode/hello_client mod04: 410d6000-4111b738: genode/init mod03: 410d5000-410d51a4: genode/config mod02: 4106e000-410d431c: genode/core mod01: 41064000-4106d374: sigma0 mod00: 41015000-41063d20: /home/vanner/projects/genode-iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco Moving up to 8 modules behind 41100000 moving module 00 { 41015000-41063d1f } -> { 412a4000-412f2d1f } [322848] moving module 01 { 41064000-4106d373 } -> { 412f3000-412fc373 } [37748] moving module 02 { 4106e000-410d431b } -> { 412fd000-4136331b } [418588] moving module 03 { 410d5000-410d51a3 } -> { 411b9000-411b91a3 } [420] moving module 04 { 410d6000-4111b737 } -> { 411ba000-411ff737 } [284472] moving module 05 { 4111c000-41147c27 } -> { 41100000-4112bc27 } [179240] moving module 06 { 41148000-4117ddbf } -> { 4112c000-41161dbf } [220608] moving module 07 { 4117e000-411b8e3b } -> { 41162000-4119ce3b } [241212] moving module 03 { 411b9000-411b91a3 } -> { 4119d000-4119d1a3 } [420] moving module 04 { 411ba000-411ff737 } -> { 4119e000-411e3737 } [284472] Scanning /home/vanner/projects/genode-iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco -serial_esc Scanning sigma0 Scanning genode/core Relocated mbi to [0x4100e000-0x4100e19c] Loading -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco Loading sigma0 Loading genode/core find kernel info page... found kernel info page at 0x40002000 Regions of list 'regions' [ 40001000, 400019ff] { a00} Kern -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco [ 40002000, 40060fff] { 5f000} Kern -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco [ 40090000, 4009673b] { 673c} Sigma0 sigma0 [ 40098000, 4009e17b] { 617c} Sigma0 sigma0 [ 40100000, 4024743f] { 147440} Root genode/core [ 41000000, 410143f3] { 143f4} Boot bootstrap [ 4100e000, 4100e299] { 29a} Root Multiboot info [ 41100000, 411e3737] { e3738} Root Module API Version: (87) experimental Sigma0 config ip:40090100 sp:41013d24 Roottask config ip:4014af84 sp:00000000 Starting kernel -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco at 40001198 Hello from Startup::stage2 Boot_alloc: size=0x180 Boot_alloc: allocated extra memory block @0xf13e1000 (size=400) Boot_alloc: @ 0xf13e1000 Boot_alloc: remaining free block @ 0xf13e1180 (size=280) Cache config: ON ID_PFR[01]: 00001131 00000011 ID_[DA]FR0: 00000400 00000000 ID_MMFR[04]: 01100003 20000000 01202000 00000211 FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 3, v: c, i: 41, t: hard, p: dbl/sngl Startup::stage2 finished SERIAL ESC: allocated IRQ 1 for serial uart Not using serial hack in slow timer handler. Welcome to Fiasco.OC (arm)! L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden Rev: 8991035 compiled with gcc 4.7.2 for sun4i [] Build: #3 Чт. апр. 18 22:48:33 MSK 2013 Calibrating timer loop... done. SIGMA0: Hello! KIP @ 40002000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [0:40000000;40000fff] [0:40061000;4008ffff] [0:40097000;40097fff] [0:4009f000;400fffff] [4:40100000;40247fff] [0:40248000;4100dfff] [4:4100e000;4100efff] [0:4100f000;410fffff] [4:41100000;411e3fff] [0:411e4000;7effffff] IOMEM:---------------------- [0:0;3fffffff] [0:80000000;ffffffff] KIP @ 40002000 magic: 4be6344c version: 87014444 sigma0 esp: 41013d24 eip: 40090100 sigma1 esp: 00000000 eip: 00000000 root esp: 00000000 eip: 4014af84 MBI @ 4100e000 mod[3] [4119d000,4119d1a4) config mod[4] [4119e000,411e3738) init mod[5] [41100000,4112bc28) hello_client mod[6] [4112c000,41161dc0) hello_server mod[7] [41162000,4119ce3c) timer :ram_alloc: Allocator 40230784 dump: Block: [50000000,5000001c) size=0000001c avail=00000000 max_avail=00000000 Block: [5000001c,50000038) size=0000001c avail=00000000 max_avail=00000000 Block: [50000038,50000054) size=0000001c avail=00000000 max_avail=00000000 Block: [50000054,50000070) size=0000001c avail=00000000 max_avail=2effff58 Block: [50000070,5000008c) size=0000001c avail=00000000 max_avail=00000000 Block: [5000008c,500000a8) size=0000001c avail=00000000 max_avail=2effff58 Block: [500000a8,7f000000) size=2effff58 avail=2effff58 max_avail=2effff58 => mem_size=788529152 (752 MB) / mem_avail=788528984 (751 MB) :region_alloc: Allocator 402318f4 dump: Block: [00001000,40000000) size=3ffff000 avail=3ffff000 max_avail=3ffff000 Block: [7f000000,bfff0000) size=40ff0000 avail=40ff0000 max_avail=40ff0000 Block: [bfff1000,c0000000) size=0000f000 avail=0000f000 max_avail=0000f000 => mem_size=2164252672 (2063 MB) / mem_avail=2164252672 (2063 MB) :io_mem: Allocator 40230be0 dump: Block: [00000000,40000000) size=40000000 avail=40000000 max_avail=40000000 Block: [40001000,40002000) size=00001000 avail=00001000 max_avail=40000000 Block: [40003000,40061000) size=0005e000 avail=0005e000 max_avail=0005e000 Block: [40090000,40097000) size=00007000 avail=00007000 max_avail=0005e000 Block: [40098000,4009f000) size=00007000 avail=00007000 max_avail=80ffffff Block: [7f000000,ffffffff) size=80ffffff avail=80ffffff max_avail=80ffffff => mem_size=3238449151 (3088 MB) / mem_avail=3238449151 (3088 MB) :io_port: Allocator 4023103c dump: :irq: Allocator 40231498 dump: Block: [00000000,00000100) size=00000100 avail=00000100 max_avail=00000100 => mem_size=256 (0 MB) / mem_avail=256 (0 MB) :rom_fs: Rom_fs 402321a8 dump: Rom: [4119e000,411e3738) init Rom: [41100000,4112bc28) hello_client Rom: [4119d000,4119d1a4) config Rom: [4112c000,41161dc0) hello_server Rom: [40002000,40003000) l4v2_kip Rom: [40002000,40003000) kip Rom: [41162000,4119ce3c) timer :core ranges: Allocator 40233f08 dump: Block: [40100000,40248000) size=00148000 avail=00148000 max_avail=00148000 Block: [41100000,411e4000) size=000e4000 avail=000e4000 max_avail=2f000000 Block: [50000000,7f000000) size=2f000000 avail=2f000000 max_avail=2f000000 => mem_size=790806528 (754 MB) / mem_avail=790806528 (754 MB) int main(): --- create local services --- int main(): --- start init --- int main(): transferred 751 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open file "ld.lib.so" [init -> hello_server] Hello::Root_component::Root_component(Genode::Rpc_entrypoint*, Genode::Allocator*): Creating root component. [init -> hello_server] virtual Hello::Session_component* Hello::Root_component::_create_session(const char*): creating hello session. [init -> hello_client] virtual void Hello::Session_client::say_hello(): Saying Hello. [init -> hello_server] virtual void Hello::Session_component::say_hello(): I am here... Hello. [init -> hello_client] int main(): Added 2 + 5 = 7 [init -> hello_client] virtual void Hello::Session_client::say_hello(): Saying Hello. [init -> hello_server] virtual void Hello::Session_component::say_hello(): I am here... Hello. [init -> hello_client] int main(): Added 2 + 5 = 7 ... ~~~;T; I"fS

Портирование Genode OS Framework на новую аппаратную платформу

Данная статья рассказывает о Genode OS Framework и процессе портирования его на новую аппаратную платформу на базе процессора архитектуры ARM. В качестве ядра для Genode используется Fiasco.OC.

text

И так, что такое Genode OS Framework? Это фреймворк для построения операционной системы на базе микроядра. Genode предоставляет единый API, позволяющий использовать различные микроядра для построения ОС. На данный момент поддерживаются следующие микроядра: Codezero, Fiasco, Fiasco.OC, Nova, OKL4, Pistachio. Также поддерживается работа на ядре Linux. Кроме этого, возможен запуск без использования сторонних ядер (base-hw) на некоторых платформах на базе архитектуры ARM.
Эти ядра поддерживают разные архитектуры процессоров и могут использовать некоторое аппаратные возможности. Например, ядро Fiasco.OC может работать на большом количестве архитектур, таких как: x86, amd64, ARM (доступны и другие архитектуры, но они не поддерживаются в Genode на данный момент), а ядро Nova является микрогипервизором для архитектуры x86 и позволяет использовать аппаратную виртуализацию. Благодаря использованию фреймворка Genode мы можем без изменений исходного кода компилировать приложение для использования на любом из поддерживаемых ядер. Более подробную информацию о Genode можно получить из документации, размещенной на сайте проекта, а также из материалов, прочитаных Norman Feske для “Летней школы системного программирования Ksys labs

В настоящее время Genode+FIasco.OC для архитектуры ARM поддерживает следующие платформы: Realview PBXA9, Versatile Express A9X4, Pandaboard (TI OMAP4), Freescale iMX53, Arndale (Samsung Exynos 5).
В качестве платформы для портирования был использован мини-ПК Cubieboard на базе SoC Allwinner A10. Эта платформа интересна по ряду причин:
- не слишком устаревшая архитектура Cortex-A8;
- наличие исходного кода загрузчика U-Boot, ядра Linux и ”утекшей” в сеть документации в виде руководства пользователя;
- большой набор переферии (SATA, HDMI, и др.);
- наличие большого количества недорогих “hackable” устройств на этом чипе (Cubieboard, Mele A1000/A2000, и другие).

Рассмотрим этот SoC более подробно.

text
Рисунок 1 - Функциональная диаграмма

CPU: ARM Cortex-A8 с частотой до 1Ghz с поддержкой NEON, VFPv3, Trustzone
GPU: Mali 400 MP с поддержкой Open GL ES 2.0
VPU: CedarX с поддержкой FullHD видео.
Переферия: 4xUSB Host, USB OTG, 4xSD/MMC, 8xUART, 4xSPI, 3xI2C, GPIO, SATA, HDMI, LCD-интерфейс и другие

Ядро Fiasco.OC поддерживает архитектуру процессоров Cortex-A8. Это значит, что для портирования его на новую платформу нужно только добавить поддержку платформы, так называемый Board Support PAckage ([BSP] (http://ru.wikipedia.org/wiki/Board_Support_Package)). Исходный код BSP расположен в директории kernel/fiasco/src/kern/arm/bsp.
В состав BSP для архитектуры ARM в Fiasco.OC входит:
- драйвер контроллера прерываний;
- драйвер таймера;
- драйвер UART;
- реализация сброса.
Кроме этого, в состав BSP входит конфигурация распределения памяти.
Память в A10, согласно руководству пользователя, распределяется следующим образом:

text

Для того, чтобы ОС могла использовать память, она должна знать физические адреса и размер необходимых регионов памяти. Эти параметры задаются в классе Mem_layout, файл mem_layout-arm-sun4i.cpp:

EXTENSION class Mem_layout
{
public:
  enum Virt_layout_sun4i : Address {
    Timer_map_base       = Devices1_map_base + 0x020C00,
    Intc_map_base        = Devices1_map_base + 0x020400,
    Uart_base            = Devices1_map_base + 0x028000,

    Watchdog_map_base    = Timer_map_base    + 0x90,
  };

  enum Phys_layout_sun4i : Address {
    Devices1_phys_base   = 0x01c00000,

    Sdram_phys_base      = 0x40000000,
    Flush_area_phys_base = 0xe0000000,
  };
};

Контроллер прерываний необходим для обработки событий от различных источников прерываний. Драйвер контроллера прерываний должен реализовать такие операции как: конфигурирование контроллера, маскирование прерываний, функцию обработки. Код драйвера в файле pic-arm-sun4i.cpp.

Таймер необходим для генерации событий,таких как: конец тайм-слота или таймаут IPC. В A10 имеется 6 таймеров. В качестве таймера для переодических прерываний используется таймер Timer0. Кроме таймеров общего назначения в состав SoC также входят Watchdog и RTC с будильником.
Для использования таймера в режиме системного он должен генерировать прерывание каждую 1 мс. Инициализация таймера и необходимые функции реализованы в файле timer-arm-sun4i.cpp.

Драйвер UART используется ядром для вывода отладочных сообщений и доступа к отладчику ядра JDB. В Fiasco.OC инициализация модуля UART отсутсвует, считается, что его уже настроил загрузчик, в нашем случае - U-Boot. Код драйвера UART находится в файлах uart-arm-sun4i.cpp и kernel/fiasco/src/lib/uart/uart_sun4i.cc.

Для выполнения полного сброса процессора применяется Watchdog таймера, назначением которого является сброс системы при зацикливании кода. Реализация находится в файле reset-arm-sun4i.cpp.

После выполнения этих действий мы получаем BSP для выбраного процессора.

Рассмотрим процесс загрузки Genode+Fiasco.OC на архитектуре ARM:

  1. При старте ROM-boot ищет загрузчик на SD-карте или загружается с NAND при отсутсвии SD-карты.
  2. U-Boot, выполняя стартовые скрипты, загружает образ Genode в виде ELF или u-boot-image.
  3. Загруженный модуль содержит в себе ядро Fiasco.OC и все остальные исполняемые файлы, такие как: sigma0, root task (в Genode это модуль core) и пользовательские программы.
  4. Первым стартует bootstrap, который выполняет часть операций неоходимых для старта ядра, такие как: — сканирование доступной памяти (выполняется не для всех архитектур, на ARM значение доступной памяти задается в конфигурации на платформу); — перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить); — и непосредственно запуск ядра.
  5. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task.
  6. Начинает выполняться модуль core (являющийся root task), который инициализирует сервисы Genode и позволяет запускать необходимые нам приложения, используя конфигурационный файл.

Соответсвенно для запуска bootstrap на Cubieboard он должен знать об этой платформе, поэтому добавляем нужную конфигурацию l4/mk/platforms/cubieboard.conf и l4/pkg/bootstrap/server/src/platform/sun4i.cc. Кроме этого необходимо реализовать драйвер UART для вывода информации о загрузке в консоль.

Заключительный этап портирования — добавление необходимых файлов конфигурации в сборочную систему Genode. Изменения можно посмотреть в соответвующем коммите в репозитории. Хорошее описание системы сборки было рассмотрено в лекции “Genode OS Framework Programming Environment”.

Исходные коды находятся на Github https://github.com/Ksys-labs/genode в ветке tutorials. Модифицированная версия Fiasco.OC в репозитории https://github.com/Ksys-labs/foc в ветке r47-sun4i, эти исходные коды уже содержат необходимые патчи и скачиваются с помощью системы сборки Genode.

Для сборки необходимо клонировать исходный код:

git clone git://github.com/Ksys-labs/genode.git
git checkout tutorials
cd genode

Собрать тулчейн для ARM:

./tools/tool_chain arm

И скачать ядро Fiasco.OC:

make prepare -C base-foc

Теперь все готово для запуска.

  1. Создаем директорию для сборки, используя команду:
./tools/create_builddir foc_cubieboard BUILD_DIR=_build.foc_cubieboard
cd _build.foc_cubieboard
  1. Добавляем репозиторий hello_tutorial для сбоки простейшего сценария, которому не требуются отсутсвующие пока драйверы.
echo 'REPOSITORIES += $(GENODE_DIR)/hello_tutorial' >> etc/build.conf
  1. Включаем генерацию файла u-boot-image
echo 'SPECS += uboot' >> etc/spec.conf
  1. Cобираем образ
make run/hello

После непродолжительной сборки получаем образ в виде: ELF (hello.elf) и u-boot-image (uImage) в директории var/run/hello. После запуска на устройстве, в подключенной консоле, можно увидеть процесс загрузки и выполняющиеся приложения из hello tutorial:

L4 Bootstrapper
  Build: #4 Чт. апр. 18 22:48:37 MSK 2013, 4.7.2
  Scanning up to 1024 MB RAM
  Memory size is 1024MB (40000000 - 80000000)
  RAM: 0000000040000000 - 000000007fffffff: 1048576kB
  Total RAM: 1024MB
  mod07: 4117e000-411b8e3c: genode/timer
  mod06: 41148000-4117ddc0: genode/hello_server
  mod05: 4111c000-41147c28: genode/hello_client
  mod04: 410d6000-4111b738: genode/init
  mod03: 410d5000-410d51a4: genode/config
  mod02: 4106e000-410d431c: genode/core
  mod01: 41064000-4106d374: sigma0
  mod00: 41015000-41063d20: /home/vanner/projects/genode-iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
  Moving up to 8 modules behind 41100000
  moving module 00 { 41015000-41063d1f } -> { 412a4000-412f2d1f } [322848]
  moving module 01 { 41064000-4106d373 } -> { 412f3000-412fc373 } [37748]
  moving module 02 { 4106e000-410d431b } -> { 412fd000-4136331b } [418588]
  moving module 03 { 410d5000-410d51a3 } -> { 411b9000-411b91a3 } [420]
  moving module 04 { 410d6000-4111b737 } -> { 411ba000-411ff737 } [284472]
  moving module 05 { 4111c000-41147c27 } -> { 41100000-4112bc27 } [179240]
  moving module 06 { 41148000-4117ddbf } -> { 4112c000-41161dbf } [220608]
  moving module 07 { 4117e000-411b8e3b } -> { 41162000-4119ce3b } [241212]
  moving module 03 { 411b9000-411b91a3 } -> { 4119d000-4119d1a3 } [420]
  moving module 04 { 411ba000-411ff737 } -> { 4119e000-411e3737 } [284472]
  Scanning /home/vanner/projects/genode-iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco -serial_esc 
  Scanning sigma0
  Scanning genode/core
  Relocated mbi to [0x4100e000-0x4100e19c]
  Loading -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
  Loading sigma0
  Loading genode/core
  find kernel info page...
  found kernel info page at 0x40002000
Regions of list 'regions'
    [ 40001000,  400019ff] {      a00} Kern   -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
    [ 40002000,  40060fff] {    5f000} Kern   -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco
    [ 40090000,  4009673b] {     673c} Sigma0 sigma0
    [ 40098000,  4009e17b] {     617c} Sigma0 sigma0
    [ 40100000,  4024743f] {   147440} Root   genode/core
    [ 41000000,  410143f3] {    143f4} Boot   bootstrap
    [ 4100e000,  4100e299] {      29a} Root   Multiboot info
    [ 41100000,  411e3737] {    e3738} Root   Module
  API Version: (87) experimental
  Sigma0 config    ip:40090100 sp:41013d24
  Roottask config  ip:4014af84 sp:00000000
  Starting kernel -iloskutov/_build.foc_cubieboard/kernel/fiasco.oc/fiasco at 40001198
Hello from Startup::stage2
Boot_alloc: size=0x180
Boot_alloc: allocated extra memory block @0xf13e1000 (size=400)
Boot_alloc: @ 0xf13e1000
Boot_alloc: remaining free block @ 0xf13e1180 (size=280)
Cache config: ON
ID_PFR[01]:  00001131 00000011 ID_[DA]FR0: 00000400 00000000
ID_MMFR[04]: 01100003 20000000 01202000 00000211
FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 3, v: c, i: 41, t: hard, p: dbl/sngl
Startup::stage2 finished
SERIAL ESC: allocated IRQ 1 for serial uart
Not using serial hack in slow timer handler.
Welcome to Fiasco.OC (arm)!
L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden
Rev: 8991035 compiled with gcc 4.7.2 for sun4i    []
Build: #3 Чт. апр. 18 22:48:33 MSK 2013

Calibrating timer loop... done.
SIGMA0: Hello!
  KIP @ 40002000
  allocated 4KB for maintenance structures
SIGMA0: Dump of all resource maps
RAM:------------------------
[0:40000000;40000fff]
[0:40061000;4008ffff]
[0:40097000;40097fff]
[0:4009f000;400fffff]
[4:40100000;40247fff]
[0:40248000;4100dfff]
[4:4100e000;4100efff]
[0:4100f000;410fffff]
[4:41100000;411e3fff]
[0:411e4000;7effffff]
IOMEM:----------------------
[0:0;3fffffff]
[0:80000000;ffffffff]

KIP @ 40002000
    magic: 4be6344c
  version: 87014444
         sigma0  esp: 41013d24  eip: 40090100
         sigma1  esp: 00000000  eip: 00000000
           root  esp: 00000000  eip: 4014af84
MBI @ 4100e000
 mod[3] [4119d000,4119d1a4) config
 mod[4] [4119e000,411e3738) init
 mod[5] [41100000,4112bc28) hello_client
 mod[6] [4112c000,41161dc0) hello_server
 mod[7] [41162000,4119ce3c) timer
:ram_alloc: Allocator 40230784 dump:
 Block: [50000000,5000001c) size=0000001c avail=00000000 max_avail=00000000
 Block: [5000001c,50000038) size=0000001c avail=00000000 max_avail=00000000
 Block: [50000038,50000054) size=0000001c avail=00000000 max_avail=00000000
 Block: [50000054,50000070) size=0000001c avail=00000000 max_avail=2effff58
 Block: [50000070,5000008c) size=0000001c avail=00000000 max_avail=00000000
 Block: [5000008c,500000a8) size=0000001c avail=00000000 max_avail=2effff58
 Block: [500000a8,7f000000) size=2effff58 avail=2effff58 max_avail=2effff58
 => mem_size=788529152 (752 MB) / mem_avail=788528984 (751 MB)
:region_alloc: Allocator 402318f4 dump:
 Block: [00001000,40000000) size=3ffff000 avail=3ffff000 max_avail=3ffff000
 Block: [7f000000,bfff0000) size=40ff0000 avail=40ff0000 max_avail=40ff0000
 Block: [bfff1000,c0000000) size=0000f000 avail=0000f000 max_avail=0000f000
 => mem_size=2164252672 (2063 MB) / mem_avail=2164252672 (2063 MB)
:io_mem: Allocator 40230be0 dump:
 Block: [00000000,40000000) size=40000000 avail=40000000 max_avail=40000000
 Block: [40001000,40002000) size=00001000 avail=00001000 max_avail=40000000
 Block: [40003000,40061000) size=0005e000 avail=0005e000 max_avail=0005e000
 Block: [40090000,40097000) size=00007000 avail=00007000 max_avail=0005e000
 Block: [40098000,4009f000) size=00007000 avail=00007000 max_avail=80ffffff
 Block: [7f000000,ffffffff) size=80ffffff avail=80ffffff max_avail=80ffffff
 => mem_size=3238449151 (3088 MB) / mem_avail=3238449151 (3088 MB)
:io_port: Allocator 4023103c dump:
:irq: Allocator 40231498 dump:
 Block: [00000000,00000100) size=00000100 avail=00000100 max_avail=00000100
 => mem_size=256 (0 MB) / mem_avail=256 (0 MB)
:rom_fs: Rom_fs 402321a8 dump:
 Rom: [4119e000,411e3738) init
 Rom: [41100000,4112bc28) hello_client
 Rom: [4119d000,4119d1a4) config
 Rom: [4112c000,41161dc0) hello_server
 Rom: [40002000,40003000) l4v2_kip
 Rom: [40002000,40003000) kip
 Rom: [41162000,4119ce3c) timer
:core ranges: Allocator 40233f08 dump:
 Block: [40100000,40248000) size=00148000 avail=00148000 max_avail=00148000
 Block: [41100000,411e4000) size=000e4000 avail=000e4000 max_avail=2f000000
 Block: [50000000,7f000000) size=2f000000 avail=2f000000 max_avail=2f000000
 => mem_size=790806528 (754 MB) / mem_avail=790806528 (754 MB)
int main(): --- create local services ---
int main(): --- start init ---
int main(): transferred 751 MB to init
int main(): --- init created, waiting for exit condition ---
[init] Could not open file "ld.lib.so"
[init -> hello_server] Hello::Root_component::Root_component(Genode::Rpc_entrypoint*, Genode::Allocator*): Creating root component.
[init -> hello_server] virtual Hello::Session_component* Hello::Root_component::_create_session(const char*): creating hello session.
[init -> hello_client] virtual void Hello::Session_client::say_hello(): Saying Hello.
[init -> hello_server] virtual void Hello::Session_component::say_hello(): I am here... Hello.
[init -> hello_client] int main(): Added 2 + 5 = 7
[init -> hello_client] virtual void Hello::Session_client::say_hello(): Saying Hello.
[init -> hello_server] virtual void Hello::Session_component::say_hello(): I am here... Hello.
[init -> hello_client] int main(): Added 2 + 5 = 7
...
;T; @]I"/genode_fork/;T{;{ ;I"# Genode fork
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

We have the following things in our repo which aren’t moved to Genode upstream yet:

  • Gumstix Overo platform, OMAP3 framebuffer driver, ADS7846 touchscreen driver

    We used to use Gumstix board for the first prototype our device. This board is OMAP3 based and it allowed us to use Fiasco.OC and Genode for Gumstix. We have implemented support of framebuffer and touchscreen. Then the platform was changed to OMAP4 and we cancelled a support this code. This code requires a little improvement.

  • Ts_input adapter

    This service implement translation raw data from resistive touchscreen to screen coordinates for Nitpicker. Also Ts_input can be used for touchscreen calibration. Ts_input configuration is compatible with tslib.

  • OMAP4 McSPI driver and SPI session interface

    This is simple SPI driver for OMAP4. We have implemented only part of McSPI functions and this driver have used only for the TSC2046 touchscreen driver.

  • TSC2046 touchscreen controller driver

    Touchscreen driver for the Chipsee expansion board for the Pandaboard.

  • Qt ssl fix

    We have done modification QtNetwork for work over SSL connections in qt-based browsers. Also, fixed loading of openssl.conf for using OpenSSL engines in Qt applications.

  • QtSql and sqlite3

    Added QtSql library with sqlite3 support.

  • Qupzilla browser port

  • Smartcard session interface and driver for TDA8029 smartcard reader

    This interface and driver implement work with smartcards. TDA8029 reader works over UART.

  • Virtual network between l4linux’s

    L4linux driver which is implemented the NIC service and it can be used for connect two l4linux instances using the NIC interface. More information is available at Gateway page.

  • Terminalmux

    Terminal multiplexer. More information available at README

  • TWL6030 Voltage Regulator driver

    This allows to enable various hardware on OMAP4 SoC. The code is in os/include/regulator_session and os/src/drivers/regulator.

  • OMAP4 I2C driver

  • I.MX53 I2C driver

We are currently working on the following features:

  • OMAP4 USB OTG (Client mode for Mentor Graphics MUSB driver).

    We currently have the controller initializing, but the data endpoints are not working. The branch is omap4-otg-dirty ; git.

  • Melfas MMS144 Touchscreen

    This is the touchscreen used in the Samsung Galaxy Nexus phone. A prototype driver and board support code is available in branch tuna-hacks ; Ksys Labs git .

  • OMAP4 GPIO MUX driver

    This allows to set up GPIO alternate functions. The code is in os/include/platform/omap4/gpiomux_session and os/src/drivers/gpio/omap4_mux. The branch is tuna-hacks; Ksys Labs git.

Below is the list of features that we want to implement but have not yet started. While implementing some hardware drivers (PWM, Clock) it will be required to also design a generic driver session interface for Genode.

  • EFI GPT partition support

    This is needed for most new embedded hardware as it is a part of EMMC standard. Also will be needed to support new UEFI laptops

  • File System DDEKit

    Currently the choice of filesystems on Genode is limited to VFAT. Providing the support for linux filesystem drivers via DDEKit will allow to always have the latest version of EXT4 driver and access linux partitions without the risk of destroying them.

  • FS → Block adapter

    This will allow to present a file in a filesystem as a block device in the same way as loop devices work on *NIX. It is needed to support multiple instances of l4linux without repartitioning the storage device

  • OMAP4 Clock driver

    It is required to provide initialization of most peripherals.

  • OMAP4 DVFS

    To reduce power consumption

  • OMAP4 DSS/DSI display

    Support for the cold initialization of the DSS subsystem and the VC interface to support LCD panels on Samsung Galaxy Nexus and Samsung P5100

  • Power Management

    Enhance the sheduler to support idle power saving and (hopefully) suspend2ram.

  • OMAP4 PWM

    Mainly for controlling backlight and vibrator motor in the phone.

  • TWL6040 Sound Codec + Routing

    Sound support on PandaBoard and Galaxy Nexus

;T; I"RWe have the following things in our [repo](https://github.com/Ksys-labs/genode) which aren't moved to Genode upstream yet: * ### Gumstix Overo platform, OMAP3 framebuffer driver, ADS7846 touchscreen driver > We used to use Gumstix board for the first prototype our device. This board is OMAP3 based and it allowed us to use Fiasco.OC and Genode for Gumstix. We have implemented support of framebuffer and touchscreen. Then the platform was changed to OMAP4 and we cancelled a support this code. This code requires a little improvement. * ### Ts_input adapter > This service implement translation raw data from resistive touchscreen to screen coordinates for Nitpicker. Also Ts_input can be used for touchscreen calibration. Ts_input configuration is compatible with tslib. * ### OMAP4 McSPI driver and SPI session interface > This is simple SPI driver for OMAP4. We have implemented only part of McSPI functions and this driver have used only for the TSC2046 touchscreen driver. * ### TSC2046 touchscreen controller driver > Touchscreen driver for the Chipsee expansion board for the Pandaboard. * ### Qt ssl fix > We have done modification QtNetwork for work over SSL connections in qt-based browsers. Also, fixed loading of openssl.conf for using OpenSSL engines in Qt applications. * ### QtSql and sqlite3 > Added QtSql library with sqlite3 support. * ### [Qupzilla](http://www.qupzilla.com/) browser port * ### Smartcard session interface and driver for TDA8029 smartcard reader > This interface and driver implement work with smartcards. TDA8029 reader works over UART. * ### Virtual network between l4linux's > L4linux driver which is implemented the NIC service and it can be used for connect two l4linux instances using the NIC interface. More information is available at Gateway page. * ### Terminalmux > Terminal multiplexer. More information available at [README](https://github.com/Ksys-labs/genode/blob/staging/os/src/server/terminalmux/README) * ### TWL6030 Voltage Regulator driver > This allows to enable various hardware on OMAP4 SoC. > The code is in **os/include/regulator_session** and **os/src/drivers/regulator**. * ### OMAP4 I2C driver * ### I.MX53 I2C driver We are currently working on the following features: * ### OMAP4 USB OTG (Client mode for Mentor Graphics MUSB driver). > We currently have the controller initializing, but the data endpoints are not working. > The branch is omap4-otg-dirty ; [git](https://github.com/astarasikov/genode.git). * ### Melfas MMS144 Touchscreen > This is the touchscreen used in the Samsung Galaxy Nexus phone. > A prototype driver and board support code is available in branch tuna-hacks ; Ksys Labs git . * ### OMAP4 GPIO MUX driver > This allows to set up GPIO alternate functions. > The code is in os/include/platform/omap4/gpiomux_session and os/src/drivers/gpio/omap4_mux. > The branch is **tuna-hacks**; [Ksys Labs git](https://github.com/Ksys-labs/genode.git). Below is the list of features that we want to implement but have not yet started. While implementing some hardware drivers (PWM, Clock) it will be required to also design a generic driver session interface for Genode. * ### EFI GPT partition support > This is needed for most new embedded hardware as it is a part of EMMC standard. Also will be needed to support new UEFI laptops * ### File System DDEKit > Currently the choice of filesystems on Genode is limited to VFAT. Providing the support for linux filesystem drivers via DDEKit will allow to always have the latest version of EXT4 driver and access linux partitions without the risk of destroying them. * ### FS → Block adapter > This will allow to present a file in a filesystem as a block device in the same way as loop devices work on *NIX. It is needed to support multiple instances of l4linux without repartitioning the storage device * ### OMAP4 Clock driver > It is required to provide initialization of most peripherals. * ### OMAP4 DVFS > To reduce power consumption * ### OMAP4 DSS/DSI display > Support for the cold initialization of the DSS subsystem and the VC interface to support LCD panels on Samsung Galaxy Nexus and Samsung P5100 * ### Power Management > Enhance the sheduler to support idle power saving and (hopefully) suspend2ram. * ### OMAP4 PWM > Mainly for controlling backlight and vibrator motor in the phone. * ### TWL6040 Sound Codec + Routing > Sound support on PandaBoard and Galaxy Nexus;T; I"

We have the following things in our repo which aren’t moved to Genode upstream yet:

We are currently working on the following features:

Below is the list of features that we want to implement but have not yet started. While implementing some hardware drivers (PWM, Clock) it will be required to also design a generic driver session interface for Genode.

;T; @cI"/tutorials/;T{;{ ;I" Tutorials

Here will be stored articles like ‘Getting Started’

(RU) Porting Genode to CubieBoard

Porting Genode framework to a commercial device

;T; I"Here will be stored articles like 'Getting Started' [(RU) Porting Genode to CubieBoard](porting_genode_to_cubieboard/) [Porting Genode framework to a commercial device](genode_nookhdp/);T; I"

Here will be stored articles like ‘Getting Started’

(RU) Porting Genode to CubieBoard

Porting Genode framework to a commercial device

;T; @iI" /robots/;T{;{;I" Samsung Galaxy Nexus U-Boot
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

Introduction

This page describes the port of the u-boot bootloader to the Galaxy Nexus phone

Rationale

There were a couple reasons to port u-boot to Galaxy Nexus

  • Security: we cannot trust the proprietary samsung bootloader
  • Implementing dual-boot for original and custom firmware
  • Booting Genode operating system

Demo

Compilation from source

Source code is in https://github.com/Ksys-labs/uboot-tuna

There exist two branches of interest

  • master - contains the official stable releases. may be force-pushed and rebased, beware
  • tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode

To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that’ s what I ‘m using and some users reported that newer compilers produce broken binaries.

There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.

Flashing instead of SBL has the following advantages

  • Faster boot time than chainloading
  • Ability to use the standard partitioning layout

There is a number of issues and therefore we do not recommend flashing it instead of SBL

  • No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you’ ll have to use OMAPFlash to restore the device if you flash a non - working kernel
  • No display initialization.You ‘ll have to disable the “Check for Bootloader initialization” option in kernel config

By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address 0x81808000.

If you want to build the SBL replacement version, edit the include/configs/omap4_tuna.h file and uncomment the #define TUNA_SPL_BUILD line. X-loader loads the bootloader to the address 0xa0208000.

export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-

U_BOARD=omap4_tuna
make clean
make distclean

make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg

Installation

Chainloaded Mode

You will need the root access to your device. You can take the prebuilt u-boot here. [gnex-uboot-chainloaded.img]

The u - boot has the support for android boot images.When flashed instead of the SBL, it boots the kernel off the “Boot” partition. When chainloaded, it looks for the kernel in /system/boot/vmlinux.uimg. Additionally, it first looks for the /system/boot/boot.scr.uimg so you can put custom commands there and override the kernel image.

It also supports booting custom images from /sdcard/boot/vmlinux.uimg and /sdcard/boot/boot.scr.uimg.

If you need larger images, I suggest that you use the tuna-fosdem-hacks branch, format the cache partition to ext2 and put the files to /cache/media/boot/.

push the files to your device via adb

adb push gnex-uboot-chainloaded.img /sdcard/ 
adb hell 

now, in the device shell, do the following:

su cat /dev/block/platform /omap/omap_hsmmc.0/by-name/boot > /sdcard /vmlinux.uimg mount - o remount, rw /system mkdir/system/boot cp /sdcard/vmlinux.uimg /system/boot/ cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform /omap /omap_hsmmc.0/by-name/boot sync reboot

you can also use fastboot to flash u-boot.img instead of dd’ing it

fastboot flash:raw boot u-boot.img”

Replacing samsung bootloader

OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.

Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.

Take the x-loader here [gnex-xloader-working.img]

adb push gnex-xloader-working.img /sdcard/

The installation procedure is roughly the same, but use sbl partition. Also, install xloader by

cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader

There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.

Search the internet for the archive named “OMAPFlash_tuna.zip” which has md5 “ddbf07a1d36b044c40af5788a83b5395”. We cannot upload it here because of the unclear license status.

Making images

You can either use Android’ s mkbootimg to produce ANDROID !type images (not recommended) or u-boot’s mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.

making a custom boot image

mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg

#alternatively, just do that when compiling linux

#do not forget to add mkimage to your PATH variable make uImage making a custom boot script

mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg

Booting Modes

The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android “reboot to recovery” and “reboot to bootloader” features

  • Normal Boot -> no keys are pressed, cyan LED
  • Recovery Boot -> Volume Up key pressed, green LED
  • Custom Boot -> Volume Down key pressed, blue LED
  • USB RNDIS mode -> both Volume keys pressed, purple LED

Pitfalls

  • No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you’ re chainloading, right ?
  • Serial number is always 0123456789 abcdef or sth like that.Anyone to fix that ?
  • UART support is quirky.The device will likely hang if booted with the UART cable.Workaround : boot without the UART cable and plug right after the purple LED flashes.

A sample boot script for android

Make a boot.scr.uimg from it and push it to the correct location.

setenv bootargs “mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18 no_console_suspend console=ttyFIQ0”;

setenv loaddaddr 0x82000000;

setenv devtype mmc;

setenv devnum 0;

setenv kernel_part 0xc;

setenv kernel_name /media/boot/vmlinux.uimg;

echo Load Address: ${loaddaddr};

echo cmdline:${bootargs};

if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0\;

elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0;

else

echo failed to boot custom image;

fi

;T; I"dIntroduction ==================== This page describes the port of the u-boot bootloader to the Galaxy Nexus phone Rationale ==================== There were a couple reasons to port u-boot to Galaxy Nexus * Security: we cannot trust the proprietary samsung bootloader * Implementing dual-boot for original and custom firmware * Booting Genode operating system Demo ==================== Compilation from source --------------------- Source code is in [https://github.com/Ksys-labs/uboot-tuna](https://github.com/Ksys-labs/uboot-tuna) There exist two branches of interest * master - contains the official stable releases. may be force-pushed and rebased, beware * tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that' s what I 'm using and some users reported that newer compilers produce broken binaries. There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL. Flashing instead of SBL has the following advantages * Faster boot time than chainloading * Ability to use the standard partitioning layout There is a number of issues and therefore we do not recommend flashing it instead of SBL * No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you' ll have to use OMAPFlash to restore the device if you flash a non - working kernel * No display initialization.You 'll have to disable the “Check for Bootloader initialization” option in kernel config By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address **0x81808000**. If you want to build the SBL replacement version, edit the **include/configs/omap4_tuna.h** file and uncomment the **#define TUNA_SPL_BUILD line**. X-loader loads the bootloader to the address **0xa0208000**. ~~~ export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH export ARCH=arm export CROSS_COMPILE=arm-none-eabi- U_BOARD=omap4_tuna make clean make distclean make ${U_BOARD}_config make -j8 ${U_BOARD} mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg ~~~ {:.language-text} Installation ==================== Chainloaded Mode You will need the root access to your device. You can take the prebuilt u-boot here. [gnex-uboot-chainloaded.img] The u - boot has the support for android boot images.When flashed instead of the SBL, it boots the kernel off the "Boot" partition. When chainloaded, it looks for the kernel in **/system/boot/vmlinux.uimg**. Additionally, it first looks for the **/system/boot/boot.scr.uimg** so you can put custom commands there and override the kernel image. It also supports booting custom images from **/sdcard/boot/vmlinux.uimg** and **/sdcard/boot/boot.scr.uimg**. If you need larger images, I suggest that you use the **tuna-fosdem-hacks** branch, format the cache partition to ext2 and put the files to **/cache/media/boot/**. push the files to your device via adb ~~~ adb push gnex-uboot-chainloaded.img /sdcard/ adb hell ~~~ {:.language-text} now, in the device shell, do the following: > su > cat /dev/block/platform /omap/omap_hsmmc.0/by-name/boot > /sdcard /vmlinux.uimg > mount - o remount, rw /system mkdir/system/boot > cp /sdcard/vmlinux.uimg /system/boot/ > cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform /omap /omap_hsmmc.0/by-name/boot > sync > reboot you can also use fastboot to flash u-boot.img instead of dd'ing it > fastboot flash:raw boot u-boot.img" Replacing samsung bootloader ==================== OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB. Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed. Take the x-loader here [gnex-xloader-working.img] > adb push gnex-xloader-working.img /sdcard/ The installation procedure is roughly the same, but use sbl partition. Also, install xloader by > cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP. Search the internet for the archive named “OMAPFlash_tuna.zip” which has md5 “ddbf07a1d36b044c40af5788a83b5395”. We cannot upload it here because of the unclear license status. Making images ==================== You can either use Android' s mkbootimg to produce ANDROID !type images (not recommended) or u-boot's mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images. making a custom boot image --------------------- > mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg > \#alternatively, just do that when compiling linux > > \#do not forget to add mkimage to your PATH variable > make uImage > making a custom boot script > mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg Booting Modes ==================== The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android “reboot to recovery” and “reboot to bootloader” features * Normal Boot -> no keys are pressed, cyan LED * Recovery Boot -> Volume Up key pressed, green LED * Custom Boot -> Volume Down key pressed, blue LED * USB RNDIS mode -> both Volume keys pressed, purple LED Pitfalls ==================== * No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you' re chainloading, right ? * Serial number is always 0123456789 abcdef or sth like that.Anyone to fix that ? * UART support is quirky.The device will likely hang if booted with the UART cable.Workaround : boot without the UART cable and plug right after the purple LED flashes. A sample boot script for android ==================== Make a boot.scr.uimg from it and push it to the correct location. > setenv bootargs "mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18 no_console_suspend console=ttyFIQ0"; > > setenv loaddaddr 0x82000000; > > setenv devtype mmc; > > setenv devnum 0; > > setenv kernel_part 0xc; > > setenv kernel_name /media/boot/vmlinux.uimg; > > echo Load Address: ${loaddaddr}; > > echo cmdline:${bootargs}; > > if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then > > bootm ${loaddaddr}; > > exit 0\; > > elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then > > bootm ${loaddaddr}; > > exit 0; > > else > echo failed to boot custom image; > fi;T; I"9

Introduction

This page describes the port of the u-boot bootloader to the Galaxy Nexus phone

Rationale

There were a couple reasons to port u-boot to Galaxy Nexus

  • Security: we cannot trust the proprietary samsung bootloader
  • Implementing dual-boot for original and custom firmware
  • Booting Genode operating system

Demo

Compilation from source

Source code is in https://github.com/Ksys-labs/uboot-tuna

There exist two branches of interest

  • master - contains the official stable releases. may be force-pushed and rebased, beware
  • tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode

To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that’ s what I ‘m using and some users reported that newer compilers produce broken binaries.

There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.

Flashing instead of SBL has the following advantages

  • Faster boot time than chainloading
  • Ability to use the standard partitioning layout

There is a number of issues and therefore we do not recommend flashing it instead of SBL

  • No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you’ ll have to use OMAPFlash to restore the device if you flash a non - working kernel
  • No display initialization.You ‘ll have to disable the “Check for Bootloader initialization” option in kernel config

By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address 0x81808000.

If you want to build the SBL replacement version, edit the include/configs/omap4_tuna.h file and uncomment the #define TUNA_SPL_BUILD line. X-loader loads the bootloader to the address 0xa0208000.

export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-

U_BOARD=omap4_tuna
make clean
make distclean

make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg

Installation

Chainloaded Mode

You will need the root access to your device. You can take the prebuilt u-boot here. [gnex-uboot-chainloaded.img]

The u - boot has the support for android boot images.When flashed instead of the SBL, it boots the kernel off the “Boot” partition. When chainloaded, it looks for the kernel in /system/boot/vmlinux.uimg. Additionally, it first looks for the /system/boot/boot.scr.uimg so you can put custom commands there and override the kernel image.

It also supports booting custom images from /sdcard/boot/vmlinux.uimg and /sdcard/boot/boot.scr.uimg.

If you need larger images, I suggest that you use the tuna-fosdem-hacks branch, format the cache partition to ext2 and put the files to /cache/media/boot/.

push the files to your device via adb

adb push gnex-uboot-chainloaded.img /sdcard/ 
adb hell 

now, in the device shell, do the following:

su cat /dev/block/platform /omap/omap_hsmmc.0/by-name/boot > /sdcard /vmlinux.uimg mount - o remount, rw /system mkdir/system/boot cp /sdcard/vmlinux.uimg /system/boot/ cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform /omap /omap_hsmmc.0/by-name/boot sync reboot

you can also use fastboot to flash u-boot.img instead of dd’ing it

fastboot flash:raw boot u-boot.img”

Replacing samsung bootloader

OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.

Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.

Take the x-loader here [gnex-xloader-working.img]

adb push gnex-xloader-working.img /sdcard/

The installation procedure is roughly the same, but use sbl partition. Also, install xloader by

cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader

There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.

Search the internet for the archive named “OMAPFlash_tuna.zip” which has md5 “ddbf07a1d36b044c40af5788a83b5395”. We cannot upload it here because of the unclear license status.

Making images

You can either use Android’ s mkbootimg to produce ANDROID !type images (not recommended) or u-boot’s mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.

making a custom boot image

mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg

#alternatively, just do that when compiling linux

#do not forget to add mkimage to your PATH variable make uImage making a custom boot script

mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg

Booting Modes

The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android “reboot to recovery” and “reboot to bootloader” features

  • Normal Boot -> no keys are pressed, cyan LED
  • Recovery Boot -> Volume Up key pressed, green LED
  • Custom Boot -> Volume Down key pressed, blue LED
  • USB RNDIS mode -> both Volume keys pressed, purple LED

Pitfalls

  • No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you’ re chainloading, right ?
  • Serial number is always 0123456789 abcdef or sth like that.Anyone to fix that ?
  • UART support is quirky.The device will likely hang if booted with the UART cable.Workaround : boot without the UART cable and plug right after the purple LED flashes.

A sample boot script for android

Make a boot.scr.uimg from it and push it to the correct location.

setenv bootargs “mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18 no_console_suspend console=ttyFIQ0”;

setenv loaddaddr 0x82000000;

setenv devtype mmc;

setenv devnum 0;

setenv kernel_part 0xc;

setenv kernel_name /media/boot/vmlinux.uimg;

echo Load Address: ${loaddaddr};

echo cmdline:${bootargs};

if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0\;

elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0;

else

echo failed to boot custom image;

fi

;T; @tI"/how-to/gdb_fiasco/;T{;{ ;I" How to use GDB to debug L4Re and L4Linux

using GDB to debug L4Re and L4Linux

GDB in conjunction with qemu can be used to debug L4Re applications and L4Linux

configuring QEMU

First, configure the qemu to automatically start the GDB server. To do this, add the “-s” switch to the parameters. When building L4Re, you can use the Makeconf.boot file to set up qemu. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

You need to uncomment or add the following line to the Makeconf.boot: > QEMU_OPTIONS += -s

connecting the debugger

Next, launch the gdb. If your host machine has the architecture different to the one being debugged, set the correct architecture via “set architecture i386:x86_64”. Also, I had to install “gdb-multiarch” on my i386 debian system to be able to debug an amd64 kernel.

A good frontend for the GDB is CGDB (which uses ncurses) which displays both the command prompt and the source code.

Now, when qemu is started, we can connect to it from gdb: target remote tcp::1234

loading symbols

To allow gdb to display functions and variable names, we need to add the debugging symbols. To know the addresses for them, use objdump and look for the address of the first LOAD section. Luckily for us, by default each module is loaded to a different address, and physical addresses match virtual ones, so we can even debug across context switches.

add-symbol-file /mnt/disk2/work/l4linux/2git/git/build/fiasco.image 0
add-symbol-file /mnt/disk2/work/l4linux/2git/git/build_l4linux/vmlinux 0x400000

using GDB

Now, you can debug L4Re binaries and L4Linux as ordinary executables. For example, set up a breakpoint at some function and continue execution when it is triggered.

break __schedule

cont
;T; I"# using GDB to debug L4Re and L4Linux GDB in conjunction with qemu can be used to debug L4Re applications and L4Linux ## configuring QEMU First, configure the qemu to automatically start the GDB server. To do this, add the “-s” switch to the parameters. When building L4Re, you can use the Makeconf.boot file to set up qemu. It must be located at `conf/Makeconf.boot` in the L4Re build directory. We can copy the one from the L4Re examples. You need to uncomment or add the following line to the Makeconf.boot: > QEMU_OPTIONS += -s ## connecting the debugger Next, launch the gdb. If your host machine has the architecture different to the one being debugged, set the correct architecture via “set architecture i386:x86_64”. Also, I had to install “gdb-multiarch” on my i386 debian system to be able to debug an amd64 kernel. > A good frontend for the GDB is CGDB (which uses ncurses) which displays both the command prompt and the source code. Now, when qemu is started, we can connect to it from gdb: target remote tcp::1234 ## loading symbols To allow gdb to display functions and variable names, we need to add the debugging symbols. To know the addresses for them, use objdump and look for the address of the first **LOAD** section. Luckily for us, by default each module is loaded to a different address, and physical addresses match virtual ones, so we can even debug across context switches. ~~~ add-symbol-file /mnt/disk2/work/l4linux/2git/git/build/fiasco.image 0 add-symbol-file /mnt/disk2/work/l4linux/2git/git/build_l4linux/vmlinux 0x400000 ~~~ ## using GDB Now, you can debug L4Re binaries and L4Linux as ordinary executables. For example, set up a breakpoint at some function and continue execution when it is triggered. ~~~ break __schedule cont ~~~;T; I"+

using GDB to debug L4Re and L4Linux

GDB in conjunction with qemu can be used to debug L4Re applications and L4Linux

configuring QEMU

First, configure the qemu to automatically start the GDB server. To do this, add the “-s” switch to the parameters. When building L4Re, you can use the Makeconf.boot file to set up qemu. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

You need to uncomment or add the following line to the Makeconf.boot: > QEMU_OPTIONS += -s

connecting the debugger

Next, launch the gdb. If your host machine has the architecture different to the one being debugged, set the correct architecture via “set architecture i386:x86_64”. Also, I had to install “gdb-multiarch” on my i386 debian system to be able to debug an amd64 kernel.

A good frontend for the GDB is CGDB (which uses ncurses) which displays both the command prompt and the source code.

Now, when qemu is started, we can connect to it from gdb: target remote tcp::1234

loading symbols

To allow gdb to display functions and variable names, we need to add the debugging symbols. To know the addresses for them, use objdump and look for the address of the first LOAD section. Luckily for us, by default each module is loaded to a different address, and physical addresses match virtual ones, so we can even debug across context switches.

add-symbol-file /mnt/disk2/work/l4linux/2git/git/build/fiasco.image 0
add-symbol-file /mnt/disk2/work/l4linux/2git/git/build_l4linux/vmlinux 0x400000

using GDB

Now, you can debug L4Re binaries and L4Linux as ordinary executables. For example, set up a breakpoint at some function and continue execution when it is triggered.

break __schedule

cont
;T; @zI"/nx_support_rus/;T{;{ ;I"0
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти. bash git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки. bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Подготовьте директории для сборки.

Для микроядра fiasco bash pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd

Для среды L4Re ``` pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Теперь можно приступить к настройке L4Re ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки. bash pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco. ``` pushd . cd “$L4LINUX_BUILDDIR” make menuconfig

echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска. bash cpio -i /path/to/ramdisk.img

Cоздание нового образа. ``` find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

компиляция тестовых утилит PaX для L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; I")$# сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти ## получение компилятора На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) "linux", а не под "none" (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor. https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## Исправление системы сборки L4Re По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл **L4Reap/l4/mk/Makeconf** необходимо заменить строку, в которой определена переменная `SYSTEM_TARGET_arm`. ``` ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ``` ## подготовка каталога для сборки Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux. > **Примечание:** В данном руководстве, такой директорией является `/mnt/disk2/l4_snapshot`. Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap ```bash git clone https://github.com/Ksys-labs/L4Reap.git ``` Переключите репозиторий на ветку с реализацией поддержки NX памяти. ```bash git checkout test-nx ``` Установите переменные среды, указывающие на директории для сброрки. ```bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ``` Подготовьте директории для сборки. Для микроядра fiasco ```bash pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd ``` Для среды L4Re ``` pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ``` ## сборка L4Re ### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните `make config` и установите настройки архитектуры. Можно также скопировать файл `.config` из примера. ```bash pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ``` Теперь можно приступить к настройке L4Re ```bash pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ``` ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в `conf/Makeconf.boot` в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона. ```bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ``` При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную `MODULE_SEARCH_PATH`. ```make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ``` Теперь, собрать все пакеты среды L4Re при помощи команды `make` в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент `S=`. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения `map_rwx` из пакета `ksys_mem_tests`. ```bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ``` ### создание образа u-boot для загрузки на устройстве (Pandaboard) ```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ``` ## сборка L4Linux Необходимо дополнительно собрать следующие пакеты среды L4Re: > io,libstdc++-v3,libvcpu,shmc Чтобы собрать L4Linux, сначала подготовим каталог для сборки. ```bash pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd ``` Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды `make menuconfig`. Также, необходимо указать в опциях конфигурации или добавлением строки в файл `.config` путь к каталогу сборки микроядра fiasco. ``` pushd . cd "$L4LINUX_BUILDDIR" make menuconfig echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ``` ### сборка начального RAMdisk Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ: ```bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ``` Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту `cpio`. Извлечение содержимого виртуального диска. ```bash cpio -i /path/to/ramdisk.img ``` Cоздание нового образа. ``` find . | cpio -o -H newc > /path/to/new_ramdisk.img ``` ## компиляция тестовых утилит PaX для L4Linux ``` tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ``` Теперь двоичные файлы доступны в каталоге pax_tests_l4linux. ;T; I"z'

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти. bash git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки. bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Подготовьте директории для сборки.

Для микроядра fiasco bash pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd

Для среды L4Re ``` pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Теперь можно приступить к настройке L4Re ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки. bash pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco. ``` pushd . cd “$L4LINUX_BUILDDIR” make menuconfig

echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска. bash cpio -i /path/to/ramdisk.img

Cоздание нового образа. ``` find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

компиляция тестовых утилит PaX для L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; @{I"/nx_support_eng/;T{;{ ;I""
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory: bash git checkout test-nx

Export the environment variables pointing to the build directories bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Prepare the build directories ```bash # for fiasco pushd . cd “${FOC_PATH}/kernel/fiasco/” make BUILDDIR=”$FOC_BUILDDIR” popd

for L4Re

pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Now, we can configure the L4Re. ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

creating the u-boot image for the target device

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux ```bash # create the l4linux build directory pushd . cd “$FOC_ROOT/l4linux” make O=”$L4LINUX_BUILDDIR” arm_defconfig popd

actually compile

pushd . cd “$L4LINUX_BUILDDIR” #you can configure the kernel now make menuconfig

#edit the config and set up the path to the fiasco build directory
echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following: ```bash #extract the ramdisk cpio -i /path/to/ramdisk.img

make a new image

find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

building PaX tests for L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; I"# building L4Re and L4Linux with NX memory support ## getting the compiler L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the "linux" toolchain as opposed to a "bare-metal" one. We have used the Sourcery Lite toolchain from Mentor https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## fixing L4Re makefile By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file **L4Reap/l4/mk/Makeconf** and replace the line containing the `SYSTEM_TARGET_arm` variable with the following. ``` ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ``` ## preparing build directory Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux. > **Note:** In the course of this manual, we assume that the directory is `/mnt/disk2/l4_snapshot`. Get source code from: https://github.com/Ksys-labs/L4Reap ```bash git clone https://github.com/Ksys-labs/L4Reap.git ``` Check out the branch with the support for the NX memory: ```bash git checkout test-nx ``` Export the environment variables pointing to the build directories ```bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ``` Prepare the build directories ```bash # for fiasco pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd # for L4Re pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ``` ## building L4Re ### building fiasco Go to the fiasco build directory, execute `make config` and set up architecture options. Sample configs for ARM and AMD64 are provided *TODO*. ```bash pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ``` Now, we can configure the L4Re. ```bash pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ``` ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at `conf/Makeconf.boot` in the L4Re build directory. We can copy the one from the L4Re examples. ```bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ``` When building a custom module, we may want to add the directory with the configuration scripts to the `MODULE_SEARCH_PATH` variable. ```make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ``` Now, you can either build all packages inside the L4Re build dir by just issuing the `make` command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the `make` command until it succeeds. Alternatively, you can build only the needed packages using the `S=` parameter. Here is a command to build everything you need to run the `map_rwx` test application from the `ksys_mem_tests` package: ```bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ``` ### creating the u-boot image for the target device ```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ``` ## building l4linux You will need to additionally build the following L4Re packages: > io,libstdc++-v3,libvcpu,shmc to compile l4linux ```bash # create the l4linux build directory pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd # actually compile pushd . cd "$L4LINUX_BUILDDIR" #you can configure the kernel now make menuconfig #edit the config and set up the path to the fiasco build directory echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ``` ### building initial RAMdisk You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from: ```bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ``` You may want to customize the contents of the ramdisk. To do so, you need to do the following: ```bash #extract the ramdisk cpio -i /path/to/ramdisk.img #make a new image find . | cpio -o -H newc > /path/to/new_ramdisk.img ``` ## building PaX tests for L4Linux ``` tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ``` Done, the binaries are in the pax_tests_l4linux directory. ;T; I"

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory: bash git checkout test-nx

Export the environment variables pointing to the build directories bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Prepare the build directories ```bash # for fiasco pushd . cd “${FOC_PATH}/kernel/fiasco/” make BUILDDIR=”$FOC_BUILDDIR” popd

for L4Re

pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Now, we can configure the L4Re. ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

creating the u-boot image for the target device

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux ```bash # create the l4linux build directory pushd . cd “$FOC_ROOT/l4linux” make O=”$L4LINUX_BUILDDIR” arm_defconfig popd

actually compile

pushd . cd “$L4LINUX_BUILDDIR” #you can configure the kernel now make menuconfig

#edit the config and set up the path to the fiasco build directory
echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following: ```bash #extract the ramdisk cpio -i /path/to/ramdisk.img

make a new image

find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

building PaX tests for L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; @I"/hardenning_eng/;T{;{ ;I""
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory: bash git checkout test-nx

Export the environment variables pointing to the build directories bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Prepare the build directories ```bash # for fiasco pushd . cd “${FOC_PATH}/kernel/fiasco/” make BUILDDIR=”$FOC_BUILDDIR” popd

for L4Re

pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Now, we can configure the L4Re. ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

creating the u-boot image for the target device

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux ```bash # create the l4linux build directory pushd . cd “$FOC_ROOT/l4linux” make O=”$L4LINUX_BUILDDIR” arm_defconfig popd

actually compile

pushd . cd “$L4LINUX_BUILDDIR” #you can configure the kernel now make menuconfig

#edit the config and set up the path to the fiasco build directory
echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following: ```bash #extract the ramdisk cpio -i /path/to/ramdisk.img

make a new image

find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

building PaX tests for L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; I"# building L4Re and L4Linux with NX memory support ## getting the compiler L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the "linux" toolchain as opposed to a "bare-metal" one. We have used the Sourcery Lite toolchain from Mentor https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## fixing L4Re makefile By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file **L4Reap/l4/mk/Makeconf** and replace the line containing the `SYSTEM_TARGET_arm` variable with the following. ``` ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ``` ## preparing build directory Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux. > **Note:** In the course of this manual, we assume that the directory is `/mnt/disk2/l4_snapshot`. Get source code from: https://github.com/Ksys-labs/L4Reap ```bash git clone https://github.com/Ksys-labs/L4Reap.git ``` Check out the branch with the support for the NX memory: ```bash git checkout test-nx ``` Export the environment variables pointing to the build directories ```bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ``` Prepare the build directories ```bash # for fiasco pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd # for L4Re pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ``` ## building L4Re ### building fiasco Go to the fiasco build directory, execute `make config` and set up architecture options. Sample configs for ARM and AMD64 are provided *TODO*. ```bash pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ``` Now, we can configure the L4Re. ```bash pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ``` ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at `conf/Makeconf.boot` in the L4Re build directory. We can copy the one from the L4Re examples. ```bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ``` When building a custom module, we may want to add the directory with the configuration scripts to the `MODULE_SEARCH_PATH` variable. ```make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ``` Now, you can either build all packages inside the L4Re build dir by just issuing the `make` command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the `make` command until it succeeds. Alternatively, you can build only the needed packages using the `S=` parameter. Here is a command to build everything you need to run the `map_rwx` test application from the `ksys_mem_tests` package: ```bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ``` ### creating the u-boot image for the target device ```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ``` ## building l4linux You will need to additionally build the following L4Re packages: > io,libstdc++-v3,libvcpu,shmc to compile l4linux ```bash # create the l4linux build directory pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd # actually compile pushd . cd "$L4LINUX_BUILDDIR" #you can configure the kernel now make menuconfig #edit the config and set up the path to the fiasco build directory echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ``` ### building initial RAMdisk You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from: ```bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ``` You may want to customize the contents of the ramdisk. To do so, you need to do the following: ```bash #extract the ramdisk cpio -i /path/to/ramdisk.img #make a new image find . | cpio -o -H newc > /path/to/new_ramdisk.img ``` ## building PaX tests for L4Linux ``` tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ``` Done, the binaries are in the pax_tests_l4linux directory. ;T; I"

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory: bash git checkout test-nx

Export the environment variables pointing to the build directories bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Prepare the build directories ```bash # for fiasco pushd . cd “${FOC_PATH}/kernel/fiasco/” make BUILDDIR=”$FOC_BUILDDIR” popd

for L4Re

pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Now, we can configure the L4Re. ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

creating the u-boot image for the target device

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux ```bash # create the l4linux build directory pushd . cd “$FOC_ROOT/l4linux” make O=”$L4LINUX_BUILDDIR” arm_defconfig popd

actually compile

pushd . cd “$L4LINUX_BUILDDIR” #you can configure the kernel now make menuconfig

#edit the config and set up the path to the fiasco build directory
echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following: ```bash #extract the ramdisk cpio -i /path/to/ramdisk.img

make a new image

find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

building PaX tests for L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; @I"/hardenning_rus/;T{;{ ;I"0
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти. bash git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки. bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Подготовьте директории для сборки.

Для микроядра fiasco bash pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd

Для среды L4Re ``` pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Теперь можно приступить к настройке L4Re ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки. bash pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco. ``` pushd . cd “$L4LINUX_BUILDDIR” make menuconfig

echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска. bash cpio -i /path/to/ramdisk.img

Cоздание нового образа. ``` find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

компиляция тестовых утилит PaX для L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; I")$# сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти ## получение компилятора На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) "linux", а не под "none" (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor. https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## Исправление системы сборки L4Re По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл **L4Reap/l4/mk/Makeconf** необходимо заменить строку, в которой определена переменная `SYSTEM_TARGET_arm`. ``` ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ``` ## подготовка каталога для сборки Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux. > **Примечание:** В данном руководстве, такой директорией является `/mnt/disk2/l4_snapshot`. Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap ```bash git clone https://github.com/Ksys-labs/L4Reap.git ``` Переключите репозиторий на ветку с реализацией поддержки NX памяти. ```bash git checkout test-nx ``` Установите переменные среды, указывающие на директории для сброрки. ```bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ``` Подготовьте директории для сборки. Для микроядра fiasco ```bash pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd ``` Для среды L4Re ``` pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ``` ## сборка L4Re ### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните `make config` и установите настройки архитектуры. Можно также скопировать файл `.config` из примера. ```bash pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ``` Теперь можно приступить к настройке L4Re ```bash pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ``` ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в `conf/Makeconf.boot` в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона. ```bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ``` При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную `MODULE_SEARCH_PATH`. ```make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ``` Теперь, собрать все пакеты среды L4Re при помощи команды `make` в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент `S=`. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения `map_rwx` из пакета `ksys_mem_tests`. ```bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ``` ### создание образа u-boot для загрузки на устройстве (Pandaboard) ```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ``` ## сборка L4Linux Необходимо дополнительно собрать следующие пакеты среды L4Re: > io,libstdc++-v3,libvcpu,shmc Чтобы собрать L4Linux, сначала подготовим каталог для сборки. ```bash pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd ``` Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды `make menuconfig`. Также, необходимо указать в опциях конфигурации или добавлением строки в файл `.config` путь к каталогу сборки микроядра fiasco. ``` pushd . cd "$L4LINUX_BUILDDIR" make menuconfig echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ``` ### сборка начального RAMdisk Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ: ```bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ``` Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту `cpio`. Извлечение содержимого виртуального диска. ```bash cpio -i /path/to/ramdisk.img ``` Cоздание нового образа. ``` find . | cpio -o -H newc > /path/to/new_ramdisk.img ``` ## компиляция тестовых утилит PaX для L4Linux ``` tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ``` Теперь двоичные файлы доступны в каталоге pax_tests_l4linux. ;T; I"z'

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm. ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

bash git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти. bash git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки. bash export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" Подготовьте директории для сборки.

Для микроядра fiasco bash pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd

Для среды L4Re ``` pushd . cd “${FOC_PATH}/l4” make B=”$L4RE_BUILDDIR” popd

```

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера. ```bash pushd . cd “$FOC_BUILDDIR” make config make “$MAKE_OPTS” popd

```

Теперь можно приступить к настройке L4Re ```bash pushd . cd “${FOC_PATH}/l4” make O=”$L4RE_BUILDDIR” config popd

``` ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

bash pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

make MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

bash pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

```bash make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

# copy the uimage to the device or the TFTP server or whatever
cp images/bootstrap.uimage /srv/tftp/panda/uImage ```

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки. bash pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco. ``` pushd . cd “$L4LINUX_BUILDDIR” make menuconfig

echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm"  popd ```

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

bash pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска. bash cpio -i /path/to/ramdisk.img

Cоздание нового образа. ``` find . | cpio -o -H newc > /path/to/new_ramdisk.img

```

компиляция тестовых утилит PaX для L4Linux

tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; @I"/ukernels/lab/;T{;{ ;I"O

Проверка подписи загружаемых модулей в Genode

Цель

Реализовать прототип модуля init с функцией контроля целостности загружаемых модулей используя механизм электронной цифровой подписи (ЭЦП). Ознакомится с процессом загрузки ОС, принципами формирования ЭЦП и интегрировать полученные инструменты в систему сборки.

1. Общая информация

Для начала разберемся, что представляет собой ЭЦП [1]:

Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. Использование электронной подписи позволяет осуществить:
- Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему.
- Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев.
- Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом.
- Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.

Для реализации ЭЦП наиболее часто используются асимметричные криптографические алгоритмы. Для подписи генерируются пара ключей: открытый и закрытый. Подпись и проверка выполняются в соответствие со следующей структурной схемой: By Acdx (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons"

Исходя из этого к ключам предъявляются следующие требования:

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

В качестве алгоритмов используемых для ЭЦП в России рекомендуется применять ГОСТ Р 34.10-2012 [2] и ГОСТ Р 34/11-2012 [3] в качестве хеш-функции. В данной лабораторной работе рекомендованными алгоритмами являются ECDSA и SHA256 в качестве хеш-функции. В репозитории sss13 добавлены сторонние открытые библиотеки, реализующие данные алгоритмы micro-ecc [4] и SHA2 [5]. Открытый GOST engine из OpenSSL не использован по причине не возможности динамической линковки процесса init.

В качестве платформы будем использовать Fiasco.OC (base-foc) для архитектуры x86_32. На самом деле мы не будем добавлять никакого платформо-специфичного кода, но формирование загрузочного образа в системе сборки является платформо-зависимым.

Рассмотрим загрузку образа, построенного на базе Genode+Fiasco.OC более подробно:

  1. Загружается загрузчик, в нашем случае GRUB, все модули, указанные в конфигурационном файле загрузчика, загружаются в соответствии со спецификацией Multiboot. Управление передается модулю bootstrap.
  2. bootstrap выполняет часть операций необходимых для старта ядра, такие как:
    • сканирование доступной памяти;
    • перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить);
    • и непосредственно запуск ядра.
  3. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task.
  4. Начинает выполняться модуль core (являющийся root task в Genode), который инициализирует сервисы Genode и запускает модуль init
  5. init последовательно загружает указанные в конфигурации модули (файл config) и запускает их выполнение.

Более подробно модуль init и создании процессов в Genode были рассмотрены в лекции “Genode Architecture”[6] прошлогодней летней школы и в статье “Configuring the init process of Genode”[7] в разделе документации на сайте Genode.

3. Порядок выполнения и рекомендации

  1. Для начала работы необходимо подготовить окружение:
    • форкнуть наш репозиторий на GitHub
    • переключиться на ветку sss13_lab
    • подготовить библиотеки:
      make prepare -C libport PKG=libc
      make prepare -C sss13

    В данном репозитории уже выполнена предварительная подготовка системы сборки и исходного кода. “Заготовка” утилиты для подписи с использованием рекомендованных библиотек находится в sss13/tools/signtools, там же находятся утилиты для добавления значения подписи в конфигурационный файл и генерации ключей.
    Оригинальный исходный код init находится в директориях os/src/init и os/include/init. Для данной работы заготовка исходного кода, скопирована в директории sss13/src/initsig и sss13/include/initsig. Этот исходный код будет использоваться в дальнейшем описании.

  2. Добавить расчет подписи для каждого исполняемого модуля и добавление полученного хеша в конфигурацию на этапе создания образа.
    Необходимо доработать утилиту для подписи sss13/tool/signtools/signfile.ccх[^8]. Эта утилита должна получать на входе имя файла с данными для подписи и имя файла с содержимым закрытыго ключа и выводить в stdout значение подписи в виде строки. Это значение при сборке, с помощью утилиты signfile.py будет вставлено в конфигурационный файл.
    Доступ к загруженным загрузчиком файлам для Genode осуществляется через ROM Session. Но для dataspace, относящегося к открытому файлу, невозможно получить реальный размер файла, размер dataspace всегда кратен размеру страницы памяти (4096 байт). Поэтому для получения хеша, размер файла должен быть дополнен нулями до размера кратного размеру страницы и затем вычислен хеш.
    Используя полученный хеш и закрытый ключ получить подпись. Подпись добавляется в конфигурационный файл на этапе сборки в виде <signature value="xxx">. Пример:
    <start name="timer">
    <resource name="RAM" quantum="20M" />
    <provides><service name="Timer" /></provides>
    <signature value="bc8d2e767f7da92b6216796eaff7ec3883597da0f751b5248baa1dae763a17bfc52b72280b3a74c49ba9c0e459adc3d72d0af58622a60440018d3f0713028650" />
    </start>

  3. Добавить проверку подписи в init
    Для начала рассмотрим исходный код модуля initsig более подробно. Модуль initsig (sss13/src/initsig/main.cc [9]) выполняет следующие действия:
    • инициализацию динамического линкера, если найден ld.lib.so (строки 154-157);
    • регистрацию сигнала, используемого для уведомления init-а об изменении конфигурации (строки 167-169);
    • определение роутинга сервисов (строки 178-186);
    • и создание потомков (строки 188-219), заканчивающееся параллельным стартом всех потомков;
    • оставшийся код отвечает за перезапуск потомков, в случае изменения конфигурации на лету.

    В данный код добавлена обработка исключения InitSig::Child::Signature_failed, которое должен генерировать класс InitSig::Child в случае каких-либо ошибок при проверке ЭЦП.
    За создание потомка отвечает класс InitSig::Child [10], который непосредственно создает процесс, именно в его конструктор стоит добавить проверку ЭЦП. Рассмотрим этот код и определим функционал, который необходимо реализовать:
    - получение значения сигнатуры из конфигурационного файла для данного модуля (строки 486-502);
    - конвертирование сигнатуры из строки в бинарный вид, пригодный для дальнейшего использование в проверке (необходимо реализовать, заготовка в строках 504-506);
    - получение указателя на данные модуля и его длину (необходимо реализовать, строки 508-510);
    - расчет хеша для данных загружаемого модуля (необходимо реализовать, строки 512-514);
    - проверка ЭЦП (необходимо реализовать, строки 522-523);
    - в случае успешной проверки ЭЦП производится создание нового модуля (строки 527-528).

    Открытый ключ в рамках этой лабораторной работы может быть просто вкомпилен в init (sss13/src/initsig/main.cc строка 19).

  4. Тестирование
    • подготовить сборочную директорию для платформы foc_x86_32 и перейти в нее;
    • подключить репозитории libport и sss13;
    • включить генерацию ЭЦП используя спек sign: echo 'SPECS += sign' >> etc/specs.conf;
    • собрать утилиты signtools: make -C ../sss13/tool/signtools
    • установить утилиты в директорию bin: PREFIX=`pwd`/bin make install -C ../sss13/tool/signtool
    • запустить скрипт lab.run: make run/lab;
    • убедиться что проверка подписей работает и подписи валидны;
    • изменить содержимое файла hackme, запустить руками и убедиться, что подпись не сходится:
      cd var/run/
      dhex lab/genode/hackme
      ../../../tool/create_iso iso ISO=lab
      qemu-system-i386 -no-kvm -m 64 -nographic -cdrom lab.iso
    • исправить подпись в конфигурации для измененного файла и проверить еще раз.
  5. Выводы
    Сделать выводы по работе, а именно, какие проблемы имеет эта реализация? Что нужно доработать, чтобы использовать такую реализацию в реальных применениях, какие еще могут быть варианты контроля целостности загружаемых модулей для Genode?

Ссылки

[1]: http://ru.wikipedia.org/wiki/Электронная_подпись
[2]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012)
[3]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012)
[4]: https://github.com/kmackay/micro-ecc
[5]: http://www.aarongifford.com/computers/sha.html
[6]: http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/
[7]: http://genode.org/documentation/developer-resources/init
[8]: тут будет ссылка на гитхаб
[9]: тут будет ссылка на гитхаб
[10]: тут будет ссылка на гитхаб

;T; I"pA##Проверка подписи загружаемых модулей в Genode## ###Цель### Реализовать прототип модуля init с функцией контроля целостности загружаемых модулей используя механизм электронной цифровой подписи (ЭЦП). Ознакомится с процессом загрузки ОС, принципами формирования ЭЦП и интегрировать полученные инструменты в систему сборки. ###1. Общая информация### Для начала разберемся, что представляет собой ЭЦП \[1\]: > Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. > Использование электронной подписи позволяет осуществить: > - Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему. > - Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев. > - Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом. > - Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д. Для реализации ЭЦП наиболее часто используются асимметричные криптографические алгоритмы. Для подписи генерируются пара ключей: открытый и закрытый. Подпись и проверка выполняются в соответствие со следующей структурной схемой: ![By Acdx (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons" ](http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/512px-Digital_Signature_diagram.svg.png) Исходя из этого к ключам предъявляются следующие требования: - закрытый ключ должен надежно храниться у производителя ПО. Именно им производится подпись модулей. - открытый ключ сохраняется в устройстве. Нет необходимости защищать этот ключ от чтения, но важно обеспечить не возможность перезаписи открытого ключа. В качестве алгоритмов используемых для ЭЦП в России рекомендуется применять ГОСТ Р 34.10-2012 \[2\] и ГОСТ Р 34/11-2012 \[3\] в качестве хеш-функции. В данной лабораторной работе рекомендованными алгоритмами являются ECDSA и SHA256 в качестве хеш-функции. В репозитории sss13 добавлены сторонние открытые библиотеки, реализующие данные алгоритмы micro-ecc \[4\] и SHA2 \[5\]. Открытый GOST engine из OpenSSL не использован по причине не возможности динамической линковки процесса init. В качестве платформы будем использовать Fiasco.OC (base-foc) для архитектуры x86_32. На самом деле мы не будем добавлять никакого платформо-специфичного кода, но формирование загрузочного образа в системе сборки является платформо-зависимым. Рассмотрим загрузку образа, построенного на базе Genode+Fiasco.OC более подробно: 1. Загружается загрузчик, в нашем случае GRUB, все модули, указанные в конфигурационном файле загрузчика, загружаются в соответствии со спецификацией Multiboot. Управление передается модулю bootstrap. 2. bootstrap выполняет часть операций необходимых для старта ядра, такие как: - сканирование доступной памяти; - перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить); - и непосредственно запуск ядра. 3. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task. 4. Начинает выполняться модуль core (являющийся root task в Genode), который инициализирует сервисы Genode и запускает модуль init 5. init последовательно загружает указанные в конфигурации модули (файл config) и запускает их выполнение. ![](http://genode.org/documentation/developer-resources/img/setup.png) Более подробно модуль init и создании процессов в Genode были рассмотрены в лекции "Genode Architecture"\[6\] прошлогодней летней школы и в статье "Configuring the init process of Genode"\[7\] в разделе документации на сайте Genode. ###3. Порядок выполнения и рекомендации### 1. Для начала работы необходимо подготовить окружение: * форкнуть наш репозиторий на GitHub * переключиться на ветку ``sss13_lab`` * подготовить библиотеки: ``make prepare -C libport PKG=libc`` ``make prepare -C sss13`` В данном репозитории уже выполнена предварительная подготовка системы сборки и исходного кода. "Заготовка" утилиты для подписи с использованием рекомендованных библиотек находится в sss13/tools/signtools, там же находятся утилиты для добавления значения подписи в конфигурационный файл и генерации ключей. Оригинальный исходный код init находится в директориях os/src/init и os/include/init. Для данной работы заготовка исходного кода, скопирована в директории sss13/src/initsig и sss13/include/initsig. Этот исходный код будет использоваться в дальнейшем описании. 2. Добавить расчет подписи для каждого исполняемого модуля и добавление полученного хеша в конфигурацию на этапе создания образа. Необходимо доработать утилиту для подписи sss13/tool/signtools/signfile.ccх[^8]. Эта утилита должна получать на входе имя файла с данными для подписи и имя файла с содержимым закрытыго ключа и выводить в stdout значение подписи в виде строки. Это значение при сборке, с помощью утилиты signfile.py будет вставлено в конфигурационный файл. Доступ к загруженным загрузчиком файлам для Genode осуществляется через ROM Session. Но для dataspace, относящегося к открытому файлу, невозможно получить реальный размер файла, размер dataspace всегда кратен размеру страницы памяти (4096 байт). Поэтому для получения хеша, размер файла должен быть дополнен нулями до размера кратного размеру страницы и затем вычислен хеш. Используя полученный хеш и закрытый ключ получить подпись. Подпись добавляется в конфигурационный файл на этапе сборки в виде ````. Пример: ```` `` `` `` `` `` `` ```` 3. Добавить проверку подписи в init Для начала рассмотрим исходный код модуля initsig более подробно. Модуль initsig (sss13/src/initsig/main.cc \[9\]) выполняет следующие действия: - инициализацию динамического линкера, если найден ld.lib.so (строки 154-157); - регистрацию сигнала, используемого для уведомления init-а об изменении конфигурации (строки 167-169); - определение роутинга сервисов (строки 178-186); - и создание потомков (строки 188-219), заканчивающееся параллельным стартом всех потомков; - оставшийся код отвечает за перезапуск потомков, в случае изменения конфигурации на лету. В данный код добавлена обработка исключения InitSig::Child::Signature_failed, которое должен генерировать класс InitSig::Child в случае каких-либо ошибок при проверке ЭЦП. За создание потомка отвечает класс InitSig::Child \[10\], который непосредственно создает процесс, именно в его конструктор стоит добавить проверку ЭЦП. Рассмотрим этот код и определим функционал, который необходимо реализовать: - получение значения сигнатуры из конфигурационного файла для данного модуля (строки 486-502); - конвертирование сигнатуры из строки в бинарный вид, пригодный для дальнейшего использование в проверке (**необходимо реализовать**, заготовка в строках 504-506); - получение указателя на данные модуля и его длину (**необходимо реализовать**, строки 508-510); - расчет хеша для данных загружаемого модуля (**необходимо реализовать**, строки 512-514); - проверка ЭЦП (**необходимо реализовать**, строки 522-523); - в случае успешной проверки ЭЦП производится создание нового модуля (строки 527-528). Открытый ключ в рамках этой лабораторной работы может быть просто вкомпилен в init (sss13/src/initsig/main.cc строка 19). 4. Тестирование - подготовить сборочную директорию для платформы foc_x86_32 и перейти в нее; - подключить репозитории libport и sss13; - включить генерацию ЭЦП используя спек sign: ``echo 'SPECS += sign' >> etc/specs.conf``; - собрать утилиты signtools: ``make -C ../sss13/tool/signtools`` - установить утилиты в директорию bin: ``PREFIX=`pwd`/bin make install -C ../sss13/tool/signtool`` - запустить скрипт lab.run: ``make run/lab``; - убедиться что проверка подписей работает и подписи валидны; - изменить содержимое файла hackme, запустить руками и убедиться, что подпись не сходится: ``cd var/run/`` ``dhex lab/genode/hackme`` ``../../../tool/create_iso iso ISO=lab`` ``qemu-system-i386 -no-kvm -m 64 -nographic -cdrom lab.iso`` - исправить подпись в конфигурации для измененного файла и проверить еще раз. 5. Выводы Сделать выводы по работе, а именно, какие проблемы имеет эта реализация? Что нужно доработать, чтобы использовать такую реализацию в реальных применениях, какие еще могут быть варианты контроля целостности загружаемых модулей для Genode? ### Ссылки ### \[1\]: [http://ru.wikipedia.org/wiki/Электронная_подпись](http://ru.wikipedia.org/wiki/Электронная_подпись) \[2\]: [http://ru.wikipedia.org/wiki/ГОСТ_Р_34.10-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р_34.10-2012) \[3\]: [http://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р_34.11-2012) \[4\]: [https://github.com/kmackay/micro-ecc](https://github.com/kmackay/micro-ecc) \[5\]: [http://www.aarongifford.com/computers/sha.html](http://www.aarongifford.com/computers/sha.html) \[6\]: [http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/](http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/) \[7\]: [http://genode.org/documentation/developer-resources/init](http://genode.org/documentation/developer-resources/init) \[8\]: тут будет ссылка на гитхаб \[9\]: тут будет ссылка на гитхаб \[10\]: тут будет ссылка на гитхаб ;T; I"%E

Проверка подписи загружаемых модулей в Genode

Цель

Реализовать прототип модуля init с функцией контроля целостности загружаемых модулей используя механизм электронной цифровой подписи (ЭЦП). Ознакомится с процессом загрузки ОС, принципами формирования ЭЦП и интегрировать полученные инструменты в систему сборки.

1. Общая информация

Для начала разберемся, что представляет собой ЭЦП [1]:

Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. Использование электронной подписи позволяет осуществить:
- Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему.
- Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев.
- Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом.
- Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.

Для реализации ЭЦП наиболее часто используются асимметричные криптографические алгоритмы. Для подписи генерируются пара ключей: открытый и закрытый. Подпись и проверка выполняются в соответствие со следующей структурной схемой: By Acdx (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0) or GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons"

Исходя из этого к ключам предъявляются следующие требования:

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

В качестве алгоритмов используемых для ЭЦП в России рекомендуется применять ГОСТ Р 34.10-2012 [2] и ГОСТ Р 34/11-2012 [3] в качестве хеш-функции. В данной лабораторной работе рекомендованными алгоритмами являются ECDSA и SHA256 в качестве хеш-функции. В репозитории sss13 добавлены сторонние открытые библиотеки, реализующие данные алгоритмы micro-ecc [4] и SHA2 [5]. Открытый GOST engine из OpenSSL не использован по причине не возможности динамической линковки процесса init.

В качестве платформы будем использовать Fiasco.OC (base-foc) для архитектуры x86_32. На самом деле мы не будем добавлять никакого платформо-специфичного кода, но формирование загрузочного образа в системе сборки является платформо-зависимым.

Рассмотрим загрузку образа, построенного на базе Genode+Fiasco.OC более подробно:

  1. Загружается загрузчик, в нашем случае GRUB, все модули, указанные в конфигурационном файле загрузчика, загружаются в соответствии со спецификацией Multiboot. Управление передается модулю bootstrap.
  2. bootstrap выполняет часть операций необходимых для старта ядра, такие как:
    • сканирование доступной памяти;
    • перемещение модулей в памяти (sigma0 и root task должны быть расположены в определенных регионах, чтобы ядро при старте могло их запустить);
    • и непосредственно запуск ядра.
  3. Ядро выполняет необходимую инициализацию системы, запускает sigma0 и root task.
  4. Начинает выполняться модуль core (являющийся root task в Genode), который инициализирует сервисы Genode и запускает модуль init
  5. init последовательно загружает указанные в конфигурации модули (файл config) и запускает их выполнение.

Более подробно модуль init и создании процессов в Genode были рассмотрены в лекции “Genode Architecture”[6] прошлогодней летней школы и в статье “Configuring the init process of Genode”[7] в разделе документации на сайте Genode.

3. Порядок выполнения и рекомендации

  1. Для начала работы необходимо подготовить окружение:
    • форкнуть наш репозиторий на GitHub
    • переключиться на ветку sss13_lab
    • подготовить библиотеки:
      make prepare -C libport PKG=libc
      make prepare -C sss13

    В данном репозитории уже выполнена предварительная подготовка системы сборки и исходного кода. “Заготовка” утилиты для подписи с использованием рекомендованных библиотек находится в sss13/tools/signtools, там же находятся утилиты для добавления значения подписи в конфигурационный файл и генерации ключей.
    Оригинальный исходный код init находится в директориях os/src/init и os/include/init. Для данной работы заготовка исходного кода, скопирована в директории sss13/src/initsig и sss13/include/initsig. Этот исходный код будет использоваться в дальнейшем описании.

  2. Добавить расчет подписи для каждого исполняемого модуля и добавление полученного хеша в конфигурацию на этапе создания образа.
    Необходимо доработать утилиту для подписи sss13/tool/signtools/signfile.ccх[^8]. Эта утилита должна получать на входе имя файла с данными для подписи и имя файла с содержимым закрытыго ключа и выводить в stdout значение подписи в виде строки. Это значение при сборке, с помощью утилиты signfile.py будет вставлено в конфигурационный файл.
    Доступ к загруженным загрузчиком файлам для Genode осуществляется через ROM Session. Но для dataspace, относящегося к открытому файлу, невозможно получить реальный размер файла, размер dataspace всегда кратен размеру страницы памяти (4096 байт). Поэтому для получения хеша, размер файла должен быть дополнен нулями до размера кратного размеру страницы и затем вычислен хеш.
    Используя полученный хеш и закрытый ключ получить подпись. Подпись добавляется в конфигурационный файл на этапе сборки в виде <signature value="xxx">. Пример:
    <start name="timer">
    <resource name="RAM" quantum="20M" />
    <provides><service name="Timer" /></provides>
    <signature value="bc8d2e767f7da92b6216796eaff7ec3883597da0f751b5248baa1dae763a17bfc52b72280b3a74c49ba9c0e459adc3d72d0af58622a60440018d3f0713028650" />
    </start>

  3. Добавить проверку подписи в init
    Для начала рассмотрим исходный код модуля initsig более подробно. Модуль initsig (sss13/src/initsig/main.cc [9]) выполняет следующие действия:
    • инициализацию динамического линкера, если найден ld.lib.so (строки 154-157);
    • регистрацию сигнала, используемого для уведомления init-а об изменении конфигурации (строки 167-169);
    • определение роутинга сервисов (строки 178-186);
    • и создание потомков (строки 188-219), заканчивающееся параллельным стартом всех потомков;
    • оставшийся код отвечает за перезапуск потомков, в случае изменения конфигурации на лету.

    В данный код добавлена обработка исключения InitSig::Child::Signature_failed, которое должен генерировать класс InitSig::Child в случае каких-либо ошибок при проверке ЭЦП.
    За создание потомка отвечает класс InitSig::Child [10], который непосредственно создает процесс, именно в его конструктор стоит добавить проверку ЭЦП. Рассмотрим этот код и определим функционал, который необходимо реализовать:
    - получение значения сигнатуры из конфигурационного файла для данного модуля (строки 486-502);
    - конвертирование сигнатуры из строки в бинарный вид, пригодный для дальнейшего использование в проверке (необходимо реализовать, заготовка в строках 504-506);
    - получение указателя на данные модуля и его длину (необходимо реализовать, строки 508-510);
    - расчет хеша для данных загружаемого модуля (необходимо реализовать, строки 512-514);
    - проверка ЭЦП (необходимо реализовать, строки 522-523);
    - в случае успешной проверки ЭЦП производится создание нового модуля (строки 527-528).

    Открытый ключ в рамках этой лабораторной работы может быть просто вкомпилен в init (sss13/src/initsig/main.cc строка 19).

  4. Тестирование
    • подготовить сборочную директорию для платформы foc_x86_32 и перейти в нее;
    • подключить репозитории libport и sss13;
    • включить генерацию ЭЦП используя спек sign: echo 'SPECS += sign' >> etc/specs.conf;
    • собрать утилиты signtools: make -C ../sss13/tool/signtools
    • установить утилиты в директорию bin: PREFIX=`pwd`/bin make install -C ../sss13/tool/signtool
    • запустить скрипт lab.run: make run/lab;
    • убедиться что проверка подписей работает и подписи валидны;
    • изменить содержимое файла hackme, запустить руками и убедиться, что подпись не сходится:
      cd var/run/
      dhex lab/genode/hackme
      ../../../tool/create_iso iso ISO=lab
      qemu-system-i386 -no-kvm -m 64 -nographic -cdrom lab.iso
    • исправить подпись в конфигурации для измененного файла и проверить еще раз.
  5. Выводы
    Сделать выводы по работе, а именно, какие проблемы имеет эта реализация? Что нужно доработать, чтобы использовать такую реализацию в реальных применениях, какие еще могут быть варианты контроля целостности загружаемых модулей для Genode?

Ссылки

[1]: http://ru.wikipedia.org/wiki/Электронная_подпись
[2]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.10-2012)
[3]: [http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012](http://ru.wikipedia.org/wiki/ГОСТ_Р34.11-2012)
[4]: https://github.com/kmackay/micro-ecc
[5]: http://www.aarongifford.com/computers/sha.html
[6]: http://sss.ksyslabs.org/ru/prev/sss-12/genode-architecture/
[7]: http://genode.org/documentation/developer-resources/init
[8]: тут будет ссылка на гитхаб
[9]: тут будет ссылка на гитхаб
[10]: тут будет ссылка на гитхаб

;T; @I"/ukernels/hardenning_eng/;T{;{ ;I"C' Building L4Re and L4Linux with NX memory support
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory:

git checkout test-nx

Export the environment variables pointing to the build directories

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Prepare the build directories

# for fiasco
pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

# for L4Re
pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Now, we can configure the L4Re.

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

creating Makeconf.boot

It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

creating the u-boot image for the target device

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux

# create the l4linux build directory
pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

# actually compile
pushd .
        cd "$L4LINUX_BUILDDIR"
        #you can configure the kernel now
        make menuconfig

        #edit the config and set up the path to the fiasco build directory
        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following:

#extract the ramdisk
cpio -i /path/to/ramdisk.img

#make a new image
find . | cpio -o -H newc > /path/to/new_ramdisk.img

building PaX tests for L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; I"# building L4Re and L4Linux with NX memory support ## getting the compiler L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the "linux" toolchain as opposed to a "bare-metal" one. We have used the Sourcery Lite toolchain from Mentor https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## fixing L4Re makefile By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file **L4Reap/l4/mk/Makeconf** and replace the line containing the `SYSTEM_TARGET_arm` variable with the following. ~~~ ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ~~~ ## preparing build directory Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux. > **Note:** In the course of this manual, we assume that the directory is `/mnt/disk2/l4_snapshot`. Get source code from: https://github.com/Ksys-labs/L4Reap ~~~ git clone https://github.com/Ksys-labs/L4Reap.git ~~~ {:.language-bash} Check out the branch with the support for the NX memory: ~~~ git checkout test-nx ~~~ {:.language-bash} Export the environment variables pointing to the build directories ~~~ export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ~~~ {:.language-bash} Prepare the build directories ~~~ # for fiasco pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd # for L4Re pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ~~~ {:.language-bash} ## building L4Re ### building fiasco Go to the fiasco build directory, execute `make config` and set up architecture options. Sample configs for ARM and AMD64 are provided *TODO*. ~~~ pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ~~~ {:.language-bash} Now, we can configure the L4Re. ~~~ pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ~~~ {:.language-bash} ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at `conf/Makeconf.boot` in the L4Re build directory. We can copy the one from the L4Re examples. ~~~ pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ~~~ {:.language-bash} When building a custom module, we may want to add the directory with the configuration scripts to the `MODULE_SEARCH_PATH` variable. ~~~ MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ~~~ {:.language-make} Now, you can either build all packages inside the L4Re build dir by just issuing the `make` command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the `make` command until it succeeds. Alternatively, you can build only the needed packages using the `S=` parameter. Here is a command to build everything you need to run the `map_rwx` test application from the `ksys_mem_tests` package: ~~~ pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ~~~ {:.language-bash} ### creating the u-boot image for the target device ~~~ make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ~~~ {:.language-bash} ## building l4linux You will need to additionally build the following L4Re packages: > io,libstdc++-v3,libvcpu,shmc to compile l4linux ~~~ # create the l4linux build directory pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd # actually compile pushd . cd "$L4LINUX_BUILDDIR" #you can configure the kernel now make menuconfig #edit the config and set up the path to the fiasco build directory echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ~~~ {:.language-bash} ### building initial RAMdisk You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from: ~~~ pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ~~~ {:.language-bash} You may want to customize the contents of the ramdisk. To do so, you need to do the following: ~~~ #extract the ramdisk cpio -i /path/to/ramdisk.img #make a new image find . | cpio -o -H newc > /path/to/new_ramdisk.img ~~~ {:.language-bash} ## building PaX tests for L4Linux ~~~ tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ~~~ {:.language-bash} Done, the binaries are in the pax_tests_l4linux directory.;T; I"~

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory:

git checkout test-nx

Export the environment variables pointing to the build directories

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Prepare the build directories

# for fiasco
pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

# for L4Re
pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Now, we can configure the L4Re.

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

creating Makeconf.boot

It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

creating the u-boot image for the target device

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux

# create the l4linux build directory
pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

# actually compile
pushd .
        cd "$L4LINUX_BUILDDIR"
        #you can configure the kernel now
        make menuconfig

        #edit the config and set up the path to the fiasco build directory
        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following:

#extract the ramdisk
cpio -i /path/to/ramdisk.img

#make a new image
find . | cpio -o -H newc > /path/to/new_ramdisk.img

building PaX tests for L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; @I"/ukernels/l4reap/;T{;{ ;I" L4Reap, L4Re (additionl) aPplications

text

We’ve ported and customized several software projects to run on top of L4Re.

L4Reap Repository

The list of software includes:

  • freetype2
  • libsigc++
  • libwhefs
  • libxml2
  • openssl
  • disko

Enhancements:

  • Buffer overflow protection
;T; I"I![text](/upload/reaping-mach_25922_sm.gif) We've ported and customized several software projects to run on top of L4Re. [L4Reap Repository](https://github.com/Ksys-labs/L4Reap.git) ## The list of software includes: * freetype2 * libsigc++ * libwhefs * libxml2 * openssl * disko ## Enhancements: * Buffer overflow protection;T; I"

text

We’ve ported and customized several software projects to run on top of L4Re.

L4Reap Repository

The list of software includes:

  • freetype2
  • libsigc++
  • libwhefs
  • libxml2
  • openssl
  • disko

Enhancements:

  • Buffer overflow protection
;T; @I"$/ukernels/l4linux_usb-otg_wifi/;T{;{ ;I"1 OMAP3 L4Linux usb-otg with wifi

Overview

L4Reap is a modified version of L4Linux created to run on TI OMAP3 (Gumstix Overo, IGEP). The goal of this project is to make a certain number of hardware resources accessible and usable from whithin a paravirtualized environment.

List of Supported Hardware

  • Libertas WiFi module
  • USB OTG Ethernet Gadget

Build Instructions

Cross Toolchain

L4Reap is known to work with CodeSourcery 2011.03 toolchain for ARM:

arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

We assume that toolchain is set up and available as arm-linux-gcc, arm-linux-ld, etc.

Setup

mkdir build
export L4DIR=`pwd`
export L4BUI=$L4DIR/build 
svn co http://svn.tudos.org/repos/oc/tudos/trunk/@40 src
git clone git://github.com/Ksys-labs/L4Reap.git

Building

Building Fiasco.OC Kernel

make BUILDDIR=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco
make -C $L4BUI/kernel config

Choose following options from menu:

Target configuration  ---> 
  Architecture (ARM processor family)  --->
  Platform (TI OMAP)  -->
  OMAP Platform (Beagle Board)  --->
make O=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco

Build L4Re

mkdir $L4BUI/l4
make O=$L4BUI/l4 -C $L4DIR/src/l4 config

Choose following options from menu:

  Target Architecture (ARM architecture)  --->                            
     CPU variant (ARMv7A type CPU)  --->
     Platform Selection (Beagleboard)  --->   

make O=$L4BUI/l4 -C $L4DIR/src/l4

Build L4Linux

make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- l4reap_defconfig
echo CONFIG_L4_OBJ_TREE=\"$L4BUI/l4\" >> $L4BUI/l4reap/.config
make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux-

Creating a Bootable Image

make O=$L4BUI/l4 -C $L4DIR/src/l4 \
  MODULES_LIST=$L4DIR/L4Reap/files/modules.list \
  MODULE_SEARCH_PATH=$L4DIR/L4Reap/files:$L4BUI/kernel:$L4BUI/l4reap \
  E=l4reap uimage

Running

Booting from MMC:

mmc rescan 0
fatload mmc 0 80000000 l4img
bootm 80000000

Bugs and Limitations

The system does not survive:

  • OTG unplugging
  • ifconfig usb0 down
  • Hi, I’m a new item!
;T; I" Overview ==================== L4Reap is a modified version of L4Linux created to run on TI OMAP3 (Gumstix Overo, IGEP). The goal of this project is to make a certain number of hardware resources accessible and usable from whithin a paravirtualized environment. List of Supported Hardware --------------------- * Libertas WiFi module * USB OTG Ethernet Gadget Build Instructions ==================== Cross Toolchain --------------------- L4Reap is known to work with CodeSourcery 2011.03 toolchain for ARM: ~~~ arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ~~~ We assume that toolchain is set up and available as arm-linux-gcc, arm-linux-ld, etc. Setup --------------------- ~~~ mkdir build export L4DIR=`pwd` export L4BUI=$L4DIR/build svn co http://svn.tudos.org/repos/oc/tudos/trunk/@40 src git clone git://github.com/Ksys-labs/L4Reap.git ~~~ {:.language-text} Building --------------------- Building Fiasco.OC Kernel ~~~ make BUILDDIR=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco make -C $L4BUI/kernel config ~~~ {:.language-text} Choose following options from menu: ~~~ Target configuration ---> Architecture (ARM processor family) ---> Platform (TI OMAP) --> OMAP Platform (Beagle Board) ---> make O=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco ~~~ {:.language-text} Build L4Re ~~~ mkdir $L4BUI/l4 make O=$L4BUI/l4 -C $L4DIR/src/l4 config ~~~ {:.language-text} Choose following options from menu: ~~~ Target Architecture (ARM architecture) ---> CPU variant (ARMv7A type CPU) ---> Platform Selection (Beagleboard) ---> make O=$L4BUI/l4 -C $L4DIR/src/l4 ~~~ {:.language-text} Build L4Linux ~~~ make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- l4reap_defconfig echo CONFIG_L4_OBJ_TREE=\"$L4BUI/l4\" >> $L4BUI/l4reap/.config make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- ~~~ {:.language-text} Creating a Bootable Image --------------------- ~~~ make O=$L4BUI/l4 -C $L4DIR/src/l4 \ MODULES_LIST=$L4DIR/L4Reap/files/modules.list \ MODULE_SEARCH_PATH=$L4DIR/L4Reap/files:$L4BUI/kernel:$L4BUI/l4reap \ E=l4reap uimage ~~~ {:.language-text} Running ==================== Booting from MMC: ~~~ mmc rescan 0 fatload mmc 0 80000000 l4img bootm 80000000 ~~~ {:.language-text} Bugs and Limitations ==================== The system does not survive: * OTG unplugging * ifconfig usb0 down * Hi, I'm a new item!;T; I"L

Overview

L4Reap is a modified version of L4Linux created to run on TI OMAP3 (Gumstix Overo, IGEP). The goal of this project is to make a certain number of hardware resources accessible and usable from whithin a paravirtualized environment.

List of Supported Hardware

  • Libertas WiFi module
  • USB OTG Ethernet Gadget

Build Instructions

Cross Toolchain

L4Reap is known to work with CodeSourcery 2011.03 toolchain for ARM:

arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

We assume that toolchain is set up and available as arm-linux-gcc, arm-linux-ld, etc.

Setup

mkdir build
export L4DIR=`pwd`
export L4BUI=$L4DIR/build 
svn co http://svn.tudos.org/repos/oc/tudos/trunk/@40 src
git clone git://github.com/Ksys-labs/L4Reap.git

Building

Building Fiasco.OC Kernel

make BUILDDIR=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco
make -C $L4BUI/kernel config

Choose following options from menu:

Target configuration  ---> 
  Architecture (ARM processor family)  --->
  Platform (TI OMAP)  -->
  OMAP Platform (Beagle Board)  --->
make O=$L4BUI/kernel -C $L4DIR/src/kernel/fiasco

Build L4Re

mkdir $L4BUI/l4
make O=$L4BUI/l4 -C $L4DIR/src/l4 config

Choose following options from menu:

  Target Architecture (ARM architecture)  --->                            
     CPU variant (ARMv7A type CPU)  --->
     Platform Selection (Beagleboard)  --->   

make O=$L4BUI/l4 -C $L4DIR/src/l4

Build L4Linux

make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux- l4reap_defconfig
echo CONFIG_L4_OBJ_TREE=\"$L4BUI/l4\" >> $L4BUI/l4reap/.config
make -C L4Reap/l4linux O=$L4BUI/l4reap L4ARCH=arm CROSS_COMPILE=arm-linux-

Creating a Bootable Image

make O=$L4BUI/l4 -C $L4DIR/src/l4 \
  MODULES_LIST=$L4DIR/L4Reap/files/modules.list \
  MODULE_SEARCH_PATH=$L4DIR/L4Reap/files:$L4BUI/kernel:$L4BUI/l4reap \
  E=l4reap uimage

Running

Booting from MMC:

mmc rescan 0
fatload mmc 0 80000000 l4img
bootm 80000000

Bugs and Limitations

The system does not survive:

  • OTG unplugging
  • ifconfig usb0 down
  • Hi, I’m a new item!
;T; @I"/ukernels/genode_fork/;T{;{ ;I"% Genode fork

We have the following things in our repo which aren’t moved to Genode upstream yet:

  • Gumstix Overo platform, OMAP3 framebuffer driver, ADS7846 touchscreen driver

    We used to use Gumstix board for the first prototype our device. This board is OMAP3 based and it allowed us to use Fiasco.OC and Genode for Gumstix. We have implemented support of framebuffer and touchscreen. Then the platform was changed to OMAP4 and we cancelled a support this code. This code requires a little improvement.

  • Ts_input adapter

    This service implement translation raw data from resistive touchscreen to screen coordinates for Nitpicker. Also Ts_input can be used for touchscreen calibration. Ts_input configuration is compatible with tslib.

  • OMAP4 McSPI driver and SPI session interface

    This is simple SPI driver for OMAP4. We have implemented only part of McSPI functions and this driver have used only for the TSC2046 touchscreen driver.

  • TSC2046 touchscreen controller driver

    Touchscreen driver for the Chipsee expansion board for the Pandaboard.

  • Qt ssl fix

    We have done modification QtNetwork for work over SSL connections in qt-based browsers. Also, fixed loading of openssl.conf for using OpenSSL engines in Qt applications.

  • QtSql and sqlite3

    Added QtSql library with sqlite3 support.

  • Qupzilla browser port

  • Smartcard session interface and driver for TDA8029 smartcard reader

    This interface and driver implement work with smartcards. TDA8029 reader works over UART.

  • Virtual network between l4linux’s

    L4linux driver which is implemented the NIC service and it can be used for connect two l4linux instances using the NIC interface. More information is available at Gateway page.

  • Terminalmux

    Terminal multiplexer. More information available at README

  • TWL6030 Voltage Regulator driver

    This allows to enable various hardware on OMAP4 SoC. The code is in os/include/regulator_session and os/src/drivers/regulator.

  • OMAP4 I2C driver

  • I.MX53 I2C driver

We are currently working on the following features:

  • OMAP4 USB OTG (Client mode for Mentor Graphics MUSB driver).

    We currently have the controller initializing, but the data endpoints are not working. The branch is omap4-otg-dirty ; git.

  • Melfas MMS144 Touchscreen

    This is the touchscreen used in the Samsung Galaxy Nexus phone. A prototype driver and board support code is available in branch tuna-hacks ; Ksys Labs git .

  • OMAP4 GPIO MUX driver

    This allows to set up GPIO alternate functions. The code is in os/include/platform/omap4/gpiomux_session and os/src/drivers/gpio/omap4_mux. The branch is tuna-hacks; Ksys Labs git.

Below is the list of features that we want to implement but have not yet started. While implementing some hardware drivers (PWM, Clock) it will be required to also design a generic driver session interface for Genode.

  • EFI GPT partition support

    This is needed for most new embedded hardware as it is a part of EMMC standard. Also will be needed to support new UEFI laptops

  • File System DDEKit

    Currently the choice of filesystems on Genode is limited to VFAT. Providing the support for linux filesystem drivers via DDEKit will allow to always have the latest version of EXT4 driver and access linux partitions without the risk of destroying them.

  • FS → Block adapter

    This will allow to present a file in a filesystem as a block device in the same way as loop devices work on *NIX. It is needed to support multiple instances of l4linux without repartitioning the storage device

  • OMAP4 Clock driver

    It is required to provide initialization of most peripherals.

  • OMAP4 DVFS

    To reduce power consumption

  • OMAP4 DSS/DSI display

    Support for the cold initialization of the DSS subsystem and the VC interface to support LCD panels on Samsung Galaxy Nexus and Samsung P5100

  • Power Management

    Enhance the sheduler to support idle power saving and (hopefully) suspend2ram.

  • OMAP4 PWM

    Mainly for controlling backlight and vibrator motor in the phone.

  • TWL6040 Sound Codec + Routing

    Sound support on PandaBoard and Galaxy Nexus

;T; I"RWe have the following things in our [repo](https://github.com/Ksys-labs/genode) which aren't moved to Genode upstream yet: * ### Gumstix Overo platform, OMAP3 framebuffer driver, ADS7846 touchscreen driver > We used to use Gumstix board for the first prototype our device. This board is OMAP3 based and it allowed us to use Fiasco.OC and Genode for Gumstix. We have implemented support of framebuffer and touchscreen. Then the platform was changed to OMAP4 and we cancelled a support this code. This code requires a little improvement. * ### Ts_input adapter > This service implement translation raw data from resistive touchscreen to screen coordinates for Nitpicker. Also Ts_input can be used for touchscreen calibration. Ts_input configuration is compatible with tslib. * ### OMAP4 McSPI driver and SPI session interface > This is simple SPI driver for OMAP4. We have implemented only part of McSPI functions and this driver have used only for the TSC2046 touchscreen driver. * ### TSC2046 touchscreen controller driver > Touchscreen driver for the Chipsee expansion board for the Pandaboard. * ### Qt ssl fix > We have done modification QtNetwork for work over SSL connections in qt-based browsers. Also, fixed loading of openssl.conf for using OpenSSL engines in Qt applications. * ### QtSql and sqlite3 > Added QtSql library with sqlite3 support. * ### [Qupzilla](http://www.qupzilla.com/) browser port * ### Smartcard session interface and driver for TDA8029 smartcard reader > This interface and driver implement work with smartcards. TDA8029 reader works over UART. * ### Virtual network between l4linux's > L4linux driver which is implemented the NIC service and it can be used for connect two l4linux instances using the NIC interface. More information is available at Gateway page. * ### Terminalmux > Terminal multiplexer. More information available at [README](https://github.com/Ksys-labs/genode/blob/staging/os/src/server/terminalmux/README) * ### TWL6030 Voltage Regulator driver > This allows to enable various hardware on OMAP4 SoC. > The code is in **os/include/regulator_session** and **os/src/drivers/regulator**. * ### OMAP4 I2C driver * ### I.MX53 I2C driver We are currently working on the following features: * ### OMAP4 USB OTG (Client mode for Mentor Graphics MUSB driver). > We currently have the controller initializing, but the data endpoints are not working. > The branch is omap4-otg-dirty ; [git](https://github.com/astarasikov/genode.git). * ### Melfas MMS144 Touchscreen > This is the touchscreen used in the Samsung Galaxy Nexus phone. > A prototype driver and board support code is available in branch tuna-hacks ; Ksys Labs git . * ### OMAP4 GPIO MUX driver > This allows to set up GPIO alternate functions. > The code is in os/include/platform/omap4/gpiomux_session and os/src/drivers/gpio/omap4_mux. > The branch is **tuna-hacks**; [Ksys Labs git](https://github.com/Ksys-labs/genode.git). Below is the list of features that we want to implement but have not yet started. While implementing some hardware drivers (PWM, Clock) it will be required to also design a generic driver session interface for Genode. * ### EFI GPT partition support > This is needed for most new embedded hardware as it is a part of EMMC standard. Also will be needed to support new UEFI laptops * ### File System DDEKit > Currently the choice of filesystems on Genode is limited to VFAT. Providing the support for linux filesystem drivers via DDEKit will allow to always have the latest version of EXT4 driver and access linux partitions without the risk of destroying them. * ### FS → Block adapter > This will allow to present a file in a filesystem as a block device in the same way as loop devices work on *NIX. It is needed to support multiple instances of l4linux without repartitioning the storage device * ### OMAP4 Clock driver > It is required to provide initialization of most peripherals. * ### OMAP4 DVFS > To reduce power consumption * ### OMAP4 DSS/DSI display > Support for the cold initialization of the DSS subsystem and the VC interface to support LCD panels on Samsung Galaxy Nexus and Samsung P5100 * ### Power Management > Enhance the sheduler to support idle power saving and (hopefully) suspend2ram. * ### OMAP4 PWM > Mainly for controlling backlight and vibrator motor in the phone. * ### TWL6040 Sound Codec + Routing > Sound support on PandaBoard and Galaxy Nexus;T; I"

We have the following things in our repo which aren’t moved to Genode upstream yet:

  • Gumstix Overo platform, OMAP3 framebuffer driver, ADS7846 touchscreen driver

    We used to use Gumstix board for the first prototype our device. This board is OMAP3 based and it allowed us to use Fiasco.OC and Genode for Gumstix. We have implemented support of framebuffer and touchscreen. Then the platform was changed to OMAP4 and we cancelled a support this code. This code requires a little improvement.

  • Ts_input adapter

    This service implement translation raw data from resistive touchscreen to screen coordinates for Nitpicker. Also Ts_input can be used for touchscreen calibration. Ts_input configuration is compatible with tslib.

  • OMAP4 McSPI driver and SPI session interface

    This is simple SPI driver for OMAP4. We have implemented only part of McSPI functions and this driver have used only for the TSC2046 touchscreen driver.

  • TSC2046 touchscreen controller driver

    Touchscreen driver for the Chipsee expansion board for the Pandaboard.

  • Qt ssl fix

    We have done modification QtNetwork for work over SSL connections in qt-based browsers. Also, fixed loading of openssl.conf for using OpenSSL engines in Qt applications.

  • QtSql and sqlite3

    Added QtSql library with sqlite3 support.

  • Qupzilla browser port

  • Smartcard session interface and driver for TDA8029 smartcard reader

    This interface and driver implement work with smartcards. TDA8029 reader works over UART.

  • Virtual network between l4linux’s

    L4linux driver which is implemented the NIC service and it can be used for connect two l4linux instances using the NIC interface. More information is available at Gateway page.

  • Terminalmux

    Terminal multiplexer. More information available at README

  • TWL6030 Voltage Regulator driver

    This allows to enable various hardware on OMAP4 SoC. The code is in os/include/regulator_session and os/src/drivers/regulator.

  • OMAP4 I2C driver

  • I.MX53 I2C driver

We are currently working on the following features:

  • OMAP4 USB OTG (Client mode for Mentor Graphics MUSB driver).

    We currently have the controller initializing, but the data endpoints are not working. The branch is omap4-otg-dirty ; git.

  • Melfas MMS144 Touchscreen

    This is the touchscreen used in the Samsung Galaxy Nexus phone. A prototype driver and board support code is available in branch tuna-hacks ; Ksys Labs git .

  • OMAP4 GPIO MUX driver

    This allows to set up GPIO alternate functions. The code is in os/include/platform/omap4/gpiomux_session and os/src/drivers/gpio/omap4_mux. The branch is tuna-hacks; Ksys Labs git.

Below is the list of features that we want to implement but have not yet started. While implementing some hardware drivers (PWM, Clock) it will be required to also design a generic driver session interface for Genode.

  • EFI GPT partition support

    This is needed for most new embedded hardware as it is a part of EMMC standard. Also will be needed to support new UEFI laptops

  • File System DDEKit

    Currently the choice of filesystems on Genode is limited to VFAT. Providing the support for linux filesystem drivers via DDEKit will allow to always have the latest version of EXT4 driver and access linux partitions without the risk of destroying them.

  • FS → Block adapter

    This will allow to present a file in a filesystem as a block device in the same way as loop devices work on *NIX. It is needed to support multiple instances of l4linux without repartitioning the storage device

  • OMAP4 Clock driver

    It is required to provide initialization of most peripherals.

  • OMAP4 DVFS

    To reduce power consumption

  • OMAP4 DSS/DSI display

    Support for the cold initialization of the DSS subsystem and the VC interface to support LCD panels on Samsung Galaxy Nexus and Samsung P5100

  • Power Management

    Enhance the sheduler to support idle power saving and (hopefully) suspend2ram.

  • OMAP4 PWM

    Mainly for controlling backlight and vibrator motor in the phone.

  • TWL6040 Sound Codec + Routing

    Sound support on PandaBoard and Galaxy Nexus

;T; @I"/ukernels/hardenning_rus/;T{;{ ;I">6 Сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти
Summer Systems School

Летняя Школа Системного Программирования

5-6 августа, Москва

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти.

git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки.

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Подготовьте директории для сборки.

Для микроядра fiasco

pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

Для среды L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Теперь можно приступить к настройке L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

создание файла конфигурации Makeconf.boot

Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки.

pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco.

pushd .
        cd "$L4LINUX_BUILDDIR"
        make menuconfig

        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска.

cpio -i /path/to/ramdisk.img

Cоздание нового образа.

find . | cpio -o -H newc > /path/to/new_ramdisk.img

компиляция тестовых утилит PaX для L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; I"@%# сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти ## получение компилятора На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) "linux", а не под "none" (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor. https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## Исправление системы сборки L4Re По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл **L4Reap/l4/mk/Makeconf** необходимо заменить строку, в которой определена переменная `SYSTEM_TARGET_arm`. ~~~ ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ~~~ ## подготовка каталога для сборки Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux. > **Примечание:** В данном руководстве, такой директорией является `/mnt/disk2/l4_snapshot`. Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap ~~~ git clone https://github.com/Ksys-labs/L4Reap.git ~~~ {:.language-bash} Переключите репозиторий на ветку с реализацией поддержки NX памяти. ~~~ git checkout test-nx ~~~ {:.language-bash} Установите переменные среды, указывающие на директории для сброрки. ~~~ export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ~~~ {:.language-bash} Подготовьте директории для сборки. Для микроядра fiasco ~~~ pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd ~~~ {:.language-bash} Для среды L4Re ~~~ pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ~~~ {:.language-bash} ## сборка L4Re ### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните `make config` и установите настройки архитектуры. Можно также скопировать файл `.config` из примера. ~~~ pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ~~~ {:.language-bash} Теперь можно приступить к настройке L4Re ~~~ pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ~~~ {:.language-bash} ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в `conf/Makeconf.boot` в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона. ~~~ pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ~~~ {:.language-bash} При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную `MODULE_SEARCH_PATH`. ~~~ MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ~~~ {:.language-bash} Теперь, собрать все пакеты среды L4Re при помощи команды `make` в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент `S=`. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения `map_rwx` из пакета `ksys_mem_tests`. ~~~ pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ~~~ {:.language-bash} ### создание образа u-boot для загрузки на устройстве (Pandaboard) ~~~ make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ~~~ {:.language-bash} ## сборка L4Linux Необходимо дополнительно собрать следующие пакеты среды L4Re: > io,libstdc++-v3,libvcpu,shmc Чтобы собрать L4Linux, сначала подготовим каталог для сборки. ~~~ pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd ~~~ {:.language-bash} Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды `make menuconfig`. Также, необходимо указать в опциях конфигурации или добавлением строки в файл `.config` путь к каталогу сборки микроядра fiasco. ~~~ pushd . cd "$L4LINUX_BUILDDIR" make menuconfig echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ~~~ {:.language-bash} ### сборка начального RAMdisk Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ: ~~~ pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ~~~ {:.language-bash} Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту `cpio`. Извлечение содержимого виртуального диска. ~~~ cpio -i /path/to/ramdisk.img ~~~ {:.language-bash} Cоздание нового образа. ~~~ find . | cpio -o -H newc > /path/to/new_ramdisk.img ~~~ {:.language-bash} ## компиляция тестовых утилит PaX для L4Linux ~~~ tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ~~~ {:.language-bash} Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.;T; I"-

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти.

git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки.

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Подготовьте директории для сборки.

Для микроядра fiasco

pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

Для среды L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Теперь можно приступить к настройке L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

создание файла конфигурации Makeconf.boot

Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки.

pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco.

pushd .
        cd "$L4LINUX_BUILDDIR"
        make menuconfig

        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска.

cpio -i /path/to/ramdisk.img

Cоздание нового образа.

find . | cpio -o -H newc > /path/to/new_ramdisk.img

компиляция тестовых утилит PaX для L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; @I"/ukernels/gnex_uboot/;T{;{ ;I"+ Samsung Galaxy Nexus U-Boot

Introduction

This page describes the port of the u-boot bootloader to the Galaxy Nexus phone

Rationale

There were a couple reasons to port u-boot to Galaxy Nexus

  • Security: we cannot trust the proprietary samsung bootloader
  • Implementing dual-boot for original and custom firmware
  • Booting Genode operating system

Demo

Compilation from source

Source code is in https://github.com/Ksys-labs/uboot-tuna

There exist two branches of interest

  • master - contains the official stable releases. may be force-pushed and rebased, beware
  • tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode

To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that’ s what I ‘m using and some users reported that newer compilers produce broken binaries.

There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.

Flashing instead of SBL has the following advantages

  • Faster boot time than chainloading
  • Ability to use the standard partitioning layout

There is a number of issues and therefore we do not recommend flashing it instead of SBL

  • No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you’ ll have to use OMAPFlash to restore the device if you flash a non - working kernel
  • No display initialization.You ‘ll have to disable the “Check for Bootloader initialization” option in kernel config

By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address 0x81808000.

If you want to build the SBL replacement version, edit the include/configs/omap4_tuna.h file and uncomment the #define TUNA_SPL_BUILD line. X-loader loads the bootloader to the address 0xa0208000.

export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-

U_BOARD=omap4_tuna
make clean
make distclean

make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg

Installation

Chainloaded Mode

You will need the root access to your device. You can take the prebuilt u-boot here. [gnex-uboot-chainloaded.img]

The u - boot has the support for android boot images.When flashed instead of the SBL, it boots the kernel off the “Boot” partition. When chainloaded, it looks for the kernel in /system/boot/vmlinux.uimg. Additionally, it first looks for the /system/boot/boot.scr.uimg so you can put custom commands there and override the kernel image.

It also supports booting custom images from /sdcard/boot/vmlinux.uimg and /sdcard/boot/boot.scr.uimg.

If you need larger images, I suggest that you use the tuna-fosdem-hacks branch, format the cache partition to ext2 and put the files to /cache/media/boot/.

push the files to your device via adb

adb push gnex-uboot-chainloaded.img /sdcard/ 
adb hell 

now, in the device shell, do the following:

su cat /dev/block/platform /omap/omap_hsmmc.0/by-name/boot > /sdcard /vmlinux.uimg mount - o remount, rw /system mkdir/system/boot cp /sdcard/vmlinux.uimg /system/boot/ cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform /omap /omap_hsmmc.0/by-name/boot sync reboot

you can also use fastboot to flash u-boot.img instead of dd’ing it

fastboot flash:raw boot u-boot.img”

Replacing samsung bootloader

OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.

Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.

Take the x-loader here [gnex-xloader-working.img]

adb push gnex-xloader-working.img /sdcard/

The installation procedure is roughly the same, but use sbl partition. Also, install xloader by

cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader

There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.

Search the internet for the archive named “OMAPFlash_tuna.zip” which has md5 “ddbf07a1d36b044c40af5788a83b5395”. We cannot upload it here because of the unclear license status.

Making images

You can either use Android’ s mkbootimg to produce ANDROID !type images (not recommended) or u-boot’s mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.

making a custom boot image

mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg

#alternatively, just do that when compiling linux

#do not forget to add mkimage to your PATH variable make uImage making a custom boot script

mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg

Booting Modes

The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android “reboot to recovery” and “reboot to bootloader” features

  • Normal Boot -> no keys are pressed, cyan LED
  • Recovery Boot -> Volume Up key pressed, green LED
  • Custom Boot -> Volume Down key pressed, blue LED
  • USB RNDIS mode -> both Volume keys pressed, purple LED

Pitfalls

  • No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you’ re chainloading, right ?
  • Serial number is always 0123456789 abcdef or sth like that.Anyone to fix that ?
  • UART support is quirky.The device will likely hang if booted with the UART cable.Workaround : boot without the UART cable and plug right after the purple LED flashes.

A sample boot script for android

Make a boot.scr.uimg from it and push it to the correct location.

setenv bootargs “mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18 no_console_suspend console=ttyFIQ0”;

setenv loaddaddr 0x82000000;

setenv devtype mmc;

setenv devnum 0;

setenv kernel_part 0xc;

setenv kernel_name /media/boot/vmlinux.uimg;

echo Load Address: ${loaddaddr};

echo cmdline:${bootargs};

if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0\;

elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0;

else

echo failed to boot custom image;

fi

;T; I"dIntroduction ==================== This page describes the port of the u-boot bootloader to the Galaxy Nexus phone Rationale ==================== There were a couple reasons to port u-boot to Galaxy Nexus * Security: we cannot trust the proprietary samsung bootloader * Implementing dual-boot for original and custom firmware * Booting Genode operating system Demo ==================== Compilation from source --------------------- Source code is in [https://github.com/Ksys-labs/uboot-tuna](https://github.com/Ksys-labs/uboot-tuna) There exist two branches of interest * master - contains the official stable releases. may be force-pushed and rebased, beware * tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that' s what I 'm using and some users reported that newer compilers produce broken binaries. There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL. Flashing instead of SBL has the following advantages * Faster boot time than chainloading * Ability to use the standard partitioning layout There is a number of issues and therefore we do not recommend flashing it instead of SBL * No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you' ll have to use OMAPFlash to restore the device if you flash a non - working kernel * No display initialization.You 'll have to disable the “Check for Bootloader initialization” option in kernel config By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address **0x81808000**. If you want to build the SBL replacement version, edit the **include/configs/omap4_tuna.h** file and uncomment the **#define TUNA_SPL_BUILD line**. X-loader loads the bootloader to the address **0xa0208000**. ~~~ export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH export ARCH=arm export CROSS_COMPILE=arm-none-eabi- U_BOARD=omap4_tuna make clean make distclean make ${U_BOARD}_config make -j8 ${U_BOARD} mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg ~~~ {:.language-text} Installation ==================== Chainloaded Mode You will need the root access to your device. You can take the prebuilt u-boot here. [gnex-uboot-chainloaded.img] The u - boot has the support for android boot images.When flashed instead of the SBL, it boots the kernel off the "Boot" partition. When chainloaded, it looks for the kernel in **/system/boot/vmlinux.uimg**. Additionally, it first looks for the **/system/boot/boot.scr.uimg** so you can put custom commands there and override the kernel image. It also supports booting custom images from **/sdcard/boot/vmlinux.uimg** and **/sdcard/boot/boot.scr.uimg**. If you need larger images, I suggest that you use the **tuna-fosdem-hacks** branch, format the cache partition to ext2 and put the files to **/cache/media/boot/**. push the files to your device via adb ~~~ adb push gnex-uboot-chainloaded.img /sdcard/ adb hell ~~~ {:.language-text} now, in the device shell, do the following: > su > cat /dev/block/platform /omap/omap_hsmmc.0/by-name/boot > /sdcard /vmlinux.uimg > mount - o remount, rw /system mkdir/system/boot > cp /sdcard/vmlinux.uimg /system/boot/ > cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform /omap /omap_hsmmc.0/by-name/boot > sync > reboot you can also use fastboot to flash u-boot.img instead of dd'ing it > fastboot flash:raw boot u-boot.img" Replacing samsung bootloader ==================== OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB. Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed. Take the x-loader here [gnex-xloader-working.img] > adb push gnex-xloader-working.img /sdcard/ The installation procedure is roughly the same, but use sbl partition. Also, install xloader by > cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP. Search the internet for the archive named “OMAPFlash_tuna.zip” which has md5 “ddbf07a1d36b044c40af5788a83b5395”. We cannot upload it here because of the unclear license status. Making images ==================== You can either use Android' s mkbootimg to produce ANDROID !type images (not recommended) or u-boot's mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images. making a custom boot image --------------------- > mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg > \#alternatively, just do that when compiling linux > > \#do not forget to add mkimage to your PATH variable > make uImage > making a custom boot script > mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg Booting Modes ==================== The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android “reboot to recovery” and “reboot to bootloader” features * Normal Boot -> no keys are pressed, cyan LED * Recovery Boot -> Volume Up key pressed, green LED * Custom Boot -> Volume Down key pressed, blue LED * USB RNDIS mode -> both Volume keys pressed, purple LED Pitfalls ==================== * No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you' re chainloading, right ? * Serial number is always 0123456789 abcdef or sth like that.Anyone to fix that ? * UART support is quirky.The device will likely hang if booted with the UART cable.Workaround : boot without the UART cable and plug right after the purple LED flashes. A sample boot script for android ==================== Make a boot.scr.uimg from it and push it to the correct location. > setenv bootargs "mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18 no_console_suspend console=ttyFIQ0"; > > setenv loaddaddr 0x82000000; > > setenv devtype mmc; > > setenv devnum 0; > > setenv kernel_part 0xc; > > setenv kernel_name /media/boot/vmlinux.uimg; > > echo Load Address: ${loaddaddr}; > > echo cmdline:${bootargs}; > > if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then > > bootm ${loaddaddr}; > > exit 0\; > > elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then > > bootm ${loaddaddr}; > > exit 0; > > else > echo failed to boot custom image; > fi;T; I"9

Introduction

This page describes the port of the u-boot bootloader to the Galaxy Nexus phone

Rationale

There were a couple reasons to port u-boot to Galaxy Nexus

  • Security: we cannot trust the proprietary samsung bootloader
  • Implementing dual-boot for original and custom firmware
  • Booting Genode operating system

Demo

Compilation from source

Source code is in https://github.com/Ksys-labs/uboot-tuna

There exist two branches of interest

  • master - contains the official stable releases. may be force-pushed and rebased, beware
  • tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode

To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that’ s what I ‘m using and some users reported that newer compilers produce broken binaries.

There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.

Flashing instead of SBL has the following advantages

  • Faster boot time than chainloading
  • Ability to use the standard partitioning layout

There is a number of issues and therefore we do not recommend flashing it instead of SBL

  • No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you’ ll have to use OMAPFlash to restore the device if you flash a non - working kernel
  • No display initialization.You ‘ll have to disable the “Check for Bootloader initialization” option in kernel config

By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address 0x81808000.

If you want to build the SBL replacement version, edit the include/configs/omap4_tuna.h file and uncomment the #define TUNA_SPL_BUILD line. X-loader loads the bootloader to the address 0xa0208000.

export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-

U_BOARD=omap4_tuna
make clean
make distclean

make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg

Installation

Chainloaded Mode

You will need the root access to your device. You can take the prebuilt u-boot here. [gnex-uboot-chainloaded.img]

The u - boot has the support for android boot images.When flashed instead of the SBL, it boots the kernel off the “Boot” partition. When chainloaded, it looks for the kernel in /system/boot/vmlinux.uimg. Additionally, it first looks for the /system/boot/boot.scr.uimg so you can put custom commands there and override the kernel image.

It also supports booting custom images from /sdcard/boot/vmlinux.uimg and /sdcard/boot/boot.scr.uimg.

If you need larger images, I suggest that you use the tuna-fosdem-hacks branch, format the cache partition to ext2 and put the files to /cache/media/boot/.

push the files to your device via adb

adb push gnex-uboot-chainloaded.img /sdcard/ 
adb hell 

now, in the device shell, do the following:

su cat /dev/block/platform /omap/omap_hsmmc.0/by-name/boot > /sdcard /vmlinux.uimg mount - o remount, rw /system mkdir/system/boot cp /sdcard/vmlinux.uimg /system/boot/ cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform /omap /omap_hsmmc.0/by-name/boot sync reboot

you can also use fastboot to flash u-boot.img instead of dd’ing it

fastboot flash:raw boot u-boot.img”

Replacing samsung bootloader

OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.

Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.

Take the x-loader here [gnex-xloader-working.img]

adb push gnex-xloader-working.img /sdcard/

The installation procedure is roughly the same, but use sbl partition. Also, install xloader by

cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader

There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.

Search the internet for the archive named “OMAPFlash_tuna.zip” which has md5 “ddbf07a1d36b044c40af5788a83b5395”. We cannot upload it here because of the unclear license status.

Making images

You can either use Android’ s mkbootimg to produce ANDROID !type images (not recommended) or u-boot’s mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.

making a custom boot image

mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg

#alternatively, just do that when compiling linux

#do not forget to add mkimage to your PATH variable make uImage making a custom boot script

mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg

Booting Modes

The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android “reboot to recovery” and “reboot to bootloader” features

  • Normal Boot -> no keys are pressed, cyan LED
  • Recovery Boot -> Volume Up key pressed, green LED
  • Custom Boot -> Volume Down key pressed, blue LED
  • USB RNDIS mode -> both Volume keys pressed, purple LED

Pitfalls

  • No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you’ re chainloading, right ?
  • Serial number is always 0123456789 abcdef or sth like that.Anyone to fix that ?
  • UART support is quirky.The device will likely hang if booted with the UART cable.Workaround : boot without the UART cable and plug right after the purple LED flashes.

A sample boot script for android

Make a boot.scr.uimg from it and push it to the correct location.

setenv bootargs “mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18 no_console_suspend console=ttyFIQ0”;

setenv loaddaddr 0x82000000;

setenv devtype mmc;

setenv devnum 0;

setenv kernel_part 0xc;

setenv kernel_name /media/boot/vmlinux.uimg;

echo Load Address: ${loaddaddr};

echo cmdline:${bootargs};

if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0\;

elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then

bootm ${loaddaddr};

exit 0;

else

echo failed to boot custom image;

fi

;T; @I"#/ukernels/hardenning/ru/build/;T{;{ ;I"o8 Сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти.

git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки.

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Подготовьте директории для сборки.

Для микроядра fiasco

pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

Для среды L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Теперь можно приступить к настройке L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

создание файла конфигурации Makeconf.boot

Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки.

pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco.

pushd .
        cd "$L4LINUX_BUILDDIR"
        make menuconfig

        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска.

cpio -i /path/to/ramdisk.img

Cоздание нового образа.

find . | cpio -o -H newc > /path/to/new_ramdisk.img

компиляция тестовых утилит PaX для L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; I"@%# сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти ## получение компилятора На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) "linux", а не под "none" (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor. https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## Исправление системы сборки L4Re По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл **L4Reap/l4/mk/Makeconf** необходимо заменить строку, в которой определена переменная `SYSTEM_TARGET_arm`. ~~~ ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ~~~ ## подготовка каталога для сборки Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux. > **Примечание:** В данном руководстве, такой директорией является `/mnt/disk2/l4_snapshot`. Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap ~~~ git clone https://github.com/Ksys-labs/L4Reap.git ~~~ {:.language-bash} Переключите репозиторий на ветку с реализацией поддержки NX памяти. ~~~ git checkout test-nx ~~~ {:.language-bash} Установите переменные среды, указывающие на директории для сброрки. ~~~ export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ~~~ {:.language-bash} Подготовьте директории для сборки. Для микроядра fiasco ~~~ pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd ~~~ {:.language-bash} Для среды L4Re ~~~ pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ~~~ {:.language-bash} ## сборка L4Re ### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните `make config` и установите настройки архитектуры. Можно также скопировать файл `.config` из примера. ~~~ pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ~~~ {:.language-bash} Теперь можно приступить к настройке L4Re ~~~ pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ~~~ {:.language-bash} ### создание файла конфигурации Makeconf.boot Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в `conf/Makeconf.boot` в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона. ~~~ pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ~~~ {:.language-bash} При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную `MODULE_SEARCH_PATH`. ~~~ MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ~~~ {:.language-bash} Теперь, собрать все пакеты среды L4Re при помощи команды `make` в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент `S=`. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения `map_rwx` из пакета `ksys_mem_tests`. ~~~ pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ~~~ {:.language-bash} ### создание образа u-boot для загрузки на устройстве (Pandaboard) ~~~ make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ~~~ {:.language-bash} ## сборка L4Linux Необходимо дополнительно собрать следующие пакеты среды L4Re: > io,libstdc++-v3,libvcpu,shmc Чтобы собрать L4Linux, сначала подготовим каталог для сборки. ~~~ pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd ~~~ {:.language-bash} Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды `make menuconfig`. Также, необходимо указать в опциях конфигурации или добавлением строки в файл `.config` путь к каталогу сборки микроядра fiasco. ~~~ pushd . cd "$L4LINUX_BUILDDIR" make menuconfig echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ~~~ {:.language-bash} ### сборка начального RAMdisk Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ: ~~~ pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ~~~ {:.language-bash} Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту `cpio`. Извлечение содержимого виртуального диска. ~~~ cpio -i /path/to/ramdisk.img ~~~ {:.language-bash} Cоздание нового образа. ~~~ find . | cpio -o -H newc > /path/to/new_ramdisk.img ~~~ {:.language-bash} ## компиляция тестовых утилит PaX для L4Linux ~~~ tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ~~~ {:.language-bash} Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.;T; I"-

сборка приложений среды L4Re и L4Linux с поддержкой неисполнимой (Non-Executable, NX) памяти

получение компилятора

На данный момент, сборка L4Re для архитектуры ARM с бинарным интерфейсом hard-float невозможна, поэтому необходимо использовать компилятор, собирающий двоичные файлы в формате softfp. Таким образом, большая часть компиляторов, по умолчанию доступная в новых версиях дистрибутивов Linux и сборка компилятора от Linaro несовместимы с L4Re. Кроме того, при вызове компоновщика в процессе сборки L4Re требуется наличие файла crtendS.o и других файлов CRT (библиотеки C Runtime), поэтому необходимо использовать компилятор, собранный под цель(target) “linux”, а не под “none” (также называемый bare metal toolchain). Проверена корректная работа системы L4Re при использовании компилятора Sourcery Lite от Mentor.

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Исправление системы сборки L4Re

По умолчанию среда L4Re не позволяет переопределить префикс компилятора, который используется при сборке. Поэтому, при использовании компилятора Sourcery необходимо внести изменение в программу сборки. В файл L4Reap/l4/mk/Makeconf необходимо заменить строку, в которой определена переменная SYSTEM_TARGET_arm.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

подготовка каталога для сборки

Перейдите в каталог, в который вы хотите скачать исходный код и в котором будут созданы директории с двоичными файлами fiasco, L4Re и L4Linux.

Примечание: В данном руководстве, такой директорией является /mnt/disk2/l4_snapshot.

Получите исходный код из следующего источника: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Переключите репозиторий на ветку с реализацией поддержки NX памяти.

git checkout test-nx

Установите переменные среды, указывающие на директории для сброрки.

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Подготовьте директории для сборки.

Для микроядра fiasco

pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

Для среды L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

сборка L4Re

### сборка микроядра fiasco Перейдите в каталог сборки fiasco, выполните make config и установите настройки архитектуры. Можно также скопировать файл .config из примера.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Теперь можно приступить к настройке L4Re

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

создание файла конфигурации Makeconf.boot

Каждый раз задавать переменные среды и путь (переменную PATH) неудобно. Вместо этого, можно прописать переменные и аргументы для запуска эмулятора QEMU в файле конфигурации. Он должен находиться в conf/Makeconf.boot в каталоге сборки L4Re. Можно использовать файл Makeconf.boot.example из примеров настройки L4Re в качестве шаблона.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

При сборке модуля L4Re, может возникнуть необходимость добавить каталог с файлами конфигурации в переменную MODULE_SEARCH_PATH.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Теперь, собрать все пакеты среды L4Re при помощи команды make в каталоге сборки. Также, можно собрать только нужные нам пакеты, перечислив их через аргумент S=. Иногда система сборки L4Re не может разрешить зависимости между пакетами, и сборка завершается неудачей. В таком случае необходимо перезапустить процесс сборки. Ниже указана команда со списком пакетов для сборки приложения map_rwx из пакета ksys_mem_tests.

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

создание образа u-boot для загрузки на устройстве (Pandaboard)

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

сборка L4Linux

Необходимо дополнительно собрать следующие пакеты среды L4Re:

io,libstdc++-v3,libvcpu,shmc

Чтобы собрать L4Linux, сначала подготовим каталог для сборки.

pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

Непосредственно процесс сборки. Можно задать опции конфигурации ядра при помощи компанды make menuconfig. Также, необходимо указать в опциях конфигурации или добавлением строки в файл .config путь к каталогу сборки микроядра fiasco.

pushd .
        cd "$L4LINUX_BUILDDIR"
        make menuconfig

        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

сборка начального RAMdisk

Можно собрать RAMdisk (виртуальный диск с образом корневой файловой системы для L4Linux) при помощи утилит типа buildroot или использовать готовый образ. Чтобы получить готовый образ:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

Может возникнуть необходимость отредактировать содержимое загрузочного диска. Для этого можно использовать утилиту cpio.

Извлечение содержимого виртуального диска.

cpio -i /path/to/ramdisk.img

Cоздание нового образа.

find . | cpio -o -H newc > /path/to/new_ramdisk.img

компиляция тестовых утилит PaX для L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Теперь двоичные файлы доступны в каталоге pax_tests_l4linux.

;T; @I"/ukernels/hardenning/;T{;{ ;I" L4Re hardenning ;T; I"[(RU) Сборка L4Re с поддержкой NX и тестирование](ru/build/) [(EN) Building L4Re with NX bit support and tests](en/build/);T; I"

(RU) Сборка L4Re с поддержкой NX и тестирование

(EN) Building L4Re with NX bit support and tests

;T; @I"#/ukernels/hardenning/en/build/;T{;{ ;I"t) Building L4Re and L4Linux with NX memory support

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory:

git checkout test-nx

Export the environment variables pointing to the build directories

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Prepare the build directories

# for fiasco
pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

# for L4Re
pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Now, we can configure the L4Re.

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

creating Makeconf.boot

It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

creating the u-boot image for the target device

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux

# create the l4linux build directory
pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

# actually compile
pushd .
        cd "$L4LINUX_BUILDDIR"
        #you can configure the kernel now
        make menuconfig

        #edit the config and set up the path to the fiasco build directory
        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following:

#extract the ramdisk
cpio -i /path/to/ramdisk.img

#make a new image
find . | cpio -o -H newc > /path/to/new_ramdisk.img

building PaX tests for L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; I"# building L4Re and L4Linux with NX memory support ## getting the compiler L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the "linux" toolchain as opposed to a "bare-metal" one. We have used the Sourcery Lite toolchain from Mentor https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ## fixing L4Re makefile By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file **L4Reap/l4/mk/Makeconf** and replace the line containing the `SYSTEM_TARGET_arm` variable with the following. ~~~ ./mk/Makeconf:SYSTEM_TARGET_arm = arm-none-linux-gnueabi- ~~~ ## preparing build directory Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux. > **Note:** In the course of this manual, we assume that the directory is `/mnt/disk2/l4_snapshot`. Get source code from: https://github.com/Ksys-labs/L4Reap ~~~ git clone https://github.com/Ksys-labs/L4Reap.git ~~~ {:.language-bash} Check out the branch with the support for the NX memory: ~~~ git checkout test-nx ~~~ {:.language-bash} Export the environment variables pointing to the build directories ~~~ export FOC_ROOT="$PWD" export FOC_PATH="${FOC_ROOT}/L4Reap" export FOC_BUILDDIR="${FOC_ROOT}/build" export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re" export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux" export MAKE_OPTS="-j10" ~~~ {:.language-bash} Prepare the build directories ~~~ # for fiasco pushd . cd "${FOC_PATH}/kernel/fiasco/" make BUILDDIR="$FOC_BUILDDIR" popd # for L4Re pushd . cd "${FOC_PATH}/l4" make B="$L4RE_BUILDDIR" popd ~~~ {:.language-bash} ## building L4Re ### building fiasco Go to the fiasco build directory, execute `make config` and set up architecture options. Sample configs for ARM and AMD64 are provided *TODO*. ~~~ pushd . cd "$FOC_BUILDDIR" make config make "$MAKE_OPTS" popd ~~~ {:.language-bash} Now, we can configure the L4Re. ~~~ pushd . cd "${FOC_PATH}/l4" make O="$L4RE_BUILDDIR" config popd ~~~ {:.language-bash} ### creating Makeconf.boot It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at `conf/Makeconf.boot` in the L4Re build directory. We can copy the one from the L4Re examples. ~~~ pushd . cd "$L4RE_BUILDDIR" mkdir conf cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot popd ~~~ {:.language-bash} When building a custom module, we may want to add the directory with the configuration scripts to the `MODULE_SEARCH_PATH` variable. ~~~ MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config ~~~ {:.language-make} Now, you can either build all packages inside the L4Re build dir by just issuing the `make` command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the `make` command until it succeeds. Alternatively, you can build only the needed packages using the `S=` parameter. Here is a command to build everything you need to run the `map_rwx` test application from the `ksys_mem_tests` package: ~~~ pushd . cd "$L4RE_BUILDDIR" make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe popd ~~~ {:.language-bash} ### creating the u-boot image for the target device ~~~ make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx # copy the uimage to the device or the TFTP server or whatever cp images/bootstrap.uimage /srv/tftp/panda/uImage ~~~ {:.language-bash} ## building l4linux You will need to additionally build the following L4Re packages: > io,libstdc++-v3,libvcpu,shmc to compile l4linux ~~~ # create the l4linux build directory pushd . cd "$FOC_ROOT/l4linux" make O="$L4LINUX_BUILDDIR" arm_defconfig popd # actually compile pushd . cd "$L4LINUX_BUILDDIR" #you can configure the kernel now make menuconfig #edit the config and set up the path to the fiasco build directory echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10 mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a" cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" popd ~~~ {:.language-bash} ### building initial RAMdisk You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from: ~~~ pushd . cd "$L4RE_BUILDDIR" wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd popd ~~~ {:.language-bash} You may want to customize the contents of the ramdisk. To do so, you need to do the following: ~~~ #extract the ramdisk cpio -i /path/to/ramdisk.img #make a new image find . | cpio -o -H newc > /path/to/new_ramdisk.img ~~~ {:.language-bash} ## building PaX tests for L4Linux ~~~ tar xvf pax_tests_l4linux.tar.gz cd pax_tests_l4linux make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- ~~~ {:.language-bash} Done, the binaries are in the pax_tests_l4linux directory.;T; I"~

building L4Re and L4Linux with NX memory support

getting the compiler

L4Re for ARM does not work when compiled with a hard-float compiler. Besides, during the linking stage L4Re needs the crtendS.o and some other CRT (C Runtime) files from the GCC. Therefore, one needs to use the “linux” toolchain as opposed to a “bare-metal” one. We have used the Sourcery Lite toolchain from Mentor

https://sourcery.mentor.com/GNUToolchain/package11447/public/arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

fixing L4Re makefile

By default L4Re does not provide a way to override the toolchain used to compile it. Therefore, you need to manually edit the file L4Reap/l4/mk/Makeconf and replace the line containing the SYSTEM_TARGET_arm variable with the following.

./mk/Makeconf:SYSTEM_TARGET_arm     = arm-none-linux-gnueabi-

preparing build directory

Go to the directory where you want to do put the source code and the build directories for fiasco, L4Re and L4Linux.

Note: In the course of this manual, we assume that the directory is /mnt/disk2/l4_snapshot.

Get source code from: https://github.com/Ksys-labs/L4Reap

git clone https://github.com/Ksys-labs/L4Reap.git

Check out the branch with the support for the NX memory:

git checkout test-nx

Export the environment variables pointing to the build directories

export FOC_ROOT="$PWD"
export FOC_PATH="${FOC_ROOT}/L4Reap"
export FOC_BUILDDIR="${FOC_ROOT}/build"
export L4RE_BUILDDIR="${FOC_ROOT}/build_l4re"
export L4LINUX_BUILDDIR="${FOC_ROOT}/build_l4linux"
export MAKE_OPTS="-j10"

Prepare the build directories

# for fiasco
pushd .
        cd "${FOC_PATH}/kernel/fiasco/"
        make BUILDDIR="$FOC_BUILDDIR"
popd

# for L4Re
pushd .
        cd "${FOC_PATH}/l4"
        make B="$L4RE_BUILDDIR"
popd

building L4Re

### building fiasco Go to the fiasco build directory, execute make config and set up architecture options. Sample configs for ARM and AMD64 are provided TODO.

pushd .
        cd "$FOC_BUILDDIR"
        make config
        make "$MAKE_OPTS"
popd

Now, we can configure the L4Re.

pushd .
        cd "${FOC_PATH}/l4"
        make O="$L4RE_BUILDDIR" config
popd

creating Makeconf.boot

It is inconvenient to export the shell variables and PATH each time. To avoid doing so, we can put the needed variables and QEMU arguments int a config file. It must be located at conf/Makeconf.boot in the L4Re build directory. We can copy the one from the L4Re examples.

pushd .
        cd "$L4RE_BUILDDIR"
        mkdir conf
        cp ../l4/conf/Makeconf.boot.example conf/Makeconf.boot
popd

When building a custom module, we may want to add the directory with the configuration scripts to the MODULE_SEARCH_PATH variable.

MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config
qemu: MODULE_SEARCH_PATH += /mnt/disk2/l4_snapshot/build/:/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf:/mnt/disk2/l4_snapshot/tudos/l4/pkg/io/config

Now, you can either build all packages inside the L4Re build dir by just issuing the make command or build only the needed packages. L4Re is known to sometimes fail to build due to package dependencies when doing parallel make. Issue the make command until it succeeds. Alternatively, you can build only the needed packages using the S= parameter. Here is a command to build everything you need to run the map_rwx test application from the ksys_mem_tests package:

pushd .
        cd "$L4RE_BUILDDIR"
        make "$MAKE_OPTS" S=libirq,input,libvbus,libio,libio-io,drivers,drivers-frst,bootstrap,libsupc++,libgcc-pure,libgcc,crtn,libkproxy,libsigma0,libsupc++-minimal,uclibc-minimal,lua,ned,ksys_mem_tests,log,libc_backends,cxx,cxx_libc_io,l4re,l4re_c,l4re_kernel,l4re_vfs,l4sys,l4util,ldscripts,ldso,libloader,loader,uclibc,moe
popd

creating the u-boot image for the target device

        make MODULES_LIST=/mnt/disk2/l4_snapshot/L4Reap/l4/pkg/ksys_mem_tests/conf/modules.list uimage E=map_rwx

        # copy the uimage to the device or the TFTP server or whatever
        cp images/bootstrap.uimage /srv/tftp/panda/uImage

building l4linux

You will need to additionally build the following L4Re packages:

io,libstdc++-v3,libvcpu,shmc

to compile l4linux

# create the l4linux build directory
pushd .
        cd "$FOC_ROOT/l4linux"
        make O="$L4LINUX_BUILDDIR" arm_defconfig
popd

# actually compile
pushd .
        cd "$L4LINUX_BUILDDIR"
        #you can configure the kernel now
        make menuconfig

        #edit the config and set up the path to the fiasco build directory
        echo CONFIG_L4_OBJ_TREE=\\"$L4_BUILDDIR\\" >> $L4BUI/l4reap/.config

        make O=$PWD/../build_l4re L4ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j10
        mkdir -p "$L4RE_BUILDDIR/bin/arm_armv7a"
        cp vmlinuz.arm "$L4RE_BUILDDIR/bin/arm_armv7a/l4f/vmlinuz.arm" 
popd

building initial RAMdisk

You may get a prebuilt ramdisk or create one using buildroot. Get the prebuilt image from:

pushd .
        cd "$L4RE_BUILDDIR"
        wget http://genode.org/files/release-11.11/l4lx/initrd-arm.gz -O bin/arm_armv7a/ramdisk-arm.rd
popd

You may want to customize the contents of the ramdisk. To do so, you need to do the following:

#extract the ramdisk
cpio -i /path/to/ramdisk.img

#make a new image
find . | cpio -o -H newc > /path/to/new_ramdisk.img

building PaX tests for L4Linux

        tar xvf pax_tests_l4linux.tar.gz
        cd pax_tests_l4linux
        make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Done, the binaries are in the pax_tests_l4linux directory.

;T; @: versioni