Когда я только знакомился с OSDev, я очень долго искал соответствующие материалы. Находил и на YouTube, и на Habr, и просто какие‑то англоязычные сайты (тогда я не сильно знал английский). Но почти все что я находил было либо незаконченным, либо недостаточно понятным и полным.
В этой статье я постараюсь рассказать все так, как ожидал я это от других.
Когда я начал работать с CH32V203G6U6 и обнаружил, что там есть 64-битный аппаратный таймер, то подумал: ух, это же отлично, раз таймер аппаратный, то и о чтении/записи заботится сам микроконтроллер. И какое-то время это не вызывало вопросов. А потом…
Не потому, что контейнерному миру срочно нужен ещё один init. Есть Tini, есть docker run --init, и для большинства production-сценариев я бы по-прежнему начал именно с них.
Мне скорее хотелось разобрать задачу до самого нижнего уровня: без libc, без runtime, напрямую через Linux syscalls. Заодно проверить, насколько сильно будет отличаться одна и та же реализация на x86-64 и ARM64.
В итоге из небольшого эксперимента получился mini-init-asm: PID 1, который запускает приложение в отдельной process group, передаёт сигналы всей группе, собирает zombie-процессы и умеет корректно завершать контейнер с exit code приложения.
Позже туда добавились subreaper mode и простой restart-on-crash. А сам проект в итоге доехал сначала до Debian unstable, а затем и до testing.
Но началось всё с вопроса: что вообще должен уметь нормальный PID 1 внутри контейнера?
В предыдущих постах мы подробно разбирали каждый слой: CPU, арифметику, скриптовый интерпретатор, оборудование. Вот, что окончательный отчёт о синтезе Quartus сообщает обо всех них: в готовой архитектуре используется 1593 логические ячейки из доступных в EP2C5 4608 (35% чипа) с 594 выделенными логическими регистрами и 17 блоками памяти M4K. Сам модуль CPU занимает 1173 из этих логических ячеек и 400 регистров. Остальная логика отдана периферии: драйверу ЖК‑дисплея (154 логические ячейки), сканеру клавиатуры (97), интерфейсу термопринтера (64), таймеру CTC (49) и аппаратному PRNG (20). 12 блоков памяти M4K занимает ROM микрокода (49152 бит: это полная программа калькулятора), 2 блока — ROM скриптинга (8192 бита), 1 — ROM BCD‑констант, 1 — таблица поиска для BCD‑умножения внутри CPU и 1 блок — ОЗУ. Меня это очень радует: полнофункциональный научный калькулятор уместился в 35% небольшой дешёвой FPGA.
В детстве я учился программированию на старом IBM PC с монохромным зелёным монитором, поэтому давно хотел создать программу для этой системы. За последние пятнадцать лет я написал более чем сотню небольших интро. В последнее время я был не так активен, но потрясающее интро «Rainbow Surf» автора Plex размером всего 16 байт мотивировало меня снова вернуться к старым наброскам и взяться за работу.
Создание этой программы сопровождалось привычными экспериментами. Я развлекался с клеточными автоматами в графике и звуке, а также исследовал трюки sizecoding. В частности: а) полиморфные ассемблерные команды (наподобие add [bx+si],al, имеющую машинный код 0x0000) б) переход в середины команд для экономии байт и многократного использования опкодов. Из сотен мелких экспериментов мне приглянулся один, интересный одним только своим названием.
Когда я дополнял всё это и избавился от лишнего, мне трудно было понять, что же происходит. Я чесал в затылке, глядя на простую формулу, оставшуюся после удаления код‑гольфингом кучи байт. Я и сам не ожидал, что объяснение этих считанных байт окажется настолько глубоким.
В моём интро «M8trix» 2014 года по экрану уже бегали псевдослучайные буквы (в 8 байтах, а потом и в 7), но мне всегда было интересно, как добавить к ним красивый звук. Но хронологически в разработке «wakeup» я сначала занимался звуком. Хорошим подзаголовком к статье мог бы быть «16 байт, превращающие звук треугольника Серпинского в дождь символов из „Матрицы“».
Примечание: на каждом такте времени новая строка треугольника Серпинского а) воспроизводится через динамик б) отрисовывается на экране с шагом 56. Можно ощутить движение, но не увидеть его, потому что оно имеет «ширину» 8192 пикселей, но одна строка символов состоит всего из 80 байт. Если бы экран был гораздо больше, то можно было бы увидеть треугольник. Или если не пропускать пиксели и рисовать и все одновременно, он тоже был бы виден.
В этой части мы начнём с тупика, в который приводит голый цикл FMOPA; затем покажем, какую часть GEMM BLIS уже построил за нас; после этого разберём пять циклов BLIS и место микроядра внутри них. Финал главы должен сделать дальнейший план конкретным: что именно нужно добавить для Apple SME, а что уже относится к готовой «мебели» фреймворка.
Эта статья посвящена путешествию в мир ретропрограммирования. Надеюсь, в ней у меня получится передать вам то чувство восхищения, которое я испытал и которое заставило меня написать этот пост. Пост о том, как создавать ПО для компьютерной системы Atari ST, выпущенной в 1985 году.
Atari ST относится ко второй крупной волне домашних компьютеров. Первая волна, созданная на основе 8-битных CPU, принесла в наши дома такие знаковые машины, как Commodore C64 и Sinclair Spectrum. Вторую волну разрабатывали на основе 16-битных CPU; она породила Apple Macintosh, Commodore Amiga и, разумеется, Atari ST.
Atari ST 1040 STF с цветным монитором Atari SC1224
Типичный Atari ST (например, 1040 STFM) имел CPU Motorola 68000 с тактовой частотой 8 МГц и 1 МБ ОЗУ; он загружал ПО с 3,5-дюймовых гибких дисков. Его графические возможности состояли из монохромного режима высокого разрешения 640x400 и 16-цветного режима 320x200, получившего наибольшую популярность в играх.
Рабочий стол GEM Atari ST имел интерфейс, очень похожий на разработанный Xerox и Apple, у него были диспетчер файлов, иконки и многооконность. Это его монохромная версия высокого разрешения.
Если у вас нет реального Atari ST, то его можно просто эмулировать на современном компьютере. Первые эмуляторы появились ещё в 90-х. Хорошим считается Hatari, который существует для большинства современных платформ. В эмуляторе также есть современные инструменты разработки. В прошлом приходилось пользоваться неуклюжим ПО разработки, которое загружалось с дискет, а сегодня можно просто писать всё в VSCode и компилировать современным GCC. У нас есть доступ к современным графическим редакторам наподобие GIMP, и мы даже можем просить помощи у ИИ.
Три статьи я собирал файл и отдавал его эмулятору, ни разу в него не заглянув. Заглянул. Внутри два разных описания одних и тех же байтов, ответ на вопрос, откуда взялся адрес 0x80000000, и поле, которое я заполнял зря.
Вы запускаете программу, о которой ничего не знаете. Она вежливо просит строку, а в ответ на ваш ввод насмешливо отвечает: «Bro, what are you trying to do?» И правда, что мы пытаемся сделать? Пытаемся понять ее.
Перед нами crackme – программа-головоломка, написанная для тренировки навыков обратной разработки: бинарник под Linux x86-64 без исходников и документации, который издевается над каждым, кто не смог его разгадать. Это первая статья цикла из трех о гибридном анализе крякми Getting Started Keygen (Mazzottis). Мы осмотрим файл штатными утилитами, найдем main в Ghidra, расшифруем «бессмысленные» имена переменных в реальную раскладку стека и подтвердим гипотезы в GDB. По пути встретим оптимизированный пролог без RBP, «хитрое» беззнаковое условие и std::string, спрятавшийся в трех переменных, которые на первый взгляд никак не связаны.
Во второй части цикла – мутационное тестирование и реконструкция скрытой структуры, в третьей – полный разбор хеш-функции и восстановление алгоритма на Python.
В прошлый раз я писал про потерянное пробуждение и получил в комментариях справедливое замечание, что примитив там классический. Так и есть. Сегодня про место, где классики меньше: как в моём ядре устроено переключение контекста, и почему ассемблер там знает смещение поля в структуре Rust.
Это неприятная связь. Ассемблеру нужен байтовый доступ к сохранённым регистрам, а раскладку структуры определяет компилятор. Если эти двое разойдутся во мнениях, вы не получите ошибку компиляции. Вы получите ядро, которое пишет регистры мимо и падает где-то далеко от места ошибки.
Написал рекурсию тем же приёмом, что во второй статье, и программа повисла навсегда: возвращаться ей было некуда. Чиню, завожу стек и по дороге выясняю, что регистра sp в наборе команд нет вовсе. А потом урезаю стек до 128 байт, и сборка об этом не говорит ни слова.
В этой части мы проверим, есть ли у SME учебная дорога, сравнимая с той, которую получили тензорные ядра GPU; затем разберём два реально полезных источника: Arm Learning Path и KleidiAI; после этого отделим то, чему они действительно учат, от того, где они останавливаются. К концу главы станет видно, какая именно «середина лестницы» отсутствует и почему следующая часть неизбежно приводит к BLIS.
Это продолжение статьи Материалы по хакингу на русском.
Вкратце — я собираю автоматические переводы материалов по хакингу и выкладываю их на сайте библиотеки. В этой подборке — книги для тех, кто хочет понимать программы, железо и протоколы не по документации, а изнутри: от устройства компьютера и ассемблера до Windows Kernel, ARM, Java-байткода, автомобильных шин, VoIP и аппаратного реверса.
Через четыре часа после первой статьи пришёл комментарий: в моём коде не хватает трёх инструкций, и на настоящей плате он рассыплется.
Читатель arteast был прав.
Сел воспроизводить поломку. Собрал два варианта, свой и правильный, прогнал на строке в 231 байт. Вывод побайтово одинаковый. Замедлил линию до предела. Ничего не изменилось. Написал программу, которая смотрит, бывает ли передатчик занят хоть когда-нибудь. При выводе в консоль не бывает.
Моя ошибка внутри эмулятора не проявляется вообще. Проверить себя было нечем.
Пришлось чинить эмулятор.
Без библиотек, без обвязок, без операционной системы под ногами. Реальный код на реальном железе — ну, почти реальном.
Пустая эмулируемая машина RISC-V, десяток строк ассемблера, и в терминале:
Сначала думал вывести «hello», как все.
Пусть будет «Привет, мир!»
Часть 1 цикла о программировании Apple Scalable Matrix Extension (SME2) — от первых принципов до промышленной реализации GEMM.
Описанный в предыдущих частях калькулятор уже работал. Реализация 2021 года запускалась на реальном оборудовании, обрабатывала нажатия клавиш, вычисляла результаты и отображала их. Арифметика была корректной в том смысле, что большинство результатов было точным до 12 значимых разрядов, а это больше, чем требуется обычному пользователю.
Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.
В итоге, версия 2025 года устранила найденные мной проблемы. Это был не патч, а почти полное переписывание арифметического движка, расширение набора команд CPU и существенное увеличение библиотеки функций. В этом посте я расскажу об изменениях и их причинах.
В июле 1980 года Recreational Computing напечатал листинг The Wizard's Castle — рогалика на BASIC для микрокомпьютера Exidy Sorcerer. Первая строка выглядела так: 10 REM"_(C2SLFF4 .
REM — это комментарий: интерпретатор его пропускает, писать туда что-то имеет смысл только для человека. Вот только читать здесь нечего, сплошная абракадабра из символов.
Мы подняли эмуляторы, залезли в дампы памяти и выяснили, что комментарий здесь вовсе не комментарий. А заодно, что у читателя, честно перепечатавшего листинг, не было и шанса запустить игру.
Когда на экране терминала появилось приглашение #, Flipper Zero уже сложно было назвать просто устройством для работы с радиопротоколами, NFC и инфракрасными пультами. Передо мной находился маленький Unix-подобный компьютер: с ядром, процессами, командной оболочкой и файловой системой на microSD.
Как часто нам приходится читать в бюллетенях безопасности «Уязвимость... позволяющая нарушителю выполнить произвольный код с помощью специально сформированного запроса». Но что на самом деле скрывается за этой фразой? Что это за специальные запросы и как наша программа может выполнять чужой код, если мы досконально знаем в ней каждую строчку и каждую библиотеку?
И почему тогда Apple платит до двух миллионов долларов за одну найденную уязвимость и выстраивает многоуровневую аппаратную защиту — а айфоны всё равно взламывают по нажатию одной кнопки?
Всё дело в том, что сами атаки стали другими. Когда инженеры перекрыли большинство очевидных ходов, хакерам пришлось изменить сам подход к взлому. Вместо поиска лазеек они научились брать легитимные вычисления программы и строить поверх них... виртуальный процессор. Даже стандартную функцию вывода текста printf удалось превратить в Тьюринг-полный интерпретатор — то есть вычислитель, способный выполнить любой алгоритм.
Перед нами — Data-Only атаки, где взлом превращается в программирование на «невидимом» процессоре. Процессоре, команды которого — лишь побочный эффект работы нашей собственной программы.
Но чтобы понять, как мы здесь оказались, придётся вернуться на двадцать лет назад.
