Linux *

#include <stdio.h>

void main() {
  printf("Hello World!\n");
}

Очень странно, но долгие годы подряд никто не переводил на русский «Free as in Freedom 2.0» — фундаментальную книгу про Ричарда Столлмана и его крестовый поход против проприетарного ПО, соглашений о неразглашении и других вещей, попирающих фундаментальные человеческие свободы в цифровую эпоху. Время это исправить!

В предыдущей части я приблизительно описал, как можно загрузить eBPF функции из ELF-файла. Теперь пришла пора перейти от фэнтези к советским мультикам, и следуя мудрому совету, потратив один раз некоторое количество усилий, сделать универсальный инструмент инструментации (или, сокращённо, УИИ!!!). При этом я воспользуюсь антипаттерном проектирования «Золотой молоток» и сооружу инструмент из относительно знакомого мне QEMU. Бонусом за это мы получим кросс-архитектурную инструментацию, а также инструментацию на уровне целого виртуального компьютера. Инструментация будет вида «небольшой нативный so-шничек + небольшой .o-файл с eBPF». При этом eBPF-функции будут подставляться перед соответствующими инструкциями внутреннего представления QEMU перед оптимизацией и кодогенерацией.

В итоге сама инструментация, добавляемая при кодогенерации (то есть, не считая пары килобайтов обычного сишного рантайма), выглядит вот так, и это не псевдокод:

#include <stdint.h>

extern uint8_t *__afl_area_ptr;
extern uint64_t prev;

void inst_qemu_brcond_i64(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u)
{
    __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1;
    prev = tag;
}

void inst_qemu_brcond_i32(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u)
{
    __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1;
    prev = tag;
}

Что же, пора загрузить нашего эльфа в Матрицу. Ну, как загрузить, скорее вмазать распылить.

Внимание: содержит системное программирование. Да, в сущности, ничего другого и не содержит.

Давайте представим, что вам дали задание написать фэнтезийно-фантастическую игру. Ну там про эльфов. И про виртуальную реальность. Вы с детства мечтали написать что-нибудь эдакое и, не раздумывая, соглашаетесь. Вскоре вы понимаете, что о мире эльфов вы знаете по большей части из анекдотов со старого башорга и прочих разрозненных источников. Упс, неувязочка. Ну, где наша не пропадала… Наученный богатым программистским опытом, вы отправляетесь в Гугл, вводите «Elf specification» и идёте по ссылкам. О! Вот эта ведёт на какую-то PDF-ку… так, что тут у нас… какой-то Elf32_Sword — эльфийские мечи — похоже, то что нужно. 32 — это, по-видимому, уровень персонажа, а две четвёрки в следующих столбцах — это урон, наверное. Точно то, что нужно, да к тому же как систематизировано!..

Под катом расположен перевод опубликованного FAQ'а о деталях будущей WSL второй версии (автор — Craig Loewen).

Уровни привилегий

• Кольцо 3. Приложения: минимальные привилегии, за исключением песочницы в пользовательском пространстве, которая ещё больше ограничена.
  
• Кольцо 0. Ядро: ядро операционной системы, в случае ОС с открытым исходным кодом вы видите его код.
  
• Кольцо −1. Гипервизор: мониторинг виртуальных машин (VMM), создаёт и запускает виртуальные машины. В гипервизорах с открытым исходным кодом, таких как Xen, KVM, bhyve и другие, вы видите код.
  
• Кольцо −2. Режим управления системой (SMM), ядро UEFI: проприетарный код, подробнее об этом ниже.
  
• Кольцо −3. Движок управления: проприетарный код, подробнее об этом ниже.

Stack technology

NET Standard

Cross Platform

В данном разделе я рассматриваю часть возможностей по кастомизации, которые потребовались мне. Это не полный список того, что предлагает buildroot, но они вполне рабочие и не требуют вмешательства в файлы самого buildroot.

В данной статье я постараюсь рассказать о фреймворке SpaceVIL (Space of Visual Items Layout), который служит для построения пользовательских графических интерфейсов на платформах .Net / .Net Core и JVM.

SpaceVIL является кроссплатформенным и мультиязычным фреймворком, в его основе лежит графическая технология OpenGL, а за создание окон отвечает библиотека GLFW. Используя данный фреймворк, вы можете работать и создавать графические клиентские приложения в операционных системах Linux, Mac OS X, Windows. Для программистов C# в данное время это особенно актуально, учитывая, что Microsoft не собирается переносить WPF на другие ОС и Avalonia является единственным возможным аналогом. Особенностью же SpaceVIL в этом конкретном случае является мультиязычность, то есть на данный момент фреймворк под .Net Core можно использовать в связке со следующими языками программирования: C#, VisualBasic. Фреймворк под JVM можно использовать в связке с языками Java и Scala. То есть, SpaceVIL можно использовать с любым из этих языков и итоговый код будет выглядеть одинаково, поэтому при переходе на другой язык переучиваться заново не придется.

SpaceVIL пока находится на стадии альфы, но, несмотря на это, фреймворк можно полноценно использовать уже сейчас, так как во фреймворке есть все необходимое для построения как сложного UI, так и для создания совершенно новых визуальных пользовательских элементов. Цель данной статьи как раз в том, чтобы убедить вас в этом.

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

Зачем собирать свой дистрибутив? Зачастую нужен ограниченный функционал при ограниченных ресурсах. Ещё чаще в автоматизации нужно создавать прошивки. Приспосабливать дистрибутив общего назначения, вычищая лишние пакеты и превращать его в прошивку путь более трудоёмкий, чем собрать новый дистриб. Использование Gentoo тоже имеет свои ограничения.

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Введение

Небольшая предыстория