Linux‑ядро в Termux: кросс‑компиляция и отладка собственных системных вызовов на Android

Termux позволяет превратить Android‑устройство в удобную лабораторию разработки: компиляторы, отладчики, скрипты сборки и инструментальная цепочка. Однако «собрать и запустить» полноценное Linux‑ядро на реальном Android — это отдельная инженерная задача: потребуется корректная настройка среды, подбор инструментария, получение исходников нужной ветки ядра, а для отладки собственных системных вызовов — продуманная схема разворачивания и логирования.

В этой статье мы разберем практический подход к кросс‑компиляции ядра из Termux, созданию/подключению модулей и безопасной отладке собственных системных вызовов. Материал ориентирован на инженерные цели обучения и разработки в рамках действующего законодательства РФ и правил информационной безопасности.

Что важно знать заранее (реальность Android‑ядра и ограничения)

Android обычно использует кастомное ядро: напрямую «заменить ядро» на большинстве устройств без поддержки загрузчика/образа ядра сложно и рискованно.
Сборка ядра и модулей требует совпадения архитектуры: чаще всего это aarch64 (ARM64), реже — arm (ARM32).
Системные вызовы (syscalls) обычно требуют изменения исходников ядра и пересборки соответствующего образа. На Android это обычно делается под целевую версию ядра и с подготовкой образов для загрузки.
Отладка на реальном устройстве упирается в доступ к логу ядра, возможности загрузки и, при необходимости, трассировку (например, через Kprobes/eBPF или логирование в ядро).

Подготовка Termux: инструменты сборки и инфраструктура

Начните с актуальной установки Termux и базовых пакетов. Для надежной сборки ядра вам понадобятся компилятор, binutils, пакеты для сборки (make, flex/bison и т.д.) и инструменты для работы с архивами.

pkg update && pkg upgrade -y
pkg install -y git curl wget ca-certificates make clang lld python3 nano tar unzip xz-utils bc bison flex rsync

Дальше важно выбрать способ кросс‑компиляции:

Кросс‑компиляция из Android (Termux) — удобна, но требует корректного toolchain и настроек.
Сборка в среде с готовым toolchain (например, Docker/локальная машина) — иногда быстрее и воспроизводимее.

Так как заголовок статьи про Termux, рассмотрим вариант именно с ним.

Выбор toolchain для кросс‑компиляции ядра (ARM64)

Для ARM64 ядра чаще всего применяют LLVM/Clang‑цепочку либо GNU toolchain. В любом случае, исходники ядра подскажут рекомендуемый инструмент.

Один из практичных подходов — использовать LLVM (clang/lld), поскольку вы уже установили их в Termux. Для этого подготовьте минимальный набор переменных окружения.

export ARCH=arm64
export SUBARCH=arm64
export CROSS_COMPILE=  # для clang часто не требуется GNU prefix
export CC=clang

В реальности для ядра часто потребуется дополнительная настройка LLVM и пути к LLVM=1. Проверяйте документацию в Documentation/process/ выбранной ветки ядра.

Получение исходников ядра и подготовка конфигурации

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

Типовые шаги:

скачать исходники ядра (официальные/кастомные под вашу платформу);
получить базовую конфигурацию (.config);
собрать образ и проверить ошибки компиляции.

Пример: клонирование репозитория (выберите свою ветку):

git clone https://example.com/linux-kernel.git
cd linux-kernel

Дальше найдите/получите .config. В некоторых случаях конфигурация доступна в дереве устройства или ее можно восстановить из вашего образа (это зависит от производителя и доступных артефактов).

Если у вас есть базовый .config, положите его в корень дерева ядра и запускайте:

make olddefconfig

Сборка ядра (kernel build) в Termux

После подготовки конфигурации переходите к сборке. Запуск параллельных задач ускоряет процесс. Количество потоков можно привязать к ресурсам устройства.

JOBS=4  # при необходимости подберите под устройство
make -j$JOBS Image.gz-dtb

Точное имя цели зависит от SoC и структуры дерева ядра. Возможные варианты включают:

Image.gz
Image.gz-dtb
иные targets для конкретного устройства

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

Патч собственных системных вызовов: как подойти инженерно

Добавление системного вызова — это не только «дописать обработчик». Нужно:

объявить syscall номер и интерфейс;
реализовать обработчик в ядре;
обновить таблицы системных вызовов для вашей архитектуры;
учесть ABI и корректный перенос типов;
собрать и проверить, что номер syscall не конфликтует.

В ядре Linux таблицы и инфраструктура различаются по архитектурам. Обычно вам придется править файлы наподобие arch/arm64/kernel/sys.c, а также соответствующие таблицы, которые зависят от вашей ветки ядра. Для начала используйте шаблон существующих syscall’ов.

В практическом цикле удобно делать так:

добавить минимальный syscall, возвращающий фиксированное значение;
включить логирование в ядро (аккуратно и минимально);
проверить вызов из user-space;
расширять функциональность только после подтверждения базовой работоспособности.

Отладка: как понять, что syscall реально исполняется

На Android‑устройствах без избыточных экспериментов лучше делать отладку через управляемые механизмы ядра и логирование.

Способ 1: логирование в ядро и чтение ring buffer

Например, внутри обработчика syscalls можно временно использовать pr_info()/printk(). Затем на стороне системы смотрите kernel log через dmesg или просмотр /proc/kmsg (в зависимости от прав и конфигурации).

# на хосте/в среде разработки (или на устройстве с достаточными правами)
dmesg -w

Если лог не виден — проверьте уровень логирования в ядре, а также настройки android kernel logging.

Способ 2: отладка через трассировку (при наличии)

В современных системах иногда доступны ftrace/tracepoints/eBPF. Однако набор зависит от конфигурации ядра. Если вы включали необходимые опции, можно собрать трассу вызовов и убедиться в исполнении.

Общий принцип: сначала подтверждаем, что syscall вызывается, затем — что данные проходят корректно, и только после этого переносим отладку в более сложные ветки логики.

Тестирование из user-space: минимальный клиент

Вы можете написать небольшой C‑клиент, который вызывает ваш syscall. Номер syscall зависит от вашей правки и архитектуры. Ниже пример общего скелета. Номер замените на ваш.

cat > test_syscall.c << 'EOF'
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <errno.h>

#ifndef NR_my_syscall
#define NR_my_syscall 400  // Замените на реальный номер
#endif

int main() {
    long ret = syscall(__NR_my_syscall, 1, 2, 3);
    if (ret < 0) {
        printf("syscall failed: ret=%ld errno=%d
", ret, errno);
        return 1;
    }
    printf("syscall ok: ret=%ld
", ret);
    return 0;
}
EOF

clang -O2 -o test_syscall test_syscall.c
./test_syscall

Важно: если syscall корректно реализован в ядре, но вы не обновили/не перезагрузили образ ядра на устройстве, тест будет «падать» или возвращать ошибку. Поэтому этап «перезагрузка/внедрение ядра» критичен.

Загрузка нового ядра: практический контур без «самодеятельности»

Как именно «установить ядро» на Android зависит от устройства: boot image, dtb, vendor boot, fastboot‑процедуры и политика производителя. Это зона, где легко повредить устройство. В рамках безопасного подхода:

делайте резервные копии;
используйте официальные и документированные механизмы (например, fastboot там, где это предусмотрено);
проверяйте совместимость образов с вашей версией загрузчика;
не делайте необратимых изменений без понимания структуры boot image для вашего устройства.

Если у вас нет уверенности — лучше обратиться к специалистам, поскольку ошибки на этапе образов могут привести к неработоспособности устройства.

План работ: от «первой сборки» до «валидного syscall»

Соберите ядро без изменений и убедитесь, что оно загружается (или хотя бы компилируется и проходит контроль).
Сделайте минимальный syscall, который возвращает константу.
Подключите тест из user-space и проверьте значение/ошибки.
Добавьте логирование (временно), чтобы подтвердить маршрут исполнения.
Уберите избыточные принты и закрепите поведение.

Про сеть и лабораторную инфраструктуру (опционально)

Если вам нужно организовать передачу логов или взаимодействие инструментаря, допустим вариант создания локальной сети (например, через Wi‑Fi tethering или локальный роутер). Это делается для удобства тестовой лаборатории и не преследует целей обхода блокировок.

Частые ошибки и как их обходить

Не совпадает ARCH/SUBARCH: симптомы — тысячи ошибок компиляции, несовпадение типов и сборка не находит нужные include.
toolchain не подходит под ядро: проверьте требования версии clang/lld и опции ядра для LLVM.
Нет обновления boot image: syscall «не найден» или ведет себя иначе — значит, вы тестируете не то ядро.
Неправильный номер syscall: клиент вызывает другой номер и «видит» чужую реализацию или ENOSYS.
Конфликт ABI: неверные типы аргументов приводят к ошибкам копирования/разыменования.

Заключение

Сборка Linux‑ядра в Termux и последующая отладка собственных системных вызовов на Android — это реальная инженерная лаборатория: от выбора правильной конфигурации и toolchain до безопасного тестирования изменений в ядре и верификации исполнения syscall. Начинайте с минимальных экспериментов, тщательно проверяйте соответствие архитектуры и версий, и используйте логирование/трассировку для подтверждения маршрута исполнения.

Если вам нужна помощь с настройкой toolchain, планом сборки под вашу конкретную платформу, подготовкой образов или организацией отладки — команда РыбинскЛАБ окажет услуги по Linux/Android‑разработке и инфраструктуре для безопасного выполнения работ.