Сразу скажу - я не считаю себя втором Терри Дэвисом и тем более не хочу делать аналог Виндовс. Изначально я все это затеял только ради прикола и изучения ассемблера.

А, и если что - мне 14, но я не против любой критики. И да, я тоже как и большинство местами использовал ИИ. Я не сидел читал мануалы часами, просто гуглил или просил нейронку пояснить.

Так а в чем же проблема x86_64?

Я так скажу - я пробовал писать под эту архитектуру. Мне не понравилось, всякие режимы (которые за меня правда переключал загрузчик), да и местный ассемблер мне было лень изучать. Просто захотел писать под более новую архитектуру.

Не буду говорить, что RISC-V лучшая, но я просто выбрал ее. Прикол в том, что инструкции короткие, да и в целом достаточно перспективно. Хотя и тут были проблемы.

Был драйвер, стала ОС

Я ничего с нуля не писал.Все началось с пыток ИИ, когда я пытался выдавить из него то обращение по конкретному адресу для доступа к графике, то опрос портов, то еще что-то такое. Мне стало лень и я пошел искать что-то плюс-минус готовое. И я нашел его - ramfb. По сути я получил готовый указатель на фреймбуфер для вывода на экран… И все. Но и на этом большое спасибо авторам драйвера. Дальше началась моя ОС.

А где хранить данные?

А тут первая проблема - как таковой кучи у меня еще нету. Есть стек, который за меня выделил автор драйвера. Есть всякие глобальные переменные. Но что если мне нужно много памяти (например, под картинки) и я не знаю точный размер? И в добавок, кто вообще рисует напрямую на экран? Тут нужен некий массив пикселей, который будет лежать в памяти, а по нашей команде быстро перенесется на экран (называется backbuffer).

Под кучу взял 64 мб из памяти, так как Qemu, где запускается моя ОС, выделяет ей аж 128 мб, часть уже занята ядром и стеком, но бОльшая часть пустует. Сделал простенький список свободных и занятых блоков памяти.

Это когда ты делишь память на куски, каждый помечаешь как занятый или свободный. Нужно мало памяти - откусываем от большого куска блок. Блок освободился, а рядом есть другой свободный блок - соединяем в один большой.Сразу же добавил функцию, чтобы узнать сколько памяти занято. Сейчас, например, занято около 3-4 мб. Ну это учитывая, что backbuffer и занял почти 3.5 мб.

В оперативной памяти что-то типа

Такая разная многопоточность

Как я думаю большинство знает, если у процессора одно ядро, одновременно на нем может выполняться только одна задача-поток. Но мы же может останавливать задачу, запускать другую, останавливать, запускать еще другую и так много раз в секунду. Тогда будет казаться, будто бы у нас несколько задач выполняются одновременно.

Многопоточность кооперативная

Так мы можем сказать потокам, чтобы если один из них решит, что стоит сделать паузу, сам вызвал yield() и отдал процессор другому потоку. И я это сделал. Все что нужно было - сохранить s-регистры процессора (те, в которых лежат всякие важные значения), указатель на личный стек потока (размер стека задается при создании) и указатель на “дорогу назад” ra. То есть yield() сохраняет эту информацию потока А, затем вместо нее загружает информацию потока Б. И так по кругу.

Кстати, стеки самих потоков я выделял в той самой куче. Просто брал блок на пару кб и говорил потоку: “Это твой стек”.

Но у такого концепта есть проблема - зависает один поток, остальные перестают выполняться. Да и в целом писать yield() каждый раз сложно.

Многопоточность вытесняющая

Поэтому я и решил переписать все на вытеснение. Для начала я сделал так - каждые 100к тиков процессора сохраняются все регистры и пинается функция обработки прерываний. Таймер, по которому будет работать многопоточность - это тоже прерывание. Так же эта функция ловит ошибки по типу kernel panic. Это было сложнее - так как потоки не добровольно отдают процессор, приходится сохранять вообще все 32 регистра. Но криво-косо я написал это и функцию sleep(), во время которой функция простаивает, ее никто не трогает.

А тут еще и ИИ начал выдавать бред, пока я тестировал у меня… начинал выполняться основной код, все было хорошо, а потоки - нет. Я сам не вижу ошибку, ИИ тоже. Он то предложит заменить какую-то часть функции, то еще что-то такое. Наконец я вспомнил про замечательную штуку - gdb. Запустил, посмотрел… Оказалось так - цикл отрисовки экрана был слишком долгим, во время него вызывалось переключение потоков, а их еще не было кроме главного. В итоге я подумал что смысла создавать потоки в конце, после отрисовки, нет, и перенес их в самое начало. Удивительно, но все заработало.

Немного про режимы

Как выяснилось, в RISC-V есть 3 режима (точнее 4, включая гипервизор, но тут он мне точно не нужен) - M-mode с полными привелегиями, S-mode для ядра ОС (я думал что и мое его использует), ну и U-mode для пользователей, но до этого мои ручки еще не дошли.

Ну и по пути я случайно осознал, что мое ядро выполняется аж в М-режиме:

Вызываю я ecall из потока. Смотрю - kernel panic. В логах какой-то код “11”. Оказалось, это и есть ecall - в M-mode он 11, а в S-mode (в котором, как я думал, работало ядро, и который я пытался выловить) это 9. Ну когда я нашел, уже быстро исправил.

Визуальчик

Но в это время на сам экран эмулятора Qemu… Ничего и не выводилось. Совсем. Просто белый экран. Хотелось красоты.

Тогда я вспомнил, что день назад прикрутил qoi.h к моему коду. QOI - формат изображений. Выбрал я его, так как декодер легкий и его удобно использовать в любой ОС, где есть базовые функции.

Я аккуратно, разумеется, согласно лицензии, взял из pop os, которой когда-то пользовался, картинку для фона. Конвертировал ее в .qoi, а так как моя ос еще не умела читать с диска, перевел картинку в заголовочный файл .h. Весит правда много, но влезает.

Дальше я нашел шрифт (Liberation Mono от Red Hat), перегнал и его в .h. Честно, визуал меня не сильно интересовал, поэтому быстро попросил ИИ переделать функции вывода в консоль в функции вывода на экран. Проверил, просмотрел что и как сделано, получилось нормально для старта. Правда пока что в графической консоли нет нормальной перемотки и много чего другого.

Вывод

Конечно, еще нету даже ввода с клавиатуры, мыши, файловой системы (даже простой). Но я считаю, что вышло неплохо, пусть и далеко от уровня реальной ОС типа Линукса. Понятно, что код не очень-то красивый, достаточно простой. Статью я выкладываю больше просто чтобы разобраться самому в том, что я написал.

Если я не забью на код, хотел бы написать еще и MMU и переход в U-mode.

Для тех кому очень интересно - можете глянуть исходный код mqos, там же будут инструкции по запуску.

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

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

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

Большая часть KolibriOS написана на FASM — плоском ассемблере. Это объясняет крошечный размер исполняемых файлов и молниеносную загрузку: система не тратит время на инициализацию абстракций, слоёв совместимости и десятков фоновых служб.

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

Несмотря на размер, KolibriOS поставляется с обширным набором софта. По данным сообщества, в образ входят более 250 программ, включая текстовый процессор, просмотрщик изображений, графический редактор, музыкальный плеер, IRC-клиент и веб-браузеры.

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

Это меняет статус системы с «основной ОС на каждый день» на «платформу для специальных задач». Почта, мессенджеры, облачные сервисы и онлайн-документация остаются недоступны без промежуточного прокси или другой машины.

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Тема получила новый импульс после серии публикаций Диона Доктера (Dion Dokter) из голландской компании Tweede golf. Во второй части он заглядывает внутрь rustc и утверждает: async Rust так и не вышел из состояния MVP. Я не буду дословно переводить его рассуждения, а переосмыслю их с упором на практику: как понять, платите ли вы за async-удобство лишними байтами, и как снизить налог, пока компилятор не научился делать это сам.

• Асинхронный Rust компилируется в state machine: на каждую await-точку приходится отдельное состояние плюс служебные Unresumed, Returned и Panicked.
• Простая функция с двумя await-точками даёт 360 строк MIR против 23 у синхронного кода. Часть излишков LLVM убирает, но не все, особенно при оптимизации по размеру.
• Компилятор не схлопывает идентичные состояния, не инлайнит futures через await, генерирует state machine даже для async-блоков без await и оставляет panic-путь в состоянии Returned.
• В release-сборках замена panic в Returned на возврат Pending может сократить прошивку на 2–5%. Убирание state machine у пустых async-блоков — ещё около 0,2%.
• Пока rustc не исправлен, можно вручную: возвращать impl Future из «прозрачных» функций, использовать std::future::ready, схлопывать await-точки через match и передавать большие данные по ссылке.

Почему async-функция — это всегда state machine

Когда вы пишете async fn, компилятор не просто оборачивает тело в callback. Он строит конечный автомат: enum, где каждый вариант — состояние между await-точками. Это называется coroutine desugaring и происходит на уровне MIR (Mid-level IR) — до того, как код попадает в LLVM.

Рассмотрим минимальный пример. Есть две функции, каждая из которых просто возвращает число, и третья складывает результаты:

У bar две await-точки, поэтому минимум два пользовательских состояния. Но если сдампить MIR после прохода coroutine_resume, картина шире:

Три служебных состояния добавляются всегда. Они нужны, чтобы соблюсти контракт Future::poll: опрос завершённой future не должен приводить к неопределённому поведению. Поэтому после первого Ready future переходит в Returned, а повторный poll паникует. Аналогично Panicked блокирует future после пойманного panic — похоже на poisoning мьютекса.

Логика корректная, но цена высокая: bar порождает 360 строк MIR, а эквивалентный синхронный код — 23. В 15 с лишним раз больше. LLVM часть этого выбросит, но на opt-level = "z" или в толстых async-графах вызовов он быстро сдаётся.

Четыре места, где компилятор работает вхолостую

1. Panic в состоянии Returned

Контракт future требует только отсутствия UB. Паниковать при повторном poll — не обязательно. Можно просто вернуть Pending снова: ничего опасного не произойдёт, а ветка panic — это лишний побочный эффект, который плохо оптимизируется.

Дион сделал экспериментальный патч rustc: в release-режиме Returned больше не паникует. На embedded-прошивках это дало 2–5% экономии бинарного размера. В debug-сборках панику можно оставить, чтобы быстро ловить ошибочный повторный poll, — по аналогии с overflow-checks.

2. State machine без await

Взгляните на функцию без единой await-точки:

Идеальная реализация — всегда возвращать Poll::Ready(5) безо всякого enum. А rustc генерирует полноценный CoroutineLayout с тремя служебными состояниями и switch по дискриминанту. Такие функции часто появляются в трейтах, где один интерфейс должен быть async, но конкретная реализация ничего не ждёт. Патч, убирающий state machine у async-блоков без await, даёт ещё 0,2% размера — мало, но правка тривиальная.

3. Futures не инлайнятся через await

Классический шаблон: адаптер просто пересылает вызов вниз.

Сейчас bar получает собственный state machine, который вызывает state machine foo. Вручную мы бы написали fn bar(blah) -> impl Future { foo(blah) } и избавились бы от лишнего enum. Аналогично с преамбулой и постамбулой: их можно перенести на FutureExt::map из крейта futures.

4. Одинаковые состояния не схлопываются

Если в async-функции несколько веток match ведут к одинаковому await, компилятор создаёт отдельное состояние на каждую ветку:

Здесь send_response вызывается с разными аргументами, но структура состояний дублируется. Если вынести выбор аргумента за await, получится одно состояние вместо двух:

В одном примере из статьи MIR сокращается с 456 до 302 строк, а ассемблер — примерно на 11%. Оптимизации stack, поэтому выигрыш в реальном коде может быть заметнее.

Что делать сегодня, не дожидаясь rustc

Всё перечисленное выше — это работа для команды компилятора. Но релиз с этими патчами может занять месяцы, а то и годы. Пока он не вышел, можно снизить async-bloat в своём коде.

Главный принцип: каждый лишний async fn — это лишний state machine. Если функция не содержит await, не делайте её async.

Заменяйте async-пустышки на impl Future

Типичный случай — трейт, где одна реализация реально ждёт ввода-вывода, а другая просто возвращает значение.

Вместо полноценного state machine получается готовая future, которая сразу возвращает Ready. Это особенно полезно в embedded-HAL, где трейты часто async, но конкретный драйвер может делать только прямой доступ к регистрам.

Прозрачные обёртки без await

Если функция только пересылает await вниз, уберите await:

Схлопывайте await-точки

Если несколько веток match заканчиваются одним и тем же await, вынесите выбор аргументов наружу. Это уменьшает число состояний state machine и облегчает жизнь LLVM.

Передавайте большие данные по ссылке

Async-функция захватывает в state machine всё, что живёт через await. Если передать массив по значению, он окажется внутри future целиком:

Разница в 52 раза по размеру future — и это без учёта memcpy, который компилятор вынужден вставлять при перемещении больших значений.

Перспективы: Project Goal и финансирование

Дион оформил эти идеи как Rust Project Goal — формальный механизм, через который команды заявляют цели на полугодие. По его оценке, работа требует порядка €30 000 финансирования. Для компиляторного проекта это скромная сумма: речь идёт о 2–5% размера прошивки практически в любом async-проекте.

Есть и другой подход к той же проблеме: не убирать state machine на входе, а научить LLVM лучше их оптимизировать на выходе. Дион считает, что оба направления дополняют друг друга. Чем проще state machine попадает в LLVM, тем эффективнее её можно проинлайнить и упростить на поздних проходах.

Выводы

Async Rust never left the MVP state. The compiler generates state machines with a lot of unnecessary baggage. With a few targeted optimizations in rustc we can get smaller binaries and better performance for everyone.

Утверждение «async Rust так и не вышел из MVP» звучит резко, но поясняет, почему наши «zero-cost» абстракции иногда всё-таки стоят дорого. Компилятор делает корректный, но не оптимальный код: лишние panic-ветки, неинлайненные futures, дублирующиеся состояния и state machine там, где они не нужны.

Для embedded и WASM это не абстрактная проблема, а конкретные килобайты прошивки. Пока rustc учится, разработчик может снизить налог вручную: убирать async у функций без await, возвращать impl Future из прозрачных обёрток, схлопывать await-точки и не передавать большие структуры по значению.

Если ваш проект на Rust бьётся о лимит flash, имеет смысл посмотреть на async-граф вызовов свежим взглядом. Часто проще убрать одну лишнюю async-обёртку, чем месяцами ждать патч в компиляторе.

Источники:
— Dion Dokter, «Async Rust never left the MVP state»;
— Dion Dokter, «Debloat your async Rust»;
— Rust Project Goal: Async state machine optimisation.

Что такое протокол передачи данных

Под протоколом передачи данных здесь понимается формат пакетов (кадров), которые строятся поверх физического уровня. Физический уровень — это уже выбранный интерфейс: RS-232, RS-485, инфракрасный канал, радиомодуль или оптоволокно. От него мы получаем две базовые операции: отправить один байт и принять один байт. Всё остальное — наша задача.

Данные передаются пакетами — кадрами. Хороший кадр позволяет приёмнику понять: где начало сообщения, кому оно адресовано, сколько в нём полезных данных и не повредились ли они по дороге.

Кадр состоит из заголовка, адресов, типа данных, длины, полезной нагрузки, контрольной суммы и концевика.

Для защиты от случайных совпадений заголовок делают многобайтовым, а контрольную сумму считают по всей значащей части кадра.

Парсинг удобно реализовывать конечным автоматом: каждый принятый байт переводит машину в новое состояние.

На хосте данные почти всегда буферизуются; на простых МК часто выгоднее передавать напрямую, чтобы сэкономить ОЗУ.

Структура кадра: из чего собирать пакет

Надёжный протокол обычно включает семь логических полей. Не все обязательны — выбор зависит от задачи.

Заголовок и концевик

Заголовок (frame header) и концевик (frame tail) отмечают границы кадра. Главное требование — минимизировать вероятность случайного совпадения этих байтов в потоке данных. Есть два подхода:

• Подбор характерных байтов. Если данные предсказуемы (например, только ASCII-текст), можно выбрать заголовок из диапазона непечатаемых символов.
• Увеличение длины. Для случайных данных лучше сделать заголовок многобайтовым — например, 0x55 0xAA 0x7E. Вероятность случайного совпадения трёх конкретных байтов подряд падает экспоненциально. Даже если совпадение произойдёт, его отловит контрольная сумма.

Адресация

Адрес назначения нужен в системах типа «один к многим» — например, когда один хост управляет несколькими датчиками по общей шине RS-485. В сложных сетях добавляют ещё и адрес источника, чтобы получатель знал, от кого пришёл пакет.

Тип, длина и данные

Тип данных (data type) говорит, что дальше идёт команда или полезная нагрузка. Длина (data length) указывает число значащих байтов в блоке данных. Вместе они образуют «тело» кадра — ту часть, которую мы действительно хотим доставить.

Контрольная сумма

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

Передача: хост и микроконтроллер

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

Передача с микроконтроллера

На простых контроллерах вроде семейства 8051 часто используют прямую передачу: процессор загружает байт в буфер UART и ждёт флага готовности. Плюс — данные моментально оказываются на линии. Минус — процессор занят на всё время отправки.

Альтернатива — передача по прерыванию: байты складываются в кольцевой буфер, а прерывание UART отправляет их фоном. Экономит процессорное время, но требует ОЗУ под буфер. На 8051 с его скудной памятью прямая передача часто выигрывает.

Передача с хоста

На ПК данные почти всегда буферизуются операционной системой. Программист работает с тремя уровнями абстракции:

1. Контролы ОС. В Windows — компоненты вроде MSComm (устаревший 32-bit ActiveX, не рекомендуется для новых проектов). Просто, но нужно следить за блокировками при приёме и многопоточностью.
2. Системные API. В Windows и Linux последовательный порт — это файл. Открываем через CreateFile или open(), но перед чтением и записью требуется настройка параметров порта (в Linux — termios со скоростью, чётностью и размером слова).
3. Класс-обёртка. Например, CSerialPort для Windows: он инкапсулирует инициализацию, поток приёма и отправку. После открытия порта вызов WriteToPort отправляет массив байтов, а внутренний поток следит за входящими данными и шлёт сообщения родительскому окну.

Приём и парсинг на конечном автомате

Приём данных на стороне микроконтроллера тоже бывает двух видов: опрос (поллинг) и прерывание. Опрос проще, но отнимает процессорное время. Прерывание эффективнее: байт пришёл — сработала процедура обработки прерывания (ISR, Interrupt Service Routine), процессор отвлёкся на доли миллисекунды и вернулся к задаче.

Где размещать парсер протокола? Если протокол простой, его можно держать прямо в обработчике прерывания: приняли корректный кадр — установили флаг, основной цикл реагирует. Для сложных протоколов лучше писать байты в буфер и разбирать их в главном цикле. Гибридный подход тоже возможен: в прерывании ищем только «команду подключения», а остальное парсим фоном.

Пример: разбор кадра по состояниям

Рассмотрим конкретный формат кадра:

Парсер реализуем через переменную state_machine. Каждое состояние соответствует ожидаемому байту. Если пришёл не тот байт — автомат сбрасывается в ноль. Это защищает от «залипания» в промежуточном состоянии при обрыве связи или помехах.

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

Приём на стороне хоста

На ПК приём организуется проще: операционная система уже буферизует входящие байты. Для неблокирующего чтения запускают отдельный поток, который ждёт данных из порта и передаёт их в основной процесс через сообщения или обратный вызов. Класс CSerialPort, например, отправляет родительскому окну сообщение WM_COMM_RXCHAR с каждым новым байтом. Обработчик этого сообщения просто вызывает тот же парсер, что и на микроконтроллере.

Таким образом, логика разбора протокола единая для обеих сторон. Различается только способ доставки байтов в парсер: прерывание ISR на МК и поток ОС на хосте.

Выводы

Проектирование протокола связи для микроконтроллера — это не ракетостроение, но требует дисциплины. Хороший кадр защищает границы (заголовок + концевик), адресует получателя, указывает длину и проверяет целостность. Парсинг на конечном автомате делает код предсказуемым и устойчивым к сбоям.

Главный принцип — сбрасывать автомат при любом нарушении ожидаемого шаблона. Это предотвращает «залипание» и позволяет системе быстро восстановиться после помехи. На основе этой базы можно наращивать надёжность: добавлять повторные передачи, порядковые номера, шифрование — в зависимости от требований проекта.

Хороший протокол — это не тот, который передаёт быстрее всех, а тот, который не ломается при помехах.

Источник: оригинальная статья Leo Liu — Microcontroller Communication Protocol Design (DEV Community).

Если вы разрабатываете встраиваемые системы или хотите войти в IoT, этот материал — практическое руководство по созданию BLE-периферии с нуля. Мы разберём, как устроен стек, как настроить окружение и как написать код, который управляет железом со смартфона.

Что такое Zephyr OS и зачем она для BLE

Zephyr OS — открытая операционная система реального времени под управлением Linux Foundation. Лицензия Apache 2.0, поддержка более 600 плат на ARM, RISC-V, x86 и других архитектурах. Главное для нас: внутри неё живёт полноценный BLE-стек, прошедший официальную сертификацию Bluetooth SIG. Рекомендуем также обзор «Первый RISC-V RVA23 чип входит в mainline Linux».

Zephyr OS включает сертифицированный BLE-стек с открытым кодом — от приложения до радиоконтроллера.

GAP управляет обнаружением и соединениями, GATT — структурой данных (сервисы и характеристики).

Для старта понадобятся плата nRF52840 DK (~40 USD) и смартфон с приложением nRF Connect.

Прошивка собирается через west — единый инструмент для клонирования, сборки и прошивки.

Оптимизация энергопотребления: интервал advertising, peripheral latency, System OFF и отключение неиспользуемых периферий.

Это означает, что вы работаете не с хобби-реализацией, а со стеком, который прошёл conformance-тестирование. От прикладного кода до радиорегистров — всё открыто. Никаких бинарных блобов. Nordic Semiconductor, чьи чипы доминируют на рынке BLE, построила свой nRF Connect SDK поверх Zephyr. Когда инженеры Nordic пишут прошивку, они используют Zephyr.

Стек поддерживает Bluetooth 5.x (2M PHY, Coded PHY для дальней связи, Extended Advertising), Bluetooth Mesh, LE Audio с кодеком LC3, Direction Finding и все стандартные профили. Если вы делаете BLE-продукт в 2025–2026 годах — Zephyr входит в тройку лучших платформ.

Как работает BLE: два слоя, которые нужно знать

Прежде чем писать код, нужна ментальная модель. BLE — это не «классический» Bluetooth для аудио. Он создан для коротких, редких сеансов связи: датчик проснулся, отправил 20 байт, уснул. Такое устройство может работать от таблеточной батарейки годами.

Разработчик взаимодействует с двумя слоями:

• GAP (Generic Access Profile) — отвечает за обнаружение и соединения. Периферия широковещательно рассылает пакеты (advertising), а central (обычно телефон) их слушает и инициирует подключение.
• GATT (Generic Attribute Profile) — отвечает за обмен данными после соединения. Данные организованы в иерархии: устройство предоставляет сервисы, внутри которых находятся характеристики — единицы данных со свойствами Read, Write, Notify, Indicate.

Каждый сервис и характеристика идентифицируются UUID. Стандартные (от Bluetooth SIG) — 16-битные, пользовательские — 128-битные. Хорошо спроектированный набор сервисов — это API вашего устройства.

Ключевые выводы

Настройка окружения

Для работы понадобится Linux (Ubuntu 22.04+), macOS или Windows с WSL2. Идеальная плата для старта — Nordic nRF52840 DK. Она недорогая, широко доступна и имеет встроенный отладчик J-Link. А ещё посмотрите, как создать самодельные устройства на Raspberry Pi, ESP32 и Node-RED.

Установка зависимостей

На Ubuntu устанавливаем toolchain и утилиты:

Устанавливаем west — CLI для управления многорепозиторным workspace:

Инициализируем workspace и скачиваем модули (HAL-ы, криптобиблиотеки, Bluetooth controller):

Устанавливаем Python-зависимости и SDK с кросс-компиляторами:

Добавляем в ~/.bashrc:

Первое приложение: простой beacon

Начнём с минимального примера: устройство, которое только объявляет о себе по радио и не принимает соединений. Это база для iBeacon, Eddystone и отслеживание активов.

Создаём структуру проекта:

Файл CMakeLists.txt:

Конфигурация prj.conf:

Код src/main.c:

Что происходит: bt_enable(NULL) инициализирует стек синхронно. bt_le_adv_start с параметром BT_LE_ADV_NCONN запускает неконнективный advertising. Массив ad содержит флаги (general discoverable, no BR/EDR) и имя устройства.

Собираем и прошиваем:

Открываем nRF Connect на смартфоне, сканируем и видим «MyBeacon» в списке устройств. Прошивка работает.

Кастомный сервис: управляем LED со смартфона

Beacon полезен, но скучен. Настоящая магия начинается, когда телефон подключается к устройству и управляет им. Сделаем сервис, который позволяет включать LED на плате и читать состояние кнопки.

Конфигурация prj.conf:

Основной код. Здесь определяем пользовательские 128-битные UUID для сервиса и двух характеристик:

Ключевые моменты: BT_GATT_SERVICE_DEFINE собирает GATT базу данных на этапе компиляции. Характеристика LED доступна для чтения и записи, а кнопка — только для чтения. UUID сервиса вынесен в scan response, чтобы не перегружать 31-байтовый advertising-пакет.

После прошивки подключаемся через nRF Connect, находим кастомный сервис (UUID начинается с 00001234), записываем 0x01 в LED-характеристику — светодиод загорается. Только что вы управляли железом со смартфона по Bluetooth.

Notifications: отправляем данные без запроса

Чтение и запись — это pull-модель. Но датчики обычно работают по push: термометр сам шлёт температуру, пульсомер — BPM. В BLE для этого есть notifications.

Чтобы добавить notification в характеристику, нужно:

1. Указать свойство BT_GATT_CHRC_NOTIFY в характеристике.
2. Добавить CCCD (Client Characteristic Configuration Descriptor) через BT_GATT_CCC — телефон пишет в него 0x0001, чтобы включить уведомления.
3. Вызвать bt_gatt_notify при изменении данных.

Типовой паттерн — периодическая отправка через delayable work item:

Work item выполняется в системном потоке, а не в контексте прерывания, поэтому вызовы Bluetooth API безопасны.

Полный sensor node в одном файле

Соберём всё вместе: датчик температуры (симулированный), который читается по запросу и пушится через notifications с настраиваемым интервалом. Добавим обработку соединений и LED-индикацию статуса.

Здесь важны две детали. Во-первых, температура хранится в формате fixed-point (сотые доли градуса в int16_t) — это позволяет избежать дорогих операций с плавающей точкой на микроконтроллерах без FPU. Во-вторых, проверка в функции записи: если телефон шлёт некорректный интервал, стек возвращает ошибку BT_ATT_ERR_VALUE_NOT_ALLOWED.

При разрыве соединения обработчики отменяют work item, гасят LED и перезапускают advertising — устройство снова доступно для обнаружения.

Безопасность: pairing и шифрование

В рабочей среде BLE без защиты — это устройство, которое любой прохожий может переключить или прочитать. Pairing создаёт зашифрованный канал и, опционально, аутентифицирует стороны.

Методы pairing в BLE:

• Just Works — шифрование без аутентификации. Защищает от пассивного прослушивания, но не от MITM.
• Passkey Entry — пользователь вводит 6-значный код. Аутентификация есть.
• Numeric Comparison — оба устройства показывают число, пользователь подтверждает совпадение.
• Out of Band (OOB) — обмен ключами через внешний канал, например NFC.

Включаем SMP (Security Manager Protocol) и persistent storage для bonding:

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

Чтобы требовать шифрования для чтения характеристики, меняем permission:

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

Роль central: сканируем и подключаемся

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

Конфигурация central:

Запуск сканирования и подключение к первому найденному устройству с RSSI выше -70 dBm:

После подключения выполняется обнаружение сервисов через bt_gatt_discover, затем — чтение характеристик и подписка на notifications через bt_gatt_subscribe.

Оптимизация: MTU, PHY и энергопотребление

По умолчанию BLE ATT MTU — 23 байта. Минус 3 байта заголовка ATT, получаем 20 байт полезной нагрузки на операцию. Для передачи прошивки или больших буферов этого мало.

Включаем MTU 247 байт и Data Length Extension:

Zephyr автоматически инициирует MTU exchange при соединении. С 247-байтным MTU, интервалом 7,5 мс и 2M PHY пропускная способность достигает ~800–1000 кбит/с на практике.

Выбор PHY — ещё один рычаг:

• 1M PHY — дефолт, стандартная дальность и скорость.
• 2M PHY (Bluetooth 5.0) — удваивает скорость, сокращает время работы радио и экономит энергию. Дальность чуть меньше.
• Coded PHY — увеличивает дальность в 2–4 раза за счёт помехоустойчивого кодирования, но скорость падает до 125 кбит/с.

Энергосбережение — ключ к автономным устройствам. Главные приёмы:

1. Увеличить advertising interval: 1000 мс потребляет в 5 раз меньше, чем 200 мс.
2. Использовать peripheral latency: пропускать connection events, когда нечего передавать.
3. Включить System OFF: ток nRF52840 падает с ~3 мА до ~1,5 мкА.
4. Отключить неиспользуемые периферии в devicetree overlay — UART, SPI, I2C жрут ток даже в простое.

Цель для BLE-датчика — средний ток в единицы микроампер. При таком потреблении таблеточная батарейка CR2032 (225 мА·ч) проработает годы.

Что ещё умеет стек: Mesh, DFU и LE Audio

Помимо классической point-to-point связи, Zephyr поддерживает три продвинутые технологии:

Bluetooth Mesh

Bluetooth Mesh — многие-ко-многим сеть поверх BLE. Узлы пересылают сообщения друг другу, расширяя радиус действия за пределы одного соединения. Используется в умных домах и офисах: десятки лампочек, выключателей и датчиков общаются без единого центрального хаба.

DFU over BLE

DFU over BLE — обновление прошивки по воздуху. Интеграция с MCUboot даёт два слота: активный и резервный. Новая прошивка загружается через BLE SMP сервис, устройство перезагружается, MCUboot проверяет подпись и, в случае неудачи, автоматически откатывается к предыдущей версии.

LE Audio

LE Audio — новый аудиостандарт на базе BLE. Кодек LC3 даёт более высокое качество, чем классический SBC, при вдвое меньшем битрейте. Режим BIS (broadcast) позволяет одному источнику транслировать звук на неограниченное число приёмников — технология, лежащая в основе Auracast.

Отладка: что делать, когда не работает

BLE сложно отлаживать, потому что радио невидимо. Начинайте с логов:

Это выдаст подробную трассировку каждой HCI-команды, advertising event и GATT-операции. Вывод идёт в UART — не оставляйте UART включённым в рабочей среде, он жрёт ток.

Интерактивный Zephyr shell позволяет вручную запускать bt advertise on, bt gatt discover и bt gatt read через последовательный порт. Это бесценно для быстрой проверки гипотез без перепрошивки.

Для анализа радиоэфира используйте nRF Sniffer для Bluetooth LE — прошивка для nRF52840 DK, которая вместе с Wireshark показывает каждый пакет в эфире: advertising PDU, connection events, pairing exchange. Это окончательный инструмент, когда подозреваете проблему на уровне протокола.

Часто задаваемые вопросы

Выводы

Zephyr OS превращает разработку BLE-устройств из работы с чёрными ящиками в инженерную дисциплину. Полный открытый стек, сертификация Bluetooth SIG, поддержка 600+ плат и активное сообщество делают его одной из сильнейших платформ для IoT.

Мы прошли путь от простого beacon до полноценного sensor node с notifications, управлением соединениями и проверкой входных данных. Этих паттернов — advertising, GATT-обработчики, CCCD, подсчёт ссылок на соединение — достаточно, чтобы построить практически любое BLE-периферийное устройство.

Следующий шаг — взять реальное железо, реальный датчик и собрать устройство, которое решает вашу задачу. Термометр для теплицы, беспроводная кнопка для умного дома, трекер для велосипеда — всё это становится доступным после освоения базовых паттернов.

Главный способ понять BLE — не читать спецификацию, а заставить мигать LED со смартфона. Когда это получится, остальное пойдёт быстро.

Источники:

How to Build Bluetooth Applications with Zephyr OS: A Handbook for Devs — freeCodeCamp.

Zephyr Bluetooth Stack Documentation — официальная документация.

Bluetooth SIG Specifications — спецификации протоколов и профилей.

Исследователь Доминик Цёлек (ciolek.dev) обнаружил два бага в цепочке компиляции Go и сообщил о них команде безопасности. Та ответила на первый отчёт через 3 минуты, на второй — через 4. Что показательно: git blame указал на самого исследователя как автора кода, в котором обнаружился баг, — он же сам написал его три года назад.

• CVE-2026-27143: переполнение int8-счётчика в цикле → prove pass удалял bounds check → инъекция инструкций
• CVE-2026-27144: no-op-конверсия *p = T(*q) вместо *p = *q → компилятор пропускал careful copy path при пересечении памяти → memory corruption
• Общая причина: «counterfeit certainty» — оптимизатор повышал «вероятно безопасно» до «доказано безопасно» слишком рано
• Memory safety — свойство всей цепочки инструментов (frontend, optimizer, lowering, runtime, codegen), а не только языка
• «Every optimization is a security claim» — каждая оптимизация компилятора является утверждением о безопасности

Баг 1 (CVE-2026-27143): переполнение счётчика цикла убирает bounds check

Первый баг связан с фазой prove pass — проходом компилятора, который статически доказывает инварианты и на основании этого удаляет избыточные проверки. Идея хорошая: зачем проверять границы массива, если компилятор «знает», что индекс всегда находится в допустимом диапазоне?

Рассмотрим цикл с переменной типа int8, шагом 10 и лимитом 120:

На первый взгляд код безопасен: i не превышает 120, массив размером 200 байт — никакого выхода за границы. Prove pass рассуждал именно так: раз условие цикла гарантирует i ∈ [0, 120], bounds check можно удалить.

Но int8 хранит значения от -128 до 127. После 120 следующий шаг — 130, что переполняет тип и оборачивается в -126. Условие i < 120 снова становится истинным, цикл продолжается, но уже с отрицательным индексом. Bounds check, который мог бы это поймать, компилятор уже выбросил — ведь он «доказал» безопасность. В результате происходит запись за пределы массива, что открывает возможность для control-flow hijack и инъекции инструкций.

Prove pass повысил «индекс вероятно в пределах диапазона» до «индекс доказано в пределах диапазона», не учтя возможность целочисленного переполнения малых типов.

Баг 2 (CVE-2026-27144): no-op-конверсия и пересечение памяти

Второй баг тоньше. Go использует «careful copy path» — специальный путь копирования данных при работе с пересекающимися областями памяти (overlapping memory). Без него можно записать в destination данные, которые уже были перезаписаны в процессе копирования из source.

Проблема возникала при казалось бы безобидной конструкции — no-op-конверсии типа при присваивании через указатель:

Конверсия T(*q) здесь не делает ничего содержательного — типы совпадают. Компилятор распознал её как no-op и оптимизировал… но при этом забыл переключиться на careful copy path. Если области памяти p и q пересекаются — данные копируются некорректно, что приводит к повреждению памяти.

Особенно опасным сценарием оказались slice values: заголовок слайса содержит указатель на данные, длину и ёмкость. При некорректном копировании заголовка указатель мог указывать на произвольную память, а длина — быть некорректной.

Общая причина: «counterfeit certainty»

Оба бага объединяет одна концептуальная проблема: компилятор принимал «вероятно безопасно» за «доказано безопасно» и на этом основании удалял защитные механизмы. Цёлек называет это counterfeit certainty — поддельная уверенность.

В первом случае prove pass «доказал» безопасность индекса, не учтя переполнение малых целых типов. Во втором случае оптимизатор «знал», что конверсия — no-op, и сделал из этого вывод, что careful copy path не нужен. В обоих случаях рассуждение было формально правильным, но неполным: не были рассмотрены все возможные состояния программы.

Every optimization is a security claim. — Каждая оптимизация компилятора является утверждением о безопасности.

Когда компилятор удаляет bounds check — он утверждает, что выход за границы невозможен. Когда он пропускает careful copy path — он утверждает, что пересечения памяти нет. Ошибка в этих утверждениях напрямую превращается в уязвимость безопасности.

Memory safety — свойство всей цепочки инструментов

Принято считать, что memory-safe языки (Go, Rust, Java, C#) гарантируют отсутствие memory corruption по определению. Это правда — в рамках спецификации языка. Но между спецификацией и работающей программой стоит компилятор.

Цепочка компиляции Go включает несколько фаз, каждая из которых делает предположения о корректности предыдущей:

• Frontend (парсинг, type checking) — проверяет синтаксис и типы
• Optimizer (prove pass, escape analysis) — доказывает инварианты и устраняет лишние проверки
• Lowering — преобразует высокоуровневые операции в машинно-зависимые
• Runtime (garbage collector, goroutine scheduler) — управляет памятью во время выполнения
• Codegen — генерирует итоговый машинный код

CVE-2026-27143 затронул фазу optimizer, CVE-2026-27144 — фазу lowering. Обе уязвимости существовали несмотря на то, что исходный код был написан на «memory-safe» языке. Memory safety — это свойство, которое нужно обеспечивать на каждом уровне стека, не только на уровне языка.

Go security team: ответ за 3–4 минуты

Исследователь отправил отчёты об обоих багах в Go security team. Первый ответ пришёл через 3 минуты, второй — через 4. Оба бага были исправлены в Go 1.26.1. Сам Цёлек отметил, что процесс взаимодействия с командой был образцовым: быстрая реакция, прозрачная коммуникация и оперативный выпуск патча.

При разборе бага исследователь запустил git blame на подозрительный участок кода компилятора — и обнаружил собственное имя. Три года назад он сам написал этот код. По его словам, это добавило исследованию особой иронии и заставило более внимательно относиться к тому, что «очевидные» оптимизации несут в себе скрытые предположения о безопасности.

Выводы

История с CVE-2026-27143 и CVE-2026-27144 показывает: использование memory-safe языка — необходимое, но недостаточное условие для безопасности программы. Компилятор — не чёрный ящик с гарантиями, а сложная система с собственными инвариантами, которые могут нарушаться.

Оба бага существовали в «тихих» местах: оптимизаторе, который молча удалял проверки, и в lowering-фазе, которая молча пропускала защитный путь копирования. Ни один линтер, ни один статический анализатор не мог их обнаружить — ведь исходный код был совершенно корректным с точки зрения языка.

Практический вывод прост: обновляйтесь. Следите за golang-announce, обновляйтесь до новых версий Go сразу после выхода патчей безопасности, и помните, что «написано на Go» ≠ «memory-safe по определению».

Одним из поводов для разочарования в области аппаратных форматов изображений всегда было медленное развитие. Разработчики обычно не решались поставлять текстуры в новом формате, пока он не становился повсеместно доступным — поддерживался большинством целевого железа и всеми вендорами без исключения. Сегодня три вендора предлагают собственные форматы аппаратного сжатия текстур на лету: ARM AFRC, ImgTec PVRIC4 и Apple Metal Lossy. Игнасио Кастаньо исследовал все три и сравнил их с программным сжатием реального времени Spark от NVIDIA.

— ARM AFRC (Pixel 8, Mali-G715) — явный победитель: по метрике RMSE значительно обходит Spark и других конкурентов во всех форматах.

— Apple Metal Lossy (A15/M2+) — коэффициент сжатия 1:2, API минималистичен: один флаг в дескрипторе текстуры.

— ImgTec PVRIC4 (Pixel 10) разочаровал: драйвер игнорирует запрошенный bitrate, качество хуже Spark для R и RG форматов.

— Vulkan-расширение VK_EXT_image_compression_control унифицирует доступ к аппаратному сжатию через параметр BPC (bits per component).

— Аппаратное сжатие — перспективная альтернатива программному, но пока ограничено современными топовыми устройствами.

Контекст: почему это важно

Разработчики обычно не решались поставлять текстуры в новом формате, пока он не становился широко доступным — то есть поддерживался большинством целевого железа и всеми вендорами. Например, хотя ATI представила форматы 3Dc в 2004 году вместе с Radeon X800 (R420) и открыла их через расширения D3D9, их использование не стало распространённым, когда Direct3D 10 стандартизировал их как BC4 и BC5 в 2007 году. Массовое применение началось лишь тогда, когда Direct3D 10 стал минимальным требованием к железу.

Crysis стала первой крупной игрой, поставляемой с BC5-текстурами, но большинство игр ещё долгие годы не решались устанавливать такое жёсткое требование к железу. Чтобы избежать задержек с принятием, форматы BC6 и BC7 разрабатывались совместно ATI и NVIDIA для Direct3D 11.

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

Apple Metal: Lossy-сжатие

Apple представила сжатие текстур с потерями в чипах A15 и M2 (оба используют одно поколение GPU). Оно обеспечивает коэффициент сжатия 1:2. Включить его на удивление просто — API минималистичен. Свойство compressionType дескриптора MTLTextureDescriptor принимает значение из перечисления MTLTextureCompressionType, и установка MTLTextureCompressionTypeLossy зачастую является единственным необходимым изменением:

Согласно таблицам возможностей Metal Feature Set Tables, все обычные пиксельные форматы поддерживают сжатие с потерями — включая 10-битные и форматы с плавающей точкой. Тестирование это подтвердило, однако основное внимание сосредоточено на форматах R8, RG8 и RGBA8.

Внутренний алгоритм Apple не задокументирован. По результатам реверс-инжиниринга lossy-форматов используется размер блока 8×4 пикселя — и они напоминают некоторые особенности форматов ETC и EAC. Несмотря на заявленное сжатие 1:2, на практике для каждого блока выделяется один байт метаданных, так что реальное потребление памяти чуть выше заявленного.

Качество на M4 Pro

Для форматов R и RG Metal Lossy показывает результаты лучше кодеков Spark EAC, но хуже BC4 и BC5. Результаты RMSE (Root Mean Square Error — среднеквадратичная ошибка; меньше = лучше):

Формат R:

Формат RG:

Прямое сравнение lossy RGBA8 с форматами Spark некорректно из-за разных коэффициентов сжатия: Metal Lossy поддерживает только 1:2, тогда как форматы Spark RGB(A) — 1:4. Тем не менее, для полноты картины:

Формат RGBA:

Производительность на M4 Pro

С точки зрения производительности lossy-форматы показывают себя отлично и при достаточно большом размере текстуры упираются в пропускную способность памяти. Результаты на M4 Pro (16 ядер GPU) в МПикс/сек:

Обратите внимание, что пропускная способность стандартных блитов остаётся достаточно стабильной вне зависимости от размера текстуры. Кодеки Spark, напротив, имеют фиксированные накладные расходы, которые становятся заметнее при уменьшении размеров текстур. Интересен скачок скорости блитов при 512×512 — у него пока нет объяснения. Также стоит учесть, что кодеки Spark требуют дополнительного копирования из буфера вывода кодека в финальную сжатую текстуру — это дополнительные накладные расходы, которых можно было бы избежать, если бы Metal поддерживал запись в блочно-сжатые текстуры, как это делает Vulkan.

Vulkan: расширение VK_EXT_image_compression_control

В Vulkan расширение VK_EXT_image_compression_control даёт приложениям возможность запрашивать сжатие изображений с фиксированной скоростью. Расширение уже доступно на флагманских устройствах от ARM и Imagination. Включение потерявого сжатия в Vulkan несколько многословнее, чем в Metal, но на практике ненамного сложнее: нужно лишь расширить структуру VkImageCreateInfo, добавив в цепочку VkImageCompressionControlEXT.

Можно использовать флаг VK_IMAGE_COMPRESSION_FIXED_RATE_DEFAULT_EXT, чтобы позволить реализации самой выбрать параметры сжатия:

Альтернативно можно явно указать флаги фиксированной скорости для управления допустимыми коэффициентами сжатия:

BPC (bits per component — бит на компонент) — несколько нестандартная единица, но она позволяет задавать коэффициент сжатия единообразно вне зависимости от количества каналов. Для справки, BPC существующих форматов блочного сжатия GPU:

Расширение VK_EXT_image_compression_control также присутствует в некоторых драйверах AMD и Qualcomm, однако, насколько известно, ни один из этих вендоров не поддерживает аппаратное сжатие изображений с фиксированной скоростью. В случае AMD расширение присутствует в драйвере RADV, чтобы Proton мог отключать потерявое сжатие фреймбуфера в некоторых играх, где оно вызывало проблемы с корректностью — через флаг VK_IMAGE_COMPRESSION_DISABLED_EXT.

ARM AFRC: лучший результат среди всех

ARM Fixed Rate Compression (AFRC) было анонсировано в 2021 году и впервые появилось в Mali-G510 в 2022-м, однако широкого распространения этот дизайн не получил. По-настоящему массовым AFRC стало с выпуском Mali-G715 и Mali-G615 в том же году. Тестирование проводилось на Pixel 8 с GPU Mali-G715.

Устройство сообщило поддержку следующих форматов сжатия с фиксированной скоростью (возможности значительно шире Metal Lossy):

В отличие от Metal Lossy, AFRC не использует дополнительных байт метаданных — все управляющие биты находятся внутри самого блока. Изображение делится на блоки 8×8 пикселей, в ряде случаев разбиваемые на подблоки меньшего размера. Размер каждого блока 8×8 в байтах:

По результатам реверс-инжиниринга удалось установить: AFRC представляет цвета с использованием преобразования YCoCg, а представление пикселей напоминает вейвлет Хаара. Для каждого подблока 4×4 используется 16 коэффициентов, квантование которых зависит от режима. Форматы RGB и RGBA принципиально одинаковы — флаг в заголовке просто указывает, присутствует ли альфа-канал или блок полностью непрозрачен.

Качество AFRC

Качество AFRC впечатляет. В отличие от Metal, здесь можно сделать прямое сравнение с ASTC в реальном времени, поскольку Mali поддерживает сжатие 1:4:

Формат R:

Формат RG:

Формат RGBA:

Во всех случаях RMSE значительно ниже, то есть AFRC превосходит Spark ASTC при нацеливании на ASTC с кодировщиком реального времени. Тем не менее есть несколько случаев, когда Spark даёт более высокое качество: на очень гладких изображениях сжатие AFRC приводит к заметным паттернам дизеринга, раскрывающим границы блоков. Это особенно заметно при использовании AFRC в качестве текстуры с увеличением, тогда как для сжатия фреймбуфера — основного сценария применения — такие паттерны практически незаметны.

Производительность AFRC (Pixel 8)

Включение AFRC не вызывает значительных накладных расходов по сравнению с несжатыми загрузками текстур, за исключением некоторых размеров. Результаты на Pixel 8 в МПикс/сек:

Пропускная способность здесь масштабируется с размером текстуры, а не остаётся стабильной. Накладные расходы одинаково влияют на блиты и compute-шейдеры Spark. В отличие от секции Metal, где lossy-блиты явно доминировали над Spark на малых размерах, здесь картина смешанная: Spark вплотную приближается к AFRC или превосходит его. Это показывает, что кодирование текстур в реальном времени вполне конкурентоспособно с аппаратным сжатием. Абсолютные числа здесь значительно ниже, чем на M4 Pro, — это принципиально разные классы устройств.

ImgTec PVRIC4: разочарование от Pixel 10

ImgTec впервые анонсировала поддержку PVRIC4 ещё в 2018 году для GPU серии Series 6, однако протестировать её удалось только с выходом Pixel 10 на чипе Series D. Первоначальное объявление намекало на то, что, как и Metal Lossy, PVRIC4 поддерживает только 50%-е сжатие, но расширение декларирует более широкий спектр опций:

К большому удивлению, качество вывода оказалось одинаковым вне зависимости от BPC. Дальнейшее расследование показало: драйвер игнорирует запрошенный BPC и всегда использует 4 bpc (сжатие 1:2). Формат блоков PVRIC4 — наиболее сложный из всех трёх вендоров: размер блоков составляет 16×16 пикселей, и, как в Metal Lossy, присутствует один байт метаданных на блок. Сделать реверс-инжиниринг практически не удалось.

Качество PVRIC4

Качество оказалось разочаровывающим. Для форматов R и RG Spark фактически превосходит PVRIC4 при нацеливании на стандартные форматы блочного сжатия, поддерживаемые этим железом:

Формат R:

Формат RG:

Для RGBA прямое сравнение невозможно из-за разных коэффициентов сжатия, но качество также значительно хуже других вендоров:

Формат RGBA:

Производительность PVRIC4 (Pixel 10)

Кривая пропускной способности на этом устройстве существенно отличается от Pixel 8: пик приходится на размеры 1024–2048, а не монотонно возрастает с размером. На больших размерах пропускная способность Spark фактически выше, чем у несжатых загрузок текстур. Это характерно для устройств, ограниченных пропускной способностью памяти: обычный блит должен прочитать всё входное изображение и записать обратно тот же объём данных, тогда как Spark записывает лишь 1/4 входных данных. Экономия на записи зачастую перекрывает вычислительные затраты кодирования.

Комментарий PowerVR Dev (ImgTec)
PVRIC4 поддерживает только сжатие 1:2. TFBC (доступен исключительно в чипах Rogue XE) поддерживал соотношения 1:2, 1:4 и 1:3. Дизайн расширения был спорным — многим не нравилась многословность выбора BPC, поэтому было решено экспонировать все BPC в рамках поддерживаемых соотношений и повышать их до поддерживаемого ratio. Это считалось допустимым, поскольку качество не деградирует относительно запроса приложения, а приложение всё равно обязано запрашивать реальный размер изображения, который не гарантирует уменьшения.

Spark: программная точка отсчёта

Spark — библиотека NVIDIA для программного сжатия текстур в реальном времени. Работает на GPU как compute shader, поддерживает форматы BC1–BC7 и ASTC. В тесте выступает базовой точкой сравнения как лучшее доступное программное сжатие без специализированного железа.

Spark показывает стабильные результаты по форматам, но требует явного вызова compute-прохода — это дополнительный этап в пайплайне. Аппаратное сжатие, напротив, встроено в рендеринг и не требует дополнительного кода. Отдельный плюс Spark — предсказуемое и согласованное поведение на всех устройствах, что важно, если унифицированный вывод критичен для вашего сценария. Ни один из форматов аппаратного сжатия пока не доступен через WebGPU — если это изменится, расширить spark.js для их поддержки будет несложно.

Итоги: кто победил

ARM AFRC — явный победитель. Это не только превосходит программные реализации вроде Spark, но и обходит все остальные форматы по всем метрикам. Итоговая таблица RMSE по всем протестированным форматам:

Стоит оговориться: результаты PVRIC4 могут не отражать полного потенциала железа — драйвер игнорирует запрошенный коэффициент сжатия и всегда использует 1:2. Возможно, эти результаты удастся пересмотреть после исправления проблемы.

Аппаратное сжатие — убедительная альтернатива программному. Главная оговорка — оно сейчас ограничено современными топовыми устройствами, которые как раз и располагают наибольшим объёмом памяти и пропускной способностью.

Даже когда нативное аппаратное сжатие доступно, есть веские причины продолжать использовать Spark. Вывод аппаратного сжатия различается у разных вендоров, и в некоторых случаях — как мы видели с PVRIC4 — качество уступает кодировщику реального времени. Если для вашего сценария критичен единообразный и предсказуемый вывод на всех вендорах, Spark остаётся правильным выбором.

• Решить, с какого языка/технологии вы хотите начать.
• Решить, на каком ресурсе вы хотите обучаться.
• Выделить время на само программирование.

Звучит просто, однако у вас уйдёт много времени на исследования, чтобы решить, что вам подходит и на каком ресурсе обучаться.

Некоторые люди начинают с относительно низкоуровневого программирования на C и C++. Другие выбирают более традиционный путь, изучая Java или C#. Есть и те, кто начинает с высокоуровневых или скриптовых языков вроде Python, Ruby или JavaScript.

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

Низкоуровневые языки: близко к «железу»

Это языки, где вы напрямую работаете с памятью компьютера. Нет автоматической уборки ненужных данных, всё под вашим контролем. Подходят для системного ПО, игр или устройств (например, микроконтроллеров).

Примеры: C (для ОС вроде Linux), C++ (для игр на движке вроде Unreal Engine), Assembler (для оптимизации критических частей кода).

Плюсы:

• Полный контроль: вы решаете, как использовать ресурсы. Так, в C++ можно вручную выделять память для массивов, избегая ненужных копий данных.
• Высокая скорость: прямой доступ к памяти позволяет писать код, который работает быстрее (это важно для работы с играми или серверами).
• Основы основ: такие языки учат, как компьютер работает изнутри, чтобы в будущем ценить удобства других языков. Например, вы узнаёте, почему «утечка памяти» — это проблема.
• Эффективность: низкоуровневые языки мотивируют думать об оптимизации заранее, снижая расход батареи или CPU.
• Компактность: минимальная библиотека, приложения получаются лёгкими (идеально для embedded-систем, как в IoT-устройствах).

Минусы:

• Всё-таки это сложно: рутинные задачи (например, чтение файла) требуют больше кода и внимания к деталям, рискуя ошибками вроде переполненного буфера.
• Ручное управление памятью: можно легко «забыть» освободить память, вызвав утечки или краши. Например, в C нужно использовать malloc/free, иначе программа съест всю RAM.
• Много копипасты: придётся писать шаблонный код, и делать это часто.
• Платформо-зависимость: код для Windows может не работать на Linux без правок.

Среднеуровневые языки: баланс контроля и удобства

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

Примеры: Java (для Android-приложений), C# (для Unity-игр или .NET-серверов).

Плюсы:

• Автоматическая память: память очищается автоматически благодаря сборщику мусора, что избавляет от ручной работы и снижает вероятность ошибок, вроде утечек памяти в больших проектах. При этом можно получить доступ к низкоуровневым функциям для особых задач, например, через специальные инструменты в Java.
• Богатые библиотеки: готовые инструменты для сетей, GUI или баз данных. Пример: Java’s Spring для веб-серверов.
• Кроссплатформенность: компиляция в байт-код (JVM для Java) позволяет запускать код везде. Например, пишешь на Windows, запускаешь на Linux.
• Безопасность: язык проверяет типы данных перед запуском программы, помогая заранее найти ошибки. Среда выполнения защищает от опасных сбоев, например, от переполненной памяти.
• Масштабируемость: встроенные инструменты для параллельных вычислений позволяют легко создавать программы, которые одновременно выполняют много задач (серверы для тысяч пользователей и т.п.).

Минусы:

• Дополнительная нагрузка от рантайма: Среда выполнения и автоматическая очистка памяти создают дополнительную нагрузку. Сборщик мусора может ненадолго останавливать программу, что заметно в играх или при обработке видео.
• Меньше контроля: абстракции скрывают детали памяти, усложняя оптимизацию (например, в Java сложно избежать боксинга примитивов).
• Повторяющийся код, которого много: приходится писать повторяющийся код и тренировать свою усидчивость, например, для доступа к данным объекта. Кстати, инструменты вроде Lombok могут упростить эту задачу.
• Зависимость от среды: для запуска программ нужна специальная среда (например, JVM для Java), что влияет на размер программ и замедляет их старт.
• Сложность интеграции: подключение кода на других языках, например, на C, требует писать специальные обёртки, что усложняет работу и снижает скорость.

Высокоуровневые языки: удобство и скорость разработки

Эти языки скрывают технические детали, позволяя сосредоточиться на создании логики программы. Подходят для веба, data science или скриптов.

Примеры: Python (для ML), Ruby (для веб-разработки), JavaScript (для фронтенда).

Плюсы:

• Простота: сложные задачи решаются в пару строк. Так, в JS async/await упрощает API-запросы.
• Быстрая разработка: динамическая типизация позволяет быстро писать и тестировать код без необходимости его компиляции.
• Богатые экосистемы: есть библиотеки для всего (к примеру, NumPy для данных в Python).
• Гибкость: легко менять код, идеально для прототипов или стартапов.

Минусы:

• Низкая производительность: абстракции добавляют нагрузки. Например, циклы в Python медленнее, чем в C.
• Ошибки на рантайме: из-за слабой типизации ошибки выявляются только при запуске программы, что усложняет отладку.
• Риск «спагетти-кода»: лёгкость изменений может привести к хаосу без дисциплины.
• Скрытые проблемы: абстракции маскируют баги.
• Зависимость от интерпретатора: программы требуют установленного интерпретатора, что замедляет их запуск и добавляет зависимость от дополнительного ПО.

Чек-лист: как выбрать язык программирования для новичка

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

1. Определите, что вас вдохновляет, и выберите сферу. Подумайте, что вы хотите создавать: сайты, игры, мобильные приложения или серверы. Разные сферы требуют разных языков. Например, для веб-разработки подойдут JavaScript или Python, для мобильных приложений — Java, Kotlin, Swift или Dart, а для игр — C# или C++. Составьте список идей (например, сайт-визитка, игра, аналитика данных) и найдите, какие языки для них используют.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
2. Ищите язык с широким применением. Выбирайте языки, которые используются в разных областях, чтобы легче переключаться между задачами. Например, Kotlin подходит для мобильной разработки, веба и серверов, а C# — для десктоп-приложений, игр (Unity) и бэкенда. Это даёт гибкость и упрощает изучение новых языков в будущем.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
3. Проверьте спрос на рынке труда. Если цель — смена профессии, изучите вакансии на HH.ru или LinkedIn. Введите «junior Python», «junior Java» и сравните, где больше предложений и какие требования. Избегайте языков с низким спросом, если хотите быстро найти работу. Например, Java, Kotlin, Python и JavaScript популярны для найма.
   — Владислав Масунов, Head of Development
4. Опробуйте языки на практике. Напишите простые программы (например, "Hello World" или калькулятор) на нескольких языках, чтобы понять, какой синтаксис вам ближе. Используйте онлайн-редакторы вроде Replit или CodePen. Например, попробуйте TypeScript для веба (он поддерживает типизацию и разные подходы к программированию) или C++ для понимания работы с памятью. Это поможет почувствовать, к чему лежит душа.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS; Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
5. Выберите язык с хорошей документацией и сообществом. Убедитесь, что у языка много обучающих материалов и активное сообщество. Например, TypeScript имеет богатую документацию и поддержку, что упрощает старт. Проверьте ресурсы вроде LearnPython.org, freeCodeCamp для JavaScript или Telegram-чаты для C++. Это поможет быстрее решать вопросы.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
6. Учитывайте сложность и карьерные цели. Для небольших проектов или быстрого старта берите Python или PHP — они проще и подходят для веб-разработки или скриптов. Для сложных задач с высокой нагрузкой (например, серверы или оптимизация) попробуйте C++ или Go. Если цель — работа в крупных компаниях, Java и Kotlin востребованы и часто используются с ИИ-инструментами. Выбирайте, исходя из сложности и ваших амбиций.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
7. Смотрите на универсальность и переход к другим языкам. Выбирайте язык, который учит основам программирования и упрощает переход к другим. Например, изучение C# может помочь освоить Java, а затем — Android-разработку. TypeScript учит объектно-ориентированному и функциональному программированию, что полезно для разных задач. Это создаёт базу для дальнейшего роста.
   — Аня Жаркова, руководитель мобильной разработки в USETECH; Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
8. Не гонитесь за гилти плежа. Избегайте языков, которые изучают «для удовольствия» без практического применения. Выбирайте те, которые можно применить в реальных проектах или которые востребованы в индустрии. Например, вместо нишевых языков берите Python, Java или Kotlin: они имеют чёткие сценарии использования.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
9. Практикуйтесь с ИИ-инструментами. Если хотите работать в крупных компаниях, освойте язык, который хорошо сочетается с ИИ-инструментами (например, Go или Java). Практикуйтесь с ИИ-агентами по типу GitHub Copilot для автоматизации задач — это ценится работодателями.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
10. Составьте план развития. Создайте roadmap: определите, какие проекты хотите делать через 3-6 месяцев (например, мобильное приложение или веб-сервис), и подберите язык под эти цели. Если выбрали C#, начните с десктоп-приложений, затем попробуйте Xamarin для кроссплатформенной разработки. Постепенно добавляйте новые языки, опираясь на первый.
    — Аня Жаркова, руководитель мобильной разработки в USETECH

Если не определились, предлагаем пройти квиз и расставить всё по полочкам:

Зачем разработчику Swift изучать ассемблер

Ассемблер — это не просто низкоуровневое программирование, а способ понять, как код на Swift или Objective-C преобразуется в инструкции процессора. Он помогает разобраться в движении данных, оптимизировать производительность и отлаживать сложные ошибки. Изучение ассемблера не требует писать целые приложения на нем, но дает уверенность и глубокое понимание работы системы. К тому же, умение работать на уровне процессора добавляет разработчику уникальности и открывает новые карьерные перспективы.

Регистры: основа работы процессора

Регистры — это быстрые ячейки памяти процессора, своего рода «рабочий стол» для данных. На архитектуре Apple Silicon (ARM64) они выполняют следующие роли:

• x0–x7: передача аргументов и возвращаемых значений.
• x8: регистр косвенных результатов (используется редко).
• x9–x15: временные регистры для промежуточных вычислений.
• x16–x17: для системных вызовов (например, указание номера вызова).
• x18: регистр платформы, сохраняемый между вызовами.
• x19–x28: регистры, которые нужно сохранять при вызове функций.
• sp (x31): указатель стека, хранящий локальные данные.
• pc: счетчик программы, указывающий на следующую инструкцию.

При выполнении системного вызова (например, для вывода текста в консоль) аргументы загружаются в регистры x0, x1 и далее, номер вызова — в x16, а команда svc 0 передает управление ядру системы.

Настройка Xcode для работы с ассемблером

Чтобы начать писать код на ассемблере, нужно настроить проект в Xcode:

1. Откройте Xcode и создайте новый проект: File → New → Project….
2. Выберите Command Line Tool в разделе macOS, затем нажмите Next.
3. Назовите проект, например, HelloAsm, выберите язык C (его позже заменим) и нажмите Create.
4. В Project Navigator удалите файл main.c.
5. Добавьте новый пустой файл: File → New → File… → Other → Empty, назовите его main.s и нажмите Create.
6. В настройках проекта откройте Build Phases и убедитесь, что main.s добавлен в Compile Sources.

Теперь Xcode будет компилировать файл main.s как точку входа для программы на ассемблере.

Первая программа: «Hello, Assembly!»

Рассмотрим минимальную программу, которая выводит «Hello, Assembly!» в терминал. Вот ее структура с пояснениями:

• .section __TEXT,__text & .global _main: указывает, что это исполняемый код, а _main — точка входа.
• mov x0, 1: задает 1 (stdout) как первый аргумент системного вызова.
• adrp/add: загружает адрес строки msg в регистр x1 (с учетом разбиения на страницы).
• mov x2, #0x11: задает длину сообщения (включая символ новой строки и нулевой терминатор).
• mov x16, #0x4: указывает номер системного вызова для записи в macOS.
• svc 0: выполняет системный вызов, передавая управление ядру.
• Повторение для вызова выхода.

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

Сборка и запуск

Соберите и запустите проект в Xcode. При успешной компиляции в терминале появится:

Hello, Assembly!

Если вывод не появился, проверьте:

• Файл main.s добавлен в Compile Sources.
• Нет лишних C-файлов, которые могут переопределить main.
• Архитектура проекта соответствует вашему оборудованию (Intel или Apple Silicon).

Что дальше

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

В какой-то момент появилось желание, используя накопленный опыт, создать собственный пет-проект. Так появился Shader-Learning.com, который я уже более двух лет разрабатываю и совершенствую в свободное время. Это платформа, созданная для того, чтобы помочь людям изучать и практиковать GPU-программирование на GLSL и HLSL прямо в браузере.

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

Все задания сгруппированы по модулям, чтобы можно было сосредоточиться на темах, которые наиболее интересны:

• роль фрагментного и вершинного шейдеров в графическом конвейере и изучение встроенных функций GLSL/HLSL;
• базовая математика и геометрия, лежащие в основе компьютерной графики – от векторов и матриц до пересечений примитивов и систем координат;
• алгоритмы обработки 2D-изображений с помощью фрагментных шейдеров;
• реализация освещения и теней;
• рендеринг травы и воды в реальном времени;
• использование функций шума для процедурной генерации визуальных эффектов;
• Продвинутые техники: билборды, Soft Particles, MRT, отложенный рендеринг, HDR, туман и другое;
• SDF.

Примеры заданий

Первое задание посвящено тому, что такое шейдерная программа и как её использовать для закрашивания пикселей на экране:

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

Иногда затрагиваю низкоуровневые моменты работы GPU:

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

Каждую задачу вы решаете локально в браузере, а когда считаете, что она выполнена правильно, отправляете её на проверку:

Есть функция «Diff», которая отображает разницу между ожидаемым результатом и результатом пользователя. Она помогает выявить разницу, которую сложно увидеть глазом:

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

Пользовательские задачи

У пользователей есть возможность создавать и делиться собственными задачами. Редактор задач позволяет построить графическую сцену с полным контролем над её компонентами:

Настройка сцены:

• настроить камеру и её анимацию;
• добавить объекты на сцену и указать их геометрию;
• загрузить текстуры и назначить их материалам.

Редактирование шейдеров:

• можно изменять вершинный и/или фрагментный шейдеры;
• добавить шейдер постобработки для экранных эффектов.

Содержание задачи:

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

Настройки проверки выполнения

• какие файлы может редактировать пользователь (фрагментный, вертексный или шейдер постобработки);
• какие кадры должны сравниваться, если задача анимированная;
• правила линтера (например, запретить использование if).

Публикация и распространение

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

Статистика задачи. Для каждой опубликованной задачи вы можете отслеживать:

• количество просмотров;
• количество успешных решений;
• лайки и дизлайки;
• текстовые отзывы от пользователей.

Управление задачами

В любой момент вы можете:

• редактировать задачу;
• скрыть её из общего доступа;
• повторно опубликовать, когда будете готовы.

Стек Технологий

Node.js, Express.js, MySQL, Amazon S3, Angular, NgXs, RxJS, Typescript, SCSS, WebGL, Three.js

Заключение

Несмотря на то, что на платформе есть платный контент, я надеюсь, что мой пост не будет воспринят негативно. Вы можете совершенно бесплатно и без рекламы решать задачи из модулей Built-in Functions и Advanced Rendering, а также решать пользовательские задания и создавать свои.

Буду рад любым вашим идеям и предложениям по развитию платформы!

Если интересно, присоединяйтесь к Discord, чтобы не пропустить новые уроки и обновления.

Спасибо за внимание!

«Я думаю, что могу смело утверждать: квантовую механику не понимает никто».

По этой причине многие идеи оставим без внимания — попытка их объяснения растянется на десяток страниц. Также не будет формул и страшных математических моделей.

Рассмотрим лишь то, что приблизит к ответу на вопрос: как квантовые вычисления повлияют на программирование в будущем.

Определения и квантовая путаница

Кубиты

Квантовые вычисления строятся на основе кубитов. Они существуют как физические объекты. Законы квантовой механики проявляются на фотонах, электронах, ионах, атомах.

Самое интересное — если обычный бит принимает значение 0 или 1, то кубит находится в суперпозиции. Его состояние описывают диапазоном от 0 до 1, и оно непрерывно меняется.

Суперпозицию можно рассмотреть на примере монетки. На столе она лежит орлом вверх (0), либо решкой (1). Теперь представьте, что монету подбросили, — она вращается в воздухе и находится как бы в обоих состояниях одновременно.

Квантовая запутанность

В квантовой механике что не явление, то необъяснимое событие. Одно из таких — запутанность. Два отдельных кубита оказываются «связаны», игнорируя расстояние.

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

Квантовый брутфорс

Битами классических компьютеров управляют логические операторы — И, ИЛИ, НЕ.

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

Представьте замок и 40 ключей. Только один из них подходит. Классический компьютер попробует каждый ключ по очереди. Квантовый образец одновременно «проверит» все варианты, затем с помощью гейтов сузит поиск до верного.

Суть в том, что квантовые методы вычисляют ответ всего за √N попыток вместо N, как в классическом переборе.

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

Представьте идеально сбалансированную иголку. Ваша задача, как ученого, — установить иглу на самый кончик и удерживать в равновесии как можно дольше.

Он — компьютер, но квантовый

Есть мнение, что квантовый компьютер (КК) вовсе не компьютер, потому что выдает не точный, а приблизительный ответ.

Но он все равно компьютер! У него есть процессор, память, он следует алгоритмам. КК принимает входные данные и выдает результат, который можно обработать.

Справедливое замечание: без классического компьютера квантовые вычисления — бесполезны.

КК отсекает решения, невозможные из-за противоречивости, и обозначает предел с ответом. Искать это точное решение и выбирать из нескольких выданных вариантов — задача обычного ПК.

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

Как квантовые вычисления повлияют на программирование

Криптография — одна из первых областей, где развитие индустрии квантовых вычислений обещает серьезные изменения. Современные методы шифрования уязвимы при применении квантовых алгоритмов.

С появлением достаточно мощного КК использование RSA и AES будет небезопасным. Поэтому IT-компании уже разрабатывают квантовую криптографию, чтобы защитить данные до появления угрозы.

В будущем интеграция квантовых технологий решит проблемы оптимизации. Компьютеры будут определять наилучшее решение среди огромного числа вариантов. Актуально для маршрутизации и планирования производства.

Машинное обучение тоже выигрывает от развития квантовых вычислений. Скорость обучения нейросетей увеличится в разы.

Классические алгоритмы vs квантовые алгоритмы

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

Например, алгоритм Шора. Он раскладывает числа на множители, но работает только на квантовом компьютере.

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

• Для числа размером 2 цифры — очень легко.
• Для числа размером 10 цифр — сложнее, но реально.
• Для числа размером в 300 цифр (как в RSA-криптографии) — может занять тысячи лет.

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

Другой пример — алгоритм Гровера. Он ускоряет поиск в неструктурированных базах данных.

В списке из 1000 элементов обычный компьютер проверит до 1000 записей. Алгоритм Гровера проверит всего √1000 ≈ 31 запись.

Нужны ли новые языки программирования?

Для квантовых измерений только традиционных языков программирования недостаточно.

Qiskit

Разработчик: IBM

Популярный Python-фреймворк для программирования квантовых алгоритмов. На нем можно написать программу и выполнить ее на симуляторе. Есть возможность запускать алгоритмы на реальных квантовых компьютерах IBM через облако.

Cirq

Разработчик: Google

Библиотека на Python для создания и тестирования технологий квантового вычисления. Cirq чаще используют для работы с алгоритмами Гровера, Шора и др. Программу можно протестировать на симуляторе.

Q#

Разработчик: Microsoft

Q# — это часть Microsoft Quantum Development Kit (QDK). Он содержит инструменты для симуляции, разработки программ и интеграции квантовых вычислений с кодом на C# или Python.

Какая математика потребуется разработчикам?

Разработчик должен уметь работать с матрицами и векторами, потому что с их помощью описывают состояния кубитов и операции над ними.

Векторы показывают, где кубит «находится» в пространстве, а матрицы управляют его изменениями.

Все квантовые операции — это просто умножение вектора состояния на матрицы. Но результат нельзя узнать до момента измерения, поэтому вероятность каждого расчета задается квадратичными модулями коэффициентов.

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

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

Когда начинать изучать квантовые вычисления?

Развитие квантовых технологий находится на этапе перехода от исследовательской стадии к практике в реальных приложениях. До массового внедрения далеко, десятки лет.

Уходить сегодня из фронтенда в разработку квантовых программ — это как создавать ИИ в 80-х годах.

Основное ограничение — количество активных кубитов и стабильность вычислений. Процессор IBM Condor с 1121 кубитом побил рекорд по мощности, но поддержание кубитов в суперпозиции и подавление квантового шума остаются нерешенными проблемами.

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

Какие компании уже инвестируют в квантовые вычисления?

IBM — лидер в разработке квантовых технологий. Их платформа IBM Quantum Experience предоставляет доступ к настоящим квантовым компьютерам через облако.

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

Google тоже добилась успеха, заявив о квантовой супрематии — решении задачи, недостижимой для классических компьютеров, с помощью своего процессора Sycamore. Google работает над оптимизацией алгоритмов и предоставляет инструменты для программирования на платформе Cirq.

Microsoft раньше других взялась за развитие языка программирования для квантовых вычислений — Q#. Вместе с этим доступен Quantum Development Kit, который моделирует квантовые программы и тестирует на симуляторах.

Amazon тоже не осталась в стороне. Компания предлагает облачный сервис AWS Braket, интегрирующий работу с квантовыми симуляторами.

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

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

Через 10 лет можно ожидать стабильных образцов с тысячами кубитов. Это станет отправной точкой для коммерческой квантовой индустрии.

Спустя 20 лет квантовые компьютеры, вероятно, станут частью бизнеса. Их будут применять разработчики, работающие с криптографией, ИИ, аналитикой. К этому времени квантовые вычисления станут массовым явлением.

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

Инструменты и платформы для начала работы

Если не терпится попробовать квантовую разработку, обратите внимание на следующие инструменты.

IBM Quantum Experience и Qiskit

IBM Quantum Experience — это облачная платформа. Она поддерживает запуск кода на реальном квантовом компьютере — 5-кубитном IBM Quito. Платформа содержит учебные курсы, в том числе серию статей по основам квантовой механики.

Чтобы программировать кубиты, зарегистрируйтесь на IBM Quantum Experience и познакомьтесь с библиотекой Python Qiskit.

Пример квантовой схемы:

В библиотеке Qiskit есть модули для изучения оптимизации, машинного обучения и квантовой химии. Если хотите протестировать программу на реальном образце КК, подключайтесь через API.

Google Cirq

Google Cirq — это библиотека Python для создания, выполнения и отладки квантовых вычислений на симуляторах или реальном оборудовании Google. Cirq подходит для тех, кто хочет более программно ориентированный подход к квантовой механике.

Особенности:

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

Пример квантовой схемы:

Чтобы использовать физический процессор, нужно подключиться к облаку Google Quantum.

Microsoft Q#

Q# — язык с высоким уровнем абстракции. Его используют, чтобы сосредоточиться на алгоритмах без погружения в низкоуровневую обработку кубитов.

Для работы с Q# понадобится Quantum Development Kit, .NET, расширение для Visual Studio или VS Code.

Простая программа на Q#:

Код выполняется через симулятор, встроенный в QDK.

Microsoft предлагает облако с доступом к реальным квантовым процессорам. После настройки учетной записи Azure можно отправлять программы на лабораторные компьютеры и гибридные симуляторы.

Симуляторы

Чтобы лучше понять работу квантовых вычислений, стоит начать с симуляторов:

• IBM Aer. Входит в состав Qiskit, имитирует шумовые и идеальные квантовые процессы.
• Google Cirq’s Simulator. Интегрирован в библиотеку Cirq, поддерживает широкий спектр квантовых операций.
• Microsoft Quantum Simulator. Разработан для работы с Q#, позволяет запускать программы и тестировать квантовые алгоритмы.
• QuTip. Библиотека Python для работы с квантовыми системами, поддерживает симуляцию квантовых состояний, унитарных операций и вычислений.

Если вы новичок — используйте Qiskit + IBM Aer.

Любите низкоуровневое программирование? Google Cirq — ваш выбор.

Чувствуете, что вам нужен язык высокого уровня с интеграцией в классические приложения? Тогда изучайте Q# + Microsoft Quantum Simulator.

Что в итоге?

Квантовые компьютеры не заменят классические — они дополнят их, решая специфические задачи. Симулировать кубиты непросто: для будущей интеграции квантовых технологий придется пополнить стек новой библиотекой и пройти курс по квантовой физике.

IBM, Microsoft и Google развивают экосистемы для новых специалистов. Есть симуляторы и обучающие материалы. Они немного облегчают вход в эту сферу.

Перед изучением темы нужно признать, что квантовые вычисления — это, без преувеличения, самое сложное направление программирования.

Особенность этой игры заключается в том, что она разработана без использования каких-либо библиотек, включая стандартную библиотеку C. Это делает её технически сложной и впечатляющей, особенно для современного программирования.

Полностью ручной подход к разработке

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

Вместо этого он взаимодействует с системой напрямую, выводя изображение через /dev/fb0 — устройство, отвечающее за отображение на экране. Весь проект написан с нуля, без применения готовых решений.

Игровая механика и вдохновение

Игра, которую создал разработчик, вдохновлена классической Boulder Dash и представляет собой классический игровой процесс с элементами «добывания» ресурсов.

Автор подчеркнул, что работа над игрой стала для него обучающим опытом, несмотря на то, что по профессии он работает с C++.

Реакция сообщества

Проект вызвал активное обсуждение на Reddit.

Многие пользователи выразили восхищение уровнем погружения в низкоуровневое программирование и поделились своим опытом работы с ассемблером в прошлом.

Один из пользователей вспомнил, как работал с подобными проектами на Commodore 64, что породило в комментариях цепочку ностальгических воспоминаний о первых шагах в программировании.

Доступ к проекту и видео

Проект доступен на GitHub, где можно скачать исходный код. Кроме того, автор выложил видео на YouTube, демонстрирующее, как игра работает на его ноутбуке:

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

Без их разработки мы бы не смогли писать приложения для наших телефонов. У нас бы не было тех машин, на которых мы сегодня ездим.

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

Премия Тьюринга выдаётся с 1966 года. Главным призом, помимо всеобщего признания единомышленников, является денежная награда — 1 млн долларов. Её Ульман с Ахо поделят между собой.

Источник: The New York Times

ОС Collapse может работать с 8-битными микропроцессорами Z80. Они до сих пор используются в кассовых аппаратах, калькуляторах. За всё время их выпустили гораздо больше, чем 16- и 32-битных микропроцессоров. Поэтому их проще будет найти в условиях постапокалипсиса. Дупрас считает, что к 2030 году массовое производство электротехники сойдёт на нет. Ценен будет тот, кому удастся найти и перепрограммировать какое-то старое устройство.

Сейчас ОС работает на собранном вручную компьютере RC2014. На ней можно редактировать текст, читать и записывать данные и даже компилировать файлы для ассемблера.

Примечание Для дизассемблирования в этой статье используется IDA Pro, но многие её функции (например блок-схемы, перевод в псевдокод и т. д.) можно найти в качестве надстроек в бесплатных дизассемблерах (radare2). Более того, для лучшего понимания имена некоторых дизассемблированных переменных были изменены с «v20» на имена, которые были у них в С. Также в этой статье исполняемый файл был скомпилирован в 64-битной версии, а для дизассемблирования используется 64-битная версия IDA Pro. Это на случай, если вы захотите повторить всё самостоятельно, потому что это может повлиять на конечный результат (например, на массивах будет сильное различие 32 и 64-битных версий, а также в 64-битной версии регистры становятся в два раза больше).

Массивы

Итак, начнём с массивов. Сначала рассмотрим код на Си:

Эти 12 строк кода превращаются в довольно внушительный блок машинного кода. Давайте рассмотрим его детально:

При инициализации массива с константным размером компилятор просто инициализирует длину массива через локальную переменную.

Во время компиляции будет выделено место только под одно значение массива litArray[0], которое и будет использоваться (можно увидеть на скриншоте ниже). Такой приём позволяет компилятору значительно увеличить производительности приложений.

Сначала длина массива сохраняется в локальную переменную ArraySize, затем вычисляется максимальное и минимальное индексное значение, а также длина всего массива, а затем под неё выделяется память.

При объявлении массива с предопределёнными значениями компилятор сохраняет каждое значение в свою переменную, которая представлена индексом массива (например objArray4 = objArray[4]).

Так же как и с предопределёнными значениями, компилятор создаёт новую переменную для указанного индексного значения при инициализации элемента массива через индекс.

При извлечении элемента массива значение элемента берётся по указанному индексу и записывается в нужную переменную.

При создании матрицы сначала её размер устанавливается в соответствии со значениями row и col. Затем рассчитываются максимальный и минимальный индексы для строк и столбцов, которые используются для расчёта базового местоположения и общего размера матрицы в памяти.

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

При извлечении значения из матрицы происходят такие же вычисления, как и при внесении значения в неё. Однако при этом ничего не записывается — содержимое извлекается и записывается в нужную переменную (например MatrixLeet).

Указатели

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

Давайте сразу разберёмся в машинном коде:

Сначала мы присваиваем переменной num значение 10.

Затем указателю pointer присваивается адрес переменной num.

Вывод переменной num на экран.

Вывод переменной pointer на экран.

Вывод адреса переменной num происходит с помощью инструкции lea (загрузка результирующего адреса) вместо mov.

Вывод адреса переменной num через указатель pointer.

Вывод адреса переменной pointer происходит с помощью инструкции lea вместо mov.

Динамическое распределение памяти

В этой статье будут рассмотрены следующие виды динамического распределения памяти:

1. malloc.
2. calloc.
3. realloc.

malloc — динамическое выделение памяти

Сначала разберёмся в коде:

Прим. перев. В оригинале статьи выделяется 11 байтов, хотя правильно будет 12. В конце строки ещё добавляется символ с кодом 0.

В этой функции выделяется место под 11 символов с помощью malloc(), а затем в выделенное пространство памяти копируется «Hello World».

Теперь давайте посмотрим на машинный код:

Примечание Во время сборки вы можете увидеть инструкции «nop». Эти инструкции были специально размещены на этапе подготовки к статье, чтобы различные части кода было проще понимать.

При использовании malloc() размер выделенной памяти (0x0B) сначала перемещается в регистр edi. Затем системная функция _malloc вызывается для выделения памяти. Выделенная область памяти затем сохраняется в переменной ptr. Потом строка «Hello World» разбивается на «Hello Wo» и «rld», поскольку она копируется в выделенное пространство памяти. Наконец, вновь скопированная строка «Hello World» выводится на экран, а выделенная память освобождается с помощью функции _free.

calloc — динамическое чистое выделение памяти

Посмотрим на код:

Как и в методе malloc(), место для 11 символов выделяется, а строка «Hello World» копируется в указанное пространство. Затем вновь перемещённый «Hello World» распечатывается, и выделенное пространство памяти освобождается.

Динамическое распределение памяти через calloc() выглядит почти идентично динамическому распределению памяти через malloc() в машинном коде.
Во-первых, пространство для 11 символов (0x0B) выделяется с помощью системной функции _calloc. Затем строка «Hello World» разбивается на «Hello Wo» и «rld„, поскольку она копируется во вновь выделенную область памяти. Затем вновь перемещённая строка “Hello World» выводится на экран, а выделенная область памяти освобождается с помощью функции _free.

realloc — динамическое перераспределение памяти

Сначала посмотрим код.

В этой функции память для 11 символов выделяется с помощью malloc(). Затем «Hello World» копируется в только что выделенное пространство памяти, прежде чем указанное расположение памяти перераспределяется, чтобы соответствовать 21 символу.

Прим. перев.: Должно быть 22 символа. Снова автор забыл символ с кодом 0, используя realloc()

Наконец, «1337 h4x0r @nonymoose» копируется в только что перераспределённое пространство. Наконец, после вывода на экран память освобождается.

Теперь посмотрим машинный код:

Сначала память выделяется с помощью malloc(). Затем, после вывода на экран только что перемещённой строки «Hello World», вызывается realloc() для переменной ptr (которая представляет переменную mem_alloc в коде), а также передаётся новый размер 0x15 (21 в десятичном виде). Затем «1337 h4x0r @nonymoose» разбивается на «1337 h4x„, “0r @nony», «moos» и «e„, поскольку он копируется в только что перераспределённое пространство памяти. Наконец, пространство освобождается с помощью функции _free.

Программирование сокетов

Далее мы рассмотрим программирование сокетов, разобрав очень простую систему клиент-серверного TCP-чата.

Прежде чем мы начнём разбирать код сервера или клиента, важно указать следующую строку кода в верхней части файла:

Эта строка определяет константу PORT как 1337. Эта константа будет использоваться как на клиенте, так и на сервере в качестве сетевого порта, используемого для создания соединения.

Серверная часть

Сначала посмотрим на код:

Сначала создаётся файловый дескриптор сокета server с доменом AF_INET, типом SOCK_STREAM и кодом протокола 0. Далее настраиваются параметры сокета и адрес. Затем сокет привязывается к сетевому адресу (порту), и сервер начинает прослушивать указанный порт с максимальной длиной очереди 3. После получения соединения сервер принимает его в переменную sock и считывает переданное значение в переменную value.

Наконец, сервер отправляет строку serverhello по соединению до возврата функции.

Теперь давайте разберём его в машинном коде:

Сначала создаются и инициализируются переменные сервера.

Затем создаётся файловый дескриптор сокетов server с помощью системной функции _socket. Параметры для функции — протокол, тип и доменное имя передаются с помощью регистров edx, esi и edi соответственно.

Затем вызывается _setsockopt для задания параметров сокета в файле дескриптора “server».

Инициализируется серверный адрес с помощью adress.sin_family, address.sin_addr.s_addr и address.sin_port.

После того как сервер был сконфигурирован, он привязывается к интернет-адресу с помощью _bind.

После привязки сервер слушает сокет, передав файловый дескриптор server. Максимальная длина очереди равна 3.

Как только соединение установлено, сервер принимает соединение сокета в переменную sock.

Затем сервер считывает переданное в переменную value сообщение с помощью _read.

В конце концов, сервер отсылает сообщение serverhello через переменную s в машинном коде.

Клиентская часть

Сначала разберёмся в коде:

Сначала создаётся файловый дескриптор сокета sock с помощью переменной домена AF_INET типа SOCK_STREAM и кода протокола 0. Затем memset используется для заполнения области памяти server_addr нулями до того, как информация об адресе будет установлена ​​с помощью server_addr.sin_family и server_addr.sin_port. До того как клиент подключится к серверу, информация об адресе преобразуется из текстового в двоичный формат с использованием inet_pton. После подключения клиент отправляет строку helloclient и затем принимает ответ сервера в переменную value. Наконец, переменная value выводится на экран, и происходит возврат из функции.

Теперь разбёремся в машинном коде:

Сначала инициализируются локальные переменные клиента.

Дескриптор файла сокета «sock» создается путём вызова системной функции _socket и передачи информации о протоколе, типе и домене через регистры edx, esi и edi соответственно.

Переменная server_address (в машинном коде «s») заполняется нулями (0x30) с помощью системного вызова _memset.

Потом настраивается адресная информация сервера.

Затем адрес переводится из текстового в двоичный формат с помощью системной функции _inet_pton. Обратите внимание, что, поскольку в коде явно не указан адрес, предполагается localhost (127.0.0.1).

Клиент подключается к серверу с помощью системного вызова _connect.

После подключения клиент отправляет строку helloClient на сервер.

Наконец, клиент получает ответ сервера в переменную value с помощью системного вызова _read.

Многопоточность

Наконец, мы рассмотрим основы потоков в C.

Во-первых, давайте посмотрим на код:

Как вы можете видеть, программа сначала печатает «This is before the thread», затем создаёт новый поток, который указывает на функцию *mythread(), используя функцию pthread_create(). По завершении функции *mythread() (после сна длиной в 1 секунду и вывода на экрана «Hello from mythread») новый поток присоединяется к основному потоку с помощью функции pthread_join() и выводится на экран «This is after the thread».

Теперь давайте разберём машинный код:

Сначала программа печатает «This is before the thread».

Затем создаётся новый поток с помощью системного вызова _pthread_create. Этот поток получает mythread() в качестве аргумента.

Как вы можете видеть, функция mythread() просто спит одну секунду перед выводом «Hello from mythread».

Примечание Внутри функции mythread() вы увидите два нопа. Они были специально размещены для облегчения навигации на этапе подготовки этой статьи.

После возврата из функции mythread() новый поток соединяется с основным потоком с помощью функции _pthread_join.

Наконец, на экран выводится «This is after the thread» и происходит возврат из функции.

Заключение

В статье мы рассмотрели массивы, указатели, динамическое распределение памяти, программирование сокетов (сетевое программирование) и многопоточность. Понимание этих аспектов существенно поможет вам продвинуться в изучении реверс-инжиниринга.

Примечание Программный код для этой статьи компилируется с помощью Microsoft Visual Studio 2015, так что некоторые функции в новых версиях могут использоваться по-другому. В качестве дизассемблера используется IDA Pro.

1. Инициализация переменных
2. Стандартная функция вывода
3. Математические операции
4. Вызов функций
5. Циклы
6. Условный оператор
7. Оператор выбора
8. Пользовательский ввод

Инициализация переменных

Переменные — одна из основных составляющих программирования. Они делятся на несколько видов, вот некоторые из них:

• строка;
• целое число;
• логическая переменная;
• символ;
• вещественное число с двойной точностью;
• вещественное число;
• массив символов.

Стандартные переменные:

Примечание в С++ строка — не примитивная переменная, но важно понять, как она будет выглядеть в машинном коде.

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

Инициализация переменных

Здесь можно увидеть как IDA показывает распределение пространства для переменных. Сначала под каждую переменную выделяется пространство, а потом уже она инициализируется.

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

Для инициализации строки требуется вызов встроенной функции.

Стандартная функция вывода

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

Для вывода данных было решено использовать printf(), а не cout.

Стандартный вывод:

Теперь посмотрим на машинный код. Сначала строковый литерал:

Как видите, строковый литерал сначала помещается в стек для вызова в качестве параметра функции printf().

Теперь посмотрим на вывод одной из переменных:

Как можно заметить, сначала переменная intvar помещается в регистр EAX, который в свою очередь записывается в стек вместе со строковым литералом %i, используемым для обозначения целочисленного вывода. Эти переменные затем берутся из стека и используются в качестве параметров при вызове функции printf().

Математические операции

Сейчас мы поговорим о следующих математических операциях:

1. Сложение.
2. Вычитание.
3. Умножение.
4. Деление.
5. Поразрядная конъюнкция (И).
6. Поразрядная дизъюнкция (ИЛИ).
7. Поразрядное исключающее ИЛИ.
8. Поразрядное отрицание.
9. Битовый сдвиг вправо.
10. Битовый сдвиг влево.

Переведём каждую операцию в ассемблерный код:

сначала присвоим переменной A значение 0A в шестнадцатеричной системе счисления или 10 в десятичной. Переменной B — 0F, что равно 15 в десятичной.

Для сложения мы используем инструкцию add:

При вычитании используется инструкция sub:

При умножении — imul:

Для деления используется инструкция idiv. Также мы используем оператор cdq, чтобы удвоить размер EAX и результат деления уместился в регистре.

При поразрядной конъюнкции используется инструкция and:

При поразрядной дизъюнкции — or:

При поразрядном исключающем ИЛИ — xor:

При поразрядном отрицании — not:

При битовом сдвиге вправо — sar:

При битовом сдвиге влево — shl:

Вызов функций

Мы рассмотрим три вида функций:

1. Функция, не возвращающая значение (void).
2. Функция, возвращающая целое число.
3. Функция с параметрами.

Вызов функций:

Сначала посмотрим, как происходит вызов функций newfunc() и newfuncret(), которые вызываются без параметров.

Функция newfunc() просто выводит сообщение «Hello! I’m a new function!»:

Функция newfunc()

Эта функция использует инструкцию retn, но только для возврата к предыдущему местоположению (чтобы программа могла продолжить свою работу после завершения функции). Посмотрим на функцию newfuncret(), которая генерирует случайное целое число с помощью функции С++ rand() и затем его возвращает.

Сначала выделяется место под переменную A. Затем вызывается функция rand(), результат которой помещается в регистр EAX. Затем значение EAX помещается в место, выделенное под переменную A, фактически присваивая переменной A результат функции rand(). Наконец, переменная A помещается в регистр EAX, чтобы функция могла его использовать в качестве возвращаемого параметра. Теперь, когда мы разобрались, как происходит вызов функций без параметров и что происходит при возврате значения из функции, поговорим о вызове функции с параметрами.

Вызов такой функции выглядит следующим образом:

Вызов функции с параметрами

Строки в С++ требуют вызова функции basic_string, но концепция вызова функции с параметрами не зависит от типа данных. Сначала переменная помещается в регистр, затем оттуда в стек, а потом происходит вызов функции.

Посмотрим на код функции:

Эта функция берёт строку, целое число и символ и печатает их с помощью функции printf(). Как видите, сначала переменные размещаются в начале функции, затем они помещаются в стек для вызова в качестве параметров функции printf(). Очень просто.

Циклы

Теперь, когда мы изучили вызов функции, вывод, переменные и математику, перейдём к контролю порядка выполнения кода (flow control). Сначала мы изучим цикл for:

Прежде чем разбить ассемблерный код на более мелкие части, посмотрим на общий вариант. Как вы можете видеть, когда цикл for запускается, у него есть 2 варианта:

• он может перейти к блоку справа (зелёная стрелка) и вернуться в основную программу;
• он может перейти к блоку слева (красная стрелка) и вернуться к началу цикла for.

Сначала сравниваются переменные i и max, чтобы проверить, достигла ли переменная максимального значения. Если переменная i не больше или не равна переменной max, то подпрограмма пойдёт по красной стрелке (вниз влево) и выведет переменную i, затем i увеличится на 1 и произойдёт возврат к началу цикла. Если переменная i больше или равна max, то подпрограмма пойдёт по зелёной стрелке, то есть выйдет из цикла for и вернётся в основную программу.

Теперь давайте взглянем на цикл while:

В этом цикле генерируется случайное число от 0 до 20. Если число больше 10, то произойдёт выход из цикла со словами «I’m out!», в противном случае продолжится работа в цикле.

В машинном коде переменная А сначала инициализируется и приравнивается к нулю, а затем инициализируется цикл, A сравнивается с шестнадцатеричным числом 0A, которое равно 10 в десятичной системе счисления. Если А не больше и не равно 10, то генерируется новое случайное число, которое записывается в А, и снова происходит сравнение. Если А больше или равно 10, то происходит выход из цикла и возврат в основную программу.

Условный оператор

Теперь поговорим об условных операторах. Для начала посмотрим код:

Эта функция генерирует случайное число от 0 до 20 и сохраняет получившееся значение в переменной А. Если А больше 15, то программа выведет «greater than 15». Если А меньше 15, но больше 10 — «less than 15, greater than 10». Если меньше 5 — «less than 5».

Посмотрим на ассемблерный граф:

Граф структурирован аналогично фактическому коду, потому что условный оператор выглядит просто: «Если X, то Y, иначе Z». Если посмотреть на первую сверху пару стрелок, то оператору предшествует сравнение А с 0F, что равно 15 в десятичной системе счисления. Если А больше или равно 15, то подпрограмма выведет «greater than 15» и вернётся в основную программу. В другом случае произойдёт сравнение А с 0A (1010). Так будет продолжаться, пока программа не выведет что-нибудь на экран и не вернётся.

Оператор выбора

Оператор выбора очень похож на оператор условия, только в операторе выбора одна переменная или выражение сравнивается с несколькими «случаями» (возможными эквивалентностями). Посмотрим код:

В этой функции переменная А получает случайное значение от 0 до 10. Затем А сравнивается с несколькими случаями, используя switch. Если значение А равно одному из случаев, то на экране появится соответствующее число, а затем произойдёт выход из оператора выбора и возврат в основную программу.

Оператор выбора не следует правилу «Если X, то Y, иначе Z» в отличии от условного оператора. Вместо этого программа сравнивает входное значение с существующими случаями и выполняет только тот случай, который соответствует входному значению. Рассмотрим два первых блока подробней.

Сначала генерируется случайное число и записывается в А. Теперь программа инициализирует оператор выбора, приравняв временную переменную var_D0 к А, затем проверяет, что она равна хотя бы одному из случаев. Если var_D0 требуется значение по умолчанию, то программа пойдёт по зелёной стрелке в секцию окончательного возврата из подпрограммы. Иначе программа совершит переход в нужный case.

Если var_D0 (A) равно 5, то код перейдёт в секцию, которая показана выше, выведет «5» и затем перейдёт в секцию возврата.

Пользовательский ввод

В этом разделе мы рассмотрим ввод пользователя с помощью потока сin из C++. Во-первых, посмотрим на код:

В этой функции мы просто записываем строку в переменную sentence с помощью функции C++ cin и затем выводим предложение с помощью оператора printf().

Разберём это в машинном коде. Во-первых, функция cin:

Сначала происходит инициализация строковой переменной sentence, затем вызов cin и запись введённых данных в sentence.

Сначала программа устанавливает содержимое переменной sentence в EAX, затем помещает EAX в стек, откуда значение переменной будет использоваться в качестве параметра для потока cin, затем вызывается оператор потока >>. Его вывод помещается в ECX, который затем помещается в стек для оператора printf():

Мы рассмотрели лишь основные принципы работы программного обеспечения на низком уровне.  Без этих основ невозможно понимать работу ПО и, соответственно, заниматься его исследованием.

Смотрите также: Эксплуатация уязвимостей исполняемых файлов для новичков

Возможности cpu_features

Не все процессоры имеют одинаковый набор функций. Существуют индивидуальные методы, или даже наборы инструкций, позволяющие улучшить производительность программы, но доступные лишь на определенных архитектурах процессоров. Например, процессоры Intel с архитектурой Haswell поддерживают набор инструкций AVX2. А вот архитектура Sandy Bridge не имеет такой функции. В таком случае на помощь придет cpu_features, способная определить доступные функции за пару строк кода. Это будет очень полезно для разработчиков, старающихся максимально ускорить и оптимизировать свой код, особенно если это драйвер для устройства или новый видеокодек.

На момент написания статьи библиотека поддерживает процессоры x86, ARM, AArch64 и MIPS. Более детально о поддерживаемых архитектурах и технологиях ниже:

Исходный код библиотеки и документация доступны на GitHub.

Как такое возможно?

Оказывается, сама по себе инструкция mov тьюринг-полная, а значит, с её помощью можно запрограммировать любой алгоритм, как на классических языках.

Если коротко, то суть в том, как проводить «сравнения» и затем в зависимости от результата выполнять определённую команду. Допустим, мы хотим сравнить значения A и B. Помещаем их в регистры Ri и Rj. Мы это можем сделать, у нас есть mov. Затем выполняем хитрый код:

Здесь мы интерпретируем значения Ri и Rj (т.е. A и B) как адреса и записываем в них 0 и 1. Если значения были одинаковые, то и адрес будет одинаковый, и он перезапишется. В итоге в Rk будет 1, если A=B, и 0 в другом случае. Почему нам не важно, что было по адресам Ri и Rj — читайте в подробном разборе, для нас это сейчас не имеет значения.

Затем мы можем поместить по некоторому адресу N одну инструкцию, а в следующую ячейку памяти N+1 — другую. И выполнить ту, что по адресу N+Rk. Вот мы и получили аналог условного выполнения инструкций, но используя только mov. Осталось только перевести весь код в такую форму, а в самом конце добавить безусловный переход на начало программы.

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

Зачем это нужно?

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

Для авторов M/o/Vfuscator сборка DOOM только через mov-инструкции нужна для доказательства работоспособности их метода. Работает, правда, всё очень долго — один кадр рендерится около 7 часов. Но в данном случае главное, что вообще работает.

Совет Не стоит сдавать или использовать (даже в изменённом виде) приведённый ниже код в качестве домашнего проекта в школе или вузе. Многие преподаватели знают об оригинальной статье и уличат вас в обмане.

Жизненный цикл командной оболочки

Оболочка выполняет три основные операции за время своего существования:

1. Инициализация: на этом этапе она читает и исполняет свои файлы конфигурации. Они изменяют её поведение.
2. Интерпретация: далее оболочка считывает команды из stdin и исполняет их.
3. Завершение: после исполнения основных команд она исполняет команды выключения, освобождает память и завершает работу.

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

В примере выше можно увидеть функцию lsh_loop(), которая будет циклически интерпретировать команды. Реализацию рассмотрим чуть ниже.

Базовый цикл командной оболочки

В первую очередь нам нужно подумать о том, как программа должна запускаться. И здесь важно понимать, что делает оболочка во время цикла. Простой способ обработки команд состоит из трех шагов:

1. Чтение: считывание команды со стандартных потоков.
2. Парсинг: распознавание программы и аргументов во входной строке.
3. Исполнение: запуск распознанной команды.

Эта идея реализована в функции lsh_loop():

Пройдемся по коду. Первые несколько строк — это просто объявления. Цикл с постусловием более удобен для проверки состояния переменной, поскольку выполняется перед проверкой ее значения. Внутри цикла выводится приглашение ввода, вызываются функции для чтения входной строки и разбиения строки на аргументы, а затем исполняются аргументы. Далее освобождается память, выделенная под строку и аргументы. Стоит обратить внимание, что в коде используется переменная состояния, возвращаемая в lsh_execute() и определяющая, когда нужно выйти из функции.

Чтение строки

Чтение строки из стандартного потока ввода — это вроде бы просто, но в C это может вызвать много хлопот. Беда в том, что никто не знает заранее, сколько текста пользователь введет в командную оболочку. Нельзя просто выделить блок и надеяться, что пользователи не выйдут за него. Вместо этого нужно перераспределять выделенный блок памяти, если пользователи выйдут за его пределы. Это стандартное решение в C, и именно оно будет использоваться для реализации lsh_read_line().

В первой части много объявлений. Стоит отметить, что в коде используется старый стиль C, а именно объявление переменных до основной части кода. Основная часть функции находится внутри, на первый взгляд, бесконечного цикла while(1). В цикле символ считывается и сохраняется как int, а не char (EOF — это целое число, а не символ, поэтому для проверки используйте int). Если это символ перевода строки или EOF, мы завершаем текущую строку и возвращаем ее. В обратном случае символ добавляется в существующую строку.

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

Те, кто знаком с новыми версиями стандартной библиотеки C, могут заметить, что в stdio.h есть функция getline(), которая выполняет большую часть работы, реализованной в коде выше. Эта функция была расширением GNU для библиотеки C до 2008 года, а затем была добавлена в спецификацию, поэтому большинство современных Unix-систем уже идут с ней в комплекте.  С getline функция становится тривиальной:

Парсинг строки

Теперь нам нужно распарсить входную строку в список аргументов. Мы сделаем небольшое упрощение и запретим пользователю использовать кавычки и обратную косую черту в аргументах командной строки. Вместо этого для разделения аргументов мы просто будем использовать пробелы. Таким образом команда  echo "вот сообщение" будет вызывать команду echo не с одним аргументом "вот сообщение", а с двумя:"вот" и "сообщение".

Теперь всё, что нам нужно сделать — разбить строку на части, используя пробелы в качестве разделителей. Это значит, что мы можем использовать классическую библиотечную функцию strtok.

Реализация этой функции подозрительно похожа на lsh_read_line(), и это неспроста! Здесь используется та же стратегия, только вместо нуль-терминированного массива символов мы используем нуль-терминированный массив указателей.

Мы начинаем разбиение, вызывая strtok. Она возвращает указатель на первый кусок строки (токен). Вообще strtok() возвращает указатели на места в строке и помещает нуль-терминаторы в конце каждого токена. Эти указатели мы храним в отдельном массиве.

При необходимости мы перераспределим массив указателей. Повторяем процесс до тех пор, пока strtok не перестанет возвращать токены, и завершаем массив токенов нуль-терминатором.

Теперь у нас есть массив токенов, готовых к исполнению.

Как командные оболочки запускают процессы

Теперь мы добрались до самой сути того, что делает оболочка. Запуск процессов — это основная функция командных оболочек. Поэтому если вы создаёте оболочку, то должны точно знать, что происходит с процессами и как они запускаются. Именно поэтому сейчас мы поговорим о процессах в Unix.

В Unix есть только два способа запуска процессов. Первый (который не будем брать в счет) — это Init. Видите ли, когда загружается Unix-система, загружается её ядро. После загрузки и инициализации ядро запускает только один процесс, который называется Init. Этот процесс выполняется в течение всего времени работы компьютера, и  управляет загрузкой остальных процессов, которые необходимы для его работы.

Поскольку все остальные процессы не Init, остаётся только один практический способ запуска процессов: системный вызов fork(). Когда эта функция вызывается, операционная система делает дубликат процесса и запускает их параллельно. Первоначальный процесс называется «родительским», а новый — «дочерним». Дочернему процессу fork() возвращает 0, а родителю — идентификатор процесса (PID) его дочернего элемента. Таким образом, любой новый процесс можно создать только из копии уже существующего.

Это может показаться проблемой. Обычно, когда вы хотите запустить новый процесс, вам не нужна копия уже работающей программы — вы хотите запустить другую программу. Для этого нужно использовать системный вызов exec(). Он заменяет текущую запущенную программу совершенно новой. Это значит, что при вызове exec операционная система останавливает процесс, загружает новую программу и запускает ее на том же месте. Вызов exec() не возвращает процесс, если нет ошибки.

Благодаря этим двум системным вызовам и возможен запуск большинства программ в Unix. Сперва существующий процесс раздваивается на родительский и дочерний, а затем дочерний процесс использует exec() для замены себя новой программой. Родительский процесс может продолжать делать другие вещи, а также следить за своими дочерними элементами, используя системный вызов wait().

Да уж, информации немало. Давайте посмотрим на код запуска программы:

Эта функция принимает список аргументов, которые мы создали ранее. Затем она разворачивает процесс и сохраняет возвращаемое значение. Как только fork() возвращает значение, мы получаем два параллельных процесса. Дочернему процессу соответствует первое условие if (где pid == 0).

В дочернем процессе мы хотим запустить команду, заданную пользователем. Поэтому мы используем один из вариантов системного вызова exec, execvp. Разные варианты exec делают разные вещи. Одни принимают переменное количество строковых аргументов, другие берут список строк, а третьи позволяют указать окружение, в котором выполняется процесс. Этот конкретный вариант принимает имя программы и массив (также называемый вектором, отсюда 'v') строковых аргументов (первым должно быть имя программы). 'p' означает, что вместо предоставления полного пути к файлу программы для запуска мы укажем только её имя, а также скажем операционной системе искать её самостоятельно.

Если команда exec возвращает -1 (или любое другое значение), значит, произошла ошибка. Таким образом, мы используем perror для вывода сообщения об ошибке вместе с именем программы, чтобы было понятно, где произошла ошибка. Затем мы завершаем процесс, но так, чтобы программная оболочка продолжала работать.

Второе условие (pid < 0) проверяет, произошла ли в процессе выполнения fork() ошибка. Если ошибка есть, мы выводим сообщение об этом на экран, но программа продолжает работать.

Третье условие означает, что вызов fork() выполнен успешно. Там находится родительский процесс. Мы знаем, что потомок собирается исполнить процесс, поэтому родитель должен дождаться завершения команды. Мы используем waitpid() для ожидания изменения состояния процесса. К сожалению, у waitpid() есть много опций (например, exec()). Процессы могут изменять свое состояние множеством способов, и не все состояния означают, что процесс завершился. Процесс может либо завершиться обычным путём (успешно либо с кодом ошибки), либо быть остановлен сигналом. Таким образом, мы используем макросы, предоставляемые waitpid(), чтобы убедиться, что процесс завершен. Затем функция возвращает 1 как сигнал вызывающей функции, что она снова может вывести приглашение ввода.

Встроенные функции оболочки

Возможно, вы заметили, что функция lsh_loop() вызывает lsh_execute(), но выше мы назвали нашу функцию lsh_launch(). Это было намеренно! Дело в том, что большинство команд, которые исполняет оболочка, являются программами — но не все. Некоторые из команд встроены прямо в оболочку.

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

Аналогично программа с именем exit не сможет выйти из командной оболочки, которая ее вызвала. Эта команда также должна быть встроена в оболочку. Кроме того, большинство оболочек настраиваются с помощью сценариев конфигурации, таких как ~/.bashrc. Эти сценарии используют команды, которые изменяют работу оболочки. Сами же команды могут изменить работу оболочки, если только они были реализованы внутри самой оболочки.

Соответственно, имеет смысл добавить некоторые команды в оболочку. В эту оболочку мы добавим cd, exit и help. А вот и реализация этих функций:

Код состоит из трёх частей. Первая часть содержит предваряющее объявление функций. Предваряющее объявление — это когда вы объявляете (но не определяете) что-то, чтобы можно было использовать это имя до его определения.lsh_help() — причина, по которой мы делаем это. Она использует массив встроенных функций, а сами массивы содержат lsh_help(). Самый простой способ разбить этот цикл зависимостей — это предваряющее объявление.

Следующая часть представляет собой массив имён встроенных команд, за которыми следует массив соответствующих функций. Это значит, что в будущем встроенные команды могут быть добавлены путем изменения этих массивов, а не большого оператора switch где-то в коде. Если вы смущены объявлением builtin_func, все в порядке. Это массив указателей на функции (которые принимают массив строк и возвращают int). Любое объявление, включающее указатели на функции в C, может стать действительно сложным.

Наконец, идет реализация каждой функции. Функция lsh_cd() сначала проверяет наличие своего второго аргумента и выводит сообщение об ошибке, если его нет. Затем она вызывает chdir(), проверяет наличие ошибок и завершает работу. Функция справки выводит информативное сообщение и имена всех встроенных функций. А функция выхода возвращает 0, как сигнал для окончания цикла команд.

Объединение встроенных функций и процессов

Последний недостающий фрагмент головоломки заключается в реализации функции lsh_execute(), которая либо запускает либо встроенный, либо другой процесс.

Код проверяет, является ли команда встроенной. Если это так, то запускает её, а в противном случае вызывает lsh_launch(), чтобы запустить процесс.

Собираем все вместе

Вот и весь код, который входит в командную оболочку. Если вы внимательно читали статью, то должны были понять, как работает оболочка. Чтобы испробовать оболочку (на Linux), вам нужно скопировать эти сегменты кода в файл main.c и скомпилировать его. Обязательно включите только одну реализацию lsh_read_line(). Вам нужно будет включить следующие заголовочные файлы:

• #include <sys/wait.h>waitpid() и связанные макросы
• #include <unistd.h>chdir() fork() exec() pid_t
• #include <stdlib.h>malloc() realloc() free() exit() execvp() EXIT_SUCCESS, EXIT_FAILURE
• #include <stdio.h>fprintf() printf() stderr getchar() perror()
• #include <string.h>strcmp() strtok()

Чтобы скомпилировать файл, введите в терминале gcc -o main main.c, а затем ./main, чтобы запустить.

Кроме того, все исходники доступны на GitHub.

Подводя итоги

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

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

Чтобы разобраться в системных вызовах, рекомендуем обратиться к мануалу: man 3p. Если вы не знаете, какой интерфейс вам предлагают стандартная библиотека C и Unix, советуем посмотреть спецификацию POSIX, в частности раздел 13.

Демонстрация

Компиляция функции, вычисляющей простые числа, с помощью M/o/Vfuscator в сравнении с GCC:

Язык Ассемблера

GCC

M/o/Vfuscator

Граф потока управления

GCC

M/o/Vfuscator

M/o/Vfuscator в действии

Пример поинтереснее

Сборка

M/o/Vfuscator использует LCC в качестве препроцессора. Предлагаемый скрипт сборки автоматически загружает LCC, настраивает его конфигурацию для MOV и собирает M/o/Vfuscator.

Если вы проводите сборку на 64-битной системе, убедитесь, что у вас есть доступ к 32-битной стандартной библиотеке (например, apt-get install libc6-dev-i386 или yum install glibc-devel.i686).

Тестирование

Проверьте, что сборка произошла корректно, с помощью следующего скрипта:

Использование

Компилируйте программы как обычно.

Всю остальную необходимую информацию можно найти в репозитории проекта на GitHub.

Благодаря этой книге вы научитесь следующему:

• Узнаете, как создать операционную систему на основе технической документации железа. В реальном мире это так и работает, вы не сможете использовать Google для быстрых ответов.
• Поймёте, как компьютерные компоненты взаимодействуют друг с другом, от софта к железу.
• Научитесь писать код самостоятельно. Слепое копирование кода не есть обучение, вы действительно научитесь решать проблемы. Кстати, слепое копирование может быть еще и опасно.
• Освоите всем привычные инструменты для низкоуровневой разработки.
• Познакомитесь с языком ассемблера.
• Выясните, из чего состоят программы и как операционная система запускает их. Небольшой обзор этой темы для любознательных мы давали в одном из наших материалов.
• Разберётесь, как проводить отладку программы прямо на железе с GDB и QEMU.

Если читать целую книгу у вас нет времени, но вы хотите получить краткий экскурс, прочтите две наших статьи, посвященных созданию ядра для собственной ОС: часть 1 и часть 2.

Что рекомендуется знать перед прочтением книги:

• Язык программирования C. Быстро освоить его можно, следуя нашему руководству.
• Базовые знания Linux. Достаточно изучить соответствующую рубрику на нашем сайте.
• Базовые знания в физике: атомы, электроны, протоны, нейтроны, напряжение.
• Закон Ома о соотношении напряжения, силы тока и сопротивления.

Книга совершенствуется и редактируется почти каждый день: вы и сами можете внести изменения или исправить опечатку. Операционная система, разработка которой послужила “сюжетом” для этой книги, опубликована на GitHub и также со временем улучшается.

На сайте можно написать исполняемый 6502-код и тут же запустить его, либо изучить любой из многочисленных образцов программ: например, можно увидеть код типичной таблицы результатов или реализацию стартовой заставки. Из более сложных примеров стоит отметить подобие арканоида и 3D-дорогу (на скриншоте выше).

Целые числа

Установка n-ого бита

Обнуление n-ого бита

Переключение n-ого бита

Округление до следующей степени двойки

Получение максимального целого

Получение минимального целого

Получение максимального long

Умножение на 2

Деление на 2

Умножение на m-тую степень 2

Деление на m-тую степень 2

Проверка на равенство

На 35% быстрее, чем JS 🙂

Проверка на чётность

Обмен значениями

Модуль

Максимум двух чисел

Минимум двух чисел

Проверка на одинаковый знак

Смена знака

Вычисление 2^n

Проверка на степень 2

Остаток от деления 2^n на m

Среднее арифметическое

Получение m-ого бита n (справа налево)

Установка m-ого бита n (справа налево)

Проверка n-ого бита

Выделение самой правой 1

Выделение самого правого 0

Смена самого правого 0 на 1

n+1

n-1

if (x==a) x=b; if (x==b) x=a;

Строки

Преобразование буквы в строчную

Преобразование буквы в заглавную

Смена вида буквы

Номер буквы в алфавите

Номер заглавной буквы в алфавите

Номер строчной буквы в алфавите

Прочее

Быстрая смена цвета с R5G5B5 на R8G8B8

Примечание: можно использовать только латиницу.

В прошлой статье я писал о том, как создать простейшее x86-ядро, использующее GRUB, работающее в защищённом режиме и выводящее на экран строку. В этот раз мы подключим к ядру драйвер клавиатуры, который может считывать символы a–z и 0–9 с клавиатуры и выводить их на экран. Весь используемый код можно найти на GitHub.

Мы общаемся с устройствами ввода / вывода, используя I/O-порты. Эти порты — просто определённые адреса на шине ввода / вывода x86-системы. Операции чтения / записи на этих портах обрабатываются специальными инструкциями, встроенными в процессор.

Чтение из портов и запись в них

Доступ к портам I/O можно получить, используя инструкции in и out, являющиеся частью набора инструкций x86.

В read_port номер порта принимается как аргумент. Когда компилятор вызывает вашу функцию, он пушит все её аргументы в стек. Аргумент копируется в регистр edx по указателю на стек. Регистр dx — это младшие 16 бит edx. Инструкция in читает из порта, номер которого хранится в dx, и помещает результат в al. Регистр al — это младшие 8 бит eax. Если вы помните, чему вас учили, то знаете, что возвращаемые функциями значения передаются через регистр eax register. Таким образом, read_port обеспечивает чтение из I/O-портов.

write_port очень похожа. Мы принимаем два аргумента: номер порта и данные для записи. Инструкция out записывает данные в указанный порт.

Прерывания

Теперь, прежде чем мы продолжим писать какой-либо драйвер устройства, давайте разберемся, как процессор узнаёт о том, что устройство совершило действие.

Самое простое решение — это поллинг, постоянная проверка состояния устройства. По очевидным причинам это не самое практичное решение. Тут в дело вступают прерывания. Прерывание — это сигнал, посылаемый процессору аппаратным или системным обеспечением, который оповещает о событии. Используя прерывания, мы можем действовать только тогда, когда возникает интересующее нас прерывание.

Устройство, называемое контроллером прерываний (Programmable Interrupt Controller, PIC), отвечает за обработку аппаратных прерываний и отправку их соответствующим системным прерываниям.

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

Если бы у нас не было контроллера прерываний, то нам пришлось бы постоянно опрашивать все устройства на наличие произошедших событий.

Рассмотрим случай с клавиатурой. Она работает через I/O-порты 0x60 и 0x64. Порт 0x60 передаёт данные (о нажатой клавише), а порт 0x64 — состояние. Однако нужно знать наверняка, когда и из какого порта читать данные.

Для этого отлично подходят прерывания. Когда происходит нажатие клавиши, клавиатура посылает сигнал на контроллер прерываний по линии IRQ1. Контроллер обладает значением offset, полученным во время его инициализации. Он добавляет номер входной линии к этому offset и получает число прерывания. Затем процессор обращается к специальной структуре данных, называющейся дескрипторной таблицей прерываний (Interrupt Descriptor Table, IDT), для передачи обработчику прерываний адреса, соответствующего числу прерывания.

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

Настраиваем IDT

Мы реализуем IDT как массив структур IDT_entry. Мы обсудим то, как прерывание клавиатуры привязано к своему обработчику, позже. Сперва посмотрим, как работают контроллеры прерываний.

Современные x86-системы имеют два контроллера прерываний по 8 входных линий. Назовём их PIC1 и PIC2. PIC1 получает сигналы с IRQ0 до IRQ7, а PIC2 — с IRQ8 до IRQ15. PIC1 использует порт 0x20 для команд и 0x21 — для данных. PIC2 использует порт 0xA0 для команд и 0xA1 — для данных.

Контроллеры инициализируются 8-битными инициализирующими командными словами (Initialization command words, ICW). Подробный синтаксис этих команд можно изучить здесь.

В защищённом режиме первой командой, которую вы должны передать двум контроллерам прерываний, является инициализирующая команда ICW1 (0x11). Эта команда заставляет контроллер ждать поступления ещё трёх инициализирующих слов на порт данных.

Эти команды сообщают контроллерам следующее:

• сдвиг (ICW2);
• состояние подключения (master/slave) (ICW3);
• дополнительную информацию об окружении (ICW4).

Вторая инициализирующая команда — это ICW2, которая записывает в порты данных каждого контроллера его сдвиг.

Контроллеры допускают каскадирование выводов и вводов, что настраивается командой ICW3, но мы не будем его использовать, поэтому установим все значения в ноль.

ICW4 устанавливает дополнительные параметры окружения. Мы  заполним младший бит, чтобы сказать контроллерам, что мы работаем в режиме 80×86.

Та-дам! Контроллеры прерываний инициализированы!

У каждого контроллера есть внутренний 8-битный регистр, называющийся регистр масок прерывания (Interrupt Mask Register, IMR). Этот регистр хранит битмэп линий IRQ, идущих в контроллер. Если бит установлен, контроллер игнорирует запрос. Это означает, что мы можем включать и выключать любую линию IRQ, меняя соответствующее значение в IMR. Чтение из порта данных возвращает значение из IMR, а запись — задаёт это значение. В нашем коде мы отключаем все линии IRQ, чтобы позже включить ту, что соответствует клавиатуре.

Если линии IRQ включены, наши контроллеры могут получать идущие по ним сигналы и преобразовывать их в числа прерываний, добавляя сдвиг. Теперь нам нужно найти IDT такую, чтобы число прерывания для клавиатуры было привязано к адресу обработчика событий клавиатуры, который мы напишем.

Какое число прерывания должно соответствовать обработчику событий клавиатуры?

Клавиатура использует IRQ1. Это линия ввода 1 контроллера PIC1. Его сдвиг равен 0x20. Для получения числа прерывания сложим 1 + 0x20 и получим 0x21. Таким образом, адрес обработчика событий должен быть связан с прерыванием 0x21 в IDT.

Теперь нам нужно определить IDT для прерывания 0x21. Мы привяжем это прерывание к функции keyboard_handler, которую запишем в ассемблерном файле.

Каждое значение в IDT состоит из 64 битов. В значении IDT для прерывания мы не храним адрес функции-обработчика целиком, а делим его на 2 части по 16 бит. Младшие биты хранятся в первых 16 битах значения IDT, а старшие 16 битов — в последних. Это сделано в целях совместимости с 286. Да, такие костыли от Intel можно встретить часто!

В значении IDT мы также должны задать тип — это нужно для того, чтобы поймать исключение. Нам также нужно передать коду ядра смещение. GRUB создаст для нас глобальную таблицу дескрипторов, каждое значение которое занимает 8 байт. Дескриптор кода ядра — это второй сегмент, поэтому его сдвиг равен 0x08. Окно прерывания равно 0x8e. Оставшиеся посередине 8 бит должны быть заполнены нулями. Таким образом, мы заполнили значение IDT в соответствии с прерыванием клавиатуры.

После того, как мы закончили все махинации с IDT, мы сообщаем процессору её адрес, используя инструкцию lidt, принимающую один операнд, который должен быть указателем на структуру дескрипторов, описывающую IDT.

Дескриптор достаточно прост. Он содержит размер IDT в байтах и её адрес. Для хранения значений я использовал массив, но вы можете воспользоваться структурой.

У нас есть указатель в переменной idt_ptr, который мы передаём в lidt, используя функцию load_idt().

Кроме того, функция load_idt() включает прерывания, используя инструкцию sti.

Когда IDT настроена, мы можем включить линию IRQ клавиатуры, используя маску прерываний, о которой мы говорили ранее.

Функция обработки прерываний клавиатуры

Итак, наши прерывания клавиатуры привязаны к функции keyboard_handler через значение IDT для прерывания 0x21. Каждый раз, когда мы нажимаем клавишу, мы можем быть уверены, что функция будет вызвана.

Эта функция просто вызывает другую функцию, написанную на Си, и возвращает значение, используя класс инструкций iret. Мы могли бы написать здесь весь необходимый код, но на Си писать безусловно приятнее. iret/iretd используются вместо ret при работе с прерываниями.

Сперва мы отправляем сигнал EOI (конец прерывания), записывая его в порт команд контроллера. Только после этого контроллер принимает следующие прерывания. Нам нужно читать два порта — порт данных 0x60 и порт команд / данных 0x64.

Сперва мы читаем порт 0x64 для получения состояния. Если младший бит состояния равен 0, то буфер пуст, и данных для чтения нет. В обратном случае мы читаем порт данных 0x60. Этот порт даёт нам код каждой нажатой клавиши. Мы используем простой массив символов в файле keyboard_map.h для связывания кодов и символов.

В этой статье мы обрабатываем только строчные буквы и цифры. Конечно, можно настроить и обработку других клавиш, а также их сочетаний.

Вы можете собрать ядро и запустить его на реальной машине или в эмуляторе (QEMU) так же, как и в прошлой статье.

Печатайте!

Давайте напишем простое ядро, которое можно загрузить при помощи бутлоадера GRUB x86-системы. Это ядро будет отображать сообщение на экране и ждать.

Как загружается x86-система?

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

В большей части регистров процессора при запуске уже находятся определённые значения. Регистр, указывающий на адрес инструкций (Instruction Pointer, EIP), хранит в себе адрес памяти, по которому лежит исполняемая процессором инструкция. EIP по умолчанию равен 0xFFFFFFF0. Таким образом, x86-процессоры на аппаратном уровне начинают работу с адреса 0xFFFFFFF0. На самом деле это — последние 16 байт 32-битного адресного пространства. Этот адрес называется вектором перезагрузки (reset vector).

Теперь карта памяти чипсета гарантирует, что 0xFFFFFFF0 принадлежит определённой части BIOS, не RAM. В это время BIOS копирует себя в RAM для более быстрого доступа. Адрес 0xFFFFFFF0 будет содержать лишь инструкцию перехода на адрес в памяти, где хранится копия BIOS.

Так начинается исполнение кода BIOS. Сперва BIOS ищет устройство, с которого можно загрузиться, в предустановленном порядке. Ищется магическое число, определяющее, является ли устройство загрузочным  (511-ый и 512-ый байты первого сектора должны равняться 0xAA55).

Когда BIOS находит загрузочное устройство, она копирует содержимое первого сектора устройства в RAM, начиная с физического адреса 0x7c00; затем переходит на адрес и исполняет загруженный код. Этот код называется бутлоадером.

Бутлоадер загружает ядро по физическому адресу 0x100000. Этот адрес используется как стартовый во всех больших ядрах на x86-системах.

Все x86-процессоры начинают работу в простом 16-битном режиме, называющимся реальным режимом. Бутлоадер GRUB переключает режим в 32-битный защищённый режим, устанавливая нижний бит регистра CR0 в 1. Таким образом, ядро загружается в 32-битном защищённом режиме.

Заметьте, что в случае с ядром Linux GRUB видит протоколы загрузки Linux и загружает ядро в реальном режиме. Ядро самостоятельно переключается в защищённый режим.

Что нам нужно?

• x86-компьютер;
• Linux;
• ассемблер NASM;
• gcc;
• ld (GNU Linker);
• grub;

Исходники можно найти на GitHub.

Задаём точку входа на ассемблере

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

Как же нам сделать так, чтобы этот код обязательно был именно исходной точкой?

Мы будем использовать скрипт-линковщик, который соединяет объектные файлы для создания конечного исполняемого файла. В этом скрипте мы явно укажем, что хотим загрузить данные по адресу 0x100000.

Вот код на ассемблере:

Первая инструкция, bits 32, не является x86-ассемблерной инструкцией. Это директива ассемблеру NASM, задающая генерацию кода для процессора, работающего в 32-битном режиме. В нашем случае это не обязательно, но вообще полезно.

Со второй строки начинается секция с кодом.

global — это ещё одна директива NASM, делающая символы исходного кода глобальными. Таким образом, линковщик знает, где находится символ start — наша точка входа.

kmain — это функция, которая будет определена в файле kernel.c. extern значит, что функция объявлена где-то в другом месте.

Затем идёт функция start, вызывающая функцию kmain и останавливающая процессор инструкцией hlt. Именно поэтому мы заранее отключаем прерывания инструкцией cli.

В идеале нам нужно выделить немного памяти и указать на неё указателем стека (esp). Однако, похоже, что GRUB уже сделал это за нас. Тем не менее, вы всё равно выделим немного места в секции BSS и переместим на её начало указатель стека. Мы используем инструкцию resb, которая резервирует указанное число байт. Сразу перед вызовом kmain указатель стека (esp) устанавливается на нужное место инструкцией mov.

Ядро на Си

В kernel.asm мы совершили вызов функции kmain(). Таким образом, наш “сишный” код должен начать исполнение с kmain():

Всё, что сделает наше ядро — очистит экран и выведет строку “my first kernel”.

Сперва мы создаём указатель vidptr, который указывает на адрес 0xb8000. С этого адреса в защищённом режиме начинается “видеопамять”. Для вывода текста на экран мы резервируем 25 строк по 80 ASCII-символов, начиная с 0xb8000.

Каждый символ отображается не привычными 8 битами, а 16. В первом байте хранится сам символ, а во втором — attribute-byte. Он описывает форматирование символа, например, его цвет.

Для вывода символа s зелёного цвета на чёрном фоне мы запишем этот символ в первый байт и значение 0x02 во второй. 0 означает чёрный фон, 2 — зелёный цвет текста.

Вот таблица цветов:

В нашем ядре мы будем использовать светло-серый текст на чёрном фоне, поэтому наш байт-атрибут будет иметь значение 0x07.

В первом цикле программа выводит пустой символ по всей зоне 80×25. Это очистит экран. В следующем цикле в “видеопамять” записываются символы из нуль-терминированной строки “my first kernel” с байтом-атрибутом, равным 0x07. Это выведет строку на экран.

Связующая часть

Мы должны собрать kernel.asm в объектный файл, используя NASM; затем при помощи GCC скомпилировать kernel.c в ещё один объектный файл. Затем их нужно присоединить к исполняемому загрузочному ядру.

Для этого мы будем использовать связывающий скрипт, который передаётся ld в качестве аргумента.

Сперва мы зададим формат вывода как 32-битный Executable and Linkable Format (ELF). ELF — это стандарный формат бинарных файлов Unix-систем архитектуры x86. ENTRY принимает один аргумент, определяющий имя символа, являющегося точкой входа. SECTIONS — это самая важная часть. В ней определяется разметка нашего исполняемого файла. Мы определяем, как должны соединяться разные секции и где их разместить.

В скобках после SECTIONS точка (.) отображает счётчик положения, по умолчанию равный 0x0. Его можно изменить, что мы и делаем.

Смотрим на следующую строку: .text : { *(.text) }. Звёздочка (*) — это специальный символ, совпадающий с любым именем файла. Выражение *(.text) означает все секции .text из всех входных файлов.

Таким образом, линковщик соединяет все секции кода объектных файлов в одну секцию исполняемого файла по адресу в счётчике положения (0x100000). После этого значение счётчика станет равным 0x100000 + размер полученной секции.

Аналогично всё происходит и с другим секциями.

Grub и Multiboot

Теперь все файлы готовы к созданию ядра. Но остался ещё один шаг.

Существует стандарт загрузки x86-ядер с использованием бутлоадера, называющийся Multiboot specification. GRUB загрузит наше ядро, только если оно удовлетворяет этим спецификациям.

Следуя им, ядро должно содержать заголовок в своих первых 8 килобайтах. Кроме того, этот заголовок должен содержать 3 поля, являющихся 4 байтами:

• магическое поле: содержит магическое число 0x1BADB002 для идентификации ядра.
• поле flags: нам оно не нужно, установим в ноль.
• поле checksum: если сложить его с предыдущими двумя, должен получиться ноль.

Наш kernel.asm станет таким:

Строим ядро

Теперь мы создадим объектные файлы из kernel.asm и kernel.c и свяжем их, используя наш скрипт.

Эта строка запустит ассемблер для создания объектного файла kasm.o в формате ELF-32.

Опция “-c” гарантирует, что после компиляции не произойдёт скрытого линкования.

Это запустит линковщик с нашим скриптом и создаст исполняемый файл, называющийся kernel.

Настраиваем grub и запускаем ядро

GRUB требует, чтобы имя ядра удовлетворяло шаблону kernel-<version>. Поэтому переименуйте ядро. Своё я назвал kernel-701.

Теперь поместите его в директорию /boot. Для этого понадобятся права суперпользователя.

В конфигурационном файле GRUB grub.cfg добавьте следующее:

Не забудьте убрать директиву hiddenmenu, если она есть.

Перезагрузите компьютер, и вы увидите список ядер с вашим в том числе. Выберите его, и вы увидите:

Это ваше ядро! В следующей части добавим систему ввода / вывода.

P.S.

• Для любых фокусов с ядром лучше использовать виртуальную машину.
• Для запуска ядра в grub2 конфиг должен выглядеть так:menuentry 'kernel 7001' {tset root='hd0,msdos1'tmultiboot /boot/kernel-7001 ro}
• если вы хотите использовать эмулятор qemu, используйте:qemu-system-i386 -kernel kernel

Даже в идеальных программах есть ошибки.

Столкнувшись с этими трудностями, Саймон Пейтон-Джонс предложил вот такой выход:

“Я думаю, будет довольно продуктивно сразу обозначить, что в программе обязательно должно или не должно произойти. Например, “это дерево всегда должно быть сбалансировано”. Или “эта функция всегда должна возвращать число больше нуля”. Может быть, в будущем найдется более простой способ гарантировать правильную работу всей программы, но пока что его нет”.

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

Это основной тезис практических доказательств. И кстати: хорошие программисты сразу пытаются увериться в том, что все будет всегда работать как надо, но в одном они порой промахиваются. Они не делятся своими рассуждениями с другими. А ведь доказательство должно пройти проверку не только его создателем — важно проверить, верно ли оно, пересказав свои мысли кому-то еще.

Кстати, вы уже могли слышать этот тезис: некоторые программисты ставят на стол фигурку, игрушку — любой предмет, с которым можно обсудить проблему. Именно в ходе объяснения проблемы кому-то другому мы чаще всего и видим все выходы и недочеты. Поэтому не бойтесь выглядеть глупо и не стесняйтесь обсуждать с кем-либо свои идеи.

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

Вот этот код может уверенно заявить о себе: здесь не могут возникнуть условия гонки (race conditions) и дедлоки. Обратите внимание на то, как именно программист решил эту проблему:

Об условиях Коффмана можно почитать здесь.

Можно сделать и проще. Например, как говорит Кен Томпсон: “У моего кода есть одна отличительная черта: он простой, отрывистый и короткий. Так его может прочитать любой человек”.

Так что этот пример на самом деле можно улучшить: например, автоматизировать разблокировки с помощью макроса, использовать язык или библиотеку, поддерживающие более высокоуровневое управление потоками.

В этом примере программист решил, что для работы его кода важно, чтобы в каждый момент времени был открыт только один клапан. Вся логика находится в одном месте, а для будущих программистов предусмотрены комментарии, объясняющие, почему все сделано именно так.

Конечно, и этот пример не совершенен. Что будет делать hardwareOpen() при возникновении ошибки? Понимание того, какие вызовы происходят в каждом из случаев, обязательно при написании кода, гарантирующего отсутствие определенных ошибок.

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

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

Немного исходников из этой статьи (примеры написаны на M4, довольно редком языке).

Для тестов использовался древний GCC 4.2.1. Если новые версии ведут себя по-другому, то обязательно сообщите об этом нам! Будьте осторожны: не все предложенные оптимизации корректны.

Итак, на каждый вопрос есть три варианта ответа: «GCC сделает это», «GCC не может так сделать», «Оптимизация неверна». Постарайтесь отвечать на вопросы самостоятельно.

1. Указатели на функцию

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

Этот приём заключается в следующем. Сперва нужно задать тип “указатель на функцию, возвращающую что-то” и использовать его для объявления переменной. Рассмотрим простой пример. Сначала я задаю тип PFC (Pointer to a Function returning a Character):

Затем использую его для объявления переменной z:

Определяю функцию a():

Адрес функции теперь хранится в z:

Заметим, что вам не нужен оператор & ("address-of"); компилятор знает, что a должна быть адресом функции. Так происходит из-за того, что с функцией можно произвести лишь две операции: 1) вызвать её или 2) взять её адрес. Поскольку вызова функции не происходит (отсутствуют скобки), остаётся лишь вариант с получением адреса, который помещается в z.

Чтобы вызвать функцию, адрес которой находится в z, просто добавьте скобки:

2. Списки аргументов переменной длины

Обычно вы объявляете функцию, которая принимает фиксированное число аргументов. Тем не менее, можно написать функцию, которая принимает любое их количество. Стандартная функция printf() тому доказательство. Разумеется, вы можете сами написать подобную функцию. Вот пример:

Первый аргумент, arg_count — это целое, в котором хранится реальное число аргументов, следующих за ним в списке переменных, указанном как три точки.

С переменными аргументами работают несколько встроенных функций и макросов: va_list, va_start, va_arg и va_end (они определены в stdarg.h).

Сперва вам нужно объявить указатель на список аргументов:

Затем установите argp в первый аргумент переменной части. Это первый аргумент после последнего фиксированного (в нашем случае arg_count):

Теперь извлекаем каждую переменную по очереди, используя va_arg:

Заметим, что вам нужно знать тип аргумента заранее (в нашем случае int) и число аргументов (у нас задаётся фиксированным arg_count).

Наконец, нужно убраться при помощи va_end:

3. Проверка и установка отдельных битов

Битовые операции иногда воспринимаются как некий сорт тёмной магии, используемой продвинутыми программистами. Да, работа с битами напрямую может быть весьма непонятной, но понимание этого процесса может вам пригодиться.

Обсудим, зачем это вообще нужно. Программы часто используют переменные-флаги для хранения булевых величин. У вас в коде вполне могут встречаться такие переменные:

Если они как-то связаны, как в примере выше (они все описывают состояние движения), то зачастую бывает удобнее хранить их в одной “переменной состояния” и использовать каждый бит для задания того или иного состояния:

Тогда вы сможете использовать битовые операции для задания или обнуления отдельных битов:

Преимуществом является то, что вся информация хранится в одном месте, и очевидно, что вы работаете с одной логической сущностью.

В архиве с кодом, который будет дан в конце статьи, есть пример работы с битами.

Чтобы установить заданный бит переменной value (в диапазоне от 0 до 31), используйте такое выражение:

Для очистки бита используйте:

А для получения значения бита:

4. Ленивые логические операторы

Логические операторы Си, && (“и”) и || (“или”), позволяют вам составлять цепочки условий в тех случаях, когда действие должно выполняться при выполнении всех условий (&&) или только одного (||). Но в Си также есть операторы & и |. Очень важно понимать разницу между ними. Если вкратце, двухсимвольные операторы (&& и ||) называются “ленивыми” операторами. Если они используются между двумя выражениями, то второе будет выполнено, только если первое оказалось верным, иначе оно пропускается. Рассмотрим пример:

Тест (int)f && feof(f) должен вернуть истинный результат, когда будет достигнут конец файла f. Сперва тест вычисляет f; она будет равна нулю (ложное значение), если файл не был открыт. Это ошибка, поэтому попытка чтения файла не увенчается успехом. Однако, поскольку первая часть теста провалена, вторая не будет обработана, и feof() не будет запущена. Этот пример демонстрирует корректное использование ленивого оператора. Теперь посмотрите на этот код:

В этом случае используется оператор &, а не &&. Оператор & — это инструкция для выполнения обоих выражений при любых условиях. Поэтому, даже если первая часть теста провалится, вторая будет выполнена. Это может привести к различным ошибкам.

5. Тернарные операторы

Операция называется тернарной. когда принимает три операнда. В Си тернарный оператор ? : можно использовать для сокращённой записи тестов if..else. Общий синтаксис выглядит так:

Пусть у нас есть две целых переменных, t and items. Мы можем использовать if..else для проверки значения items и присваивания её значения переменной t таким образом:

Используя тернарный оператор, эту запись можно сократить до одной строки:

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

Рассмотрим ещё один пример. Этот код выводит первую строку, когда у нас один предмет, и вторую, когда их несколько:

Это можно переписать так:

6. Стек

Стек — это LIFO-хранилище. Вы можете использовать адресную арифметику для добавления элементов в стек или извлечения их из него. Часто под стеком подразумевается структура, используемая Си для хранения локальных переменных функции. Но на самом деле стек — это общий тип структуры данных, которым вы спокойно можете пользоваться.

Код ниже задаёт очень маленький стек: массив _stack из двух целых. Помните, что при тестировании всегда лучше использовать небольшие числа. Если код содержит ошибки, найти их при работе с массивом из 2 элементов будет проще, чем если их будет 100. Также объявляется указатель на стек _sp и устанавливается в основание стека _stack:

Теперь определим функцию push(), которая помещает целое в стек. Она возвращает новое число элементов в стеке или -1, если стек полон:

Для получения элементов стека нужна функция pop(). Она возвращает новое число элементов в стеке или -1, если он пуст:

А вот пример, демонстрирующий работу со стеком:

7. Копирование данных

Вот три способа копирования данных. Первый использует стандартную функцию memcpy(), которая копирует n байт из src в dst:

Теперь посмотрим на самодельную альтернативу memcpy(). Она может быть полезной, если копируемые данные нужно как-то обработать:

И наконец, функция, использующая 32-битные целые для ускорения копирования. Помните, что скорость в конечном итоге зависит от оптимизации компилятора. В этом примере предполагается, что счётчик данных n кратен 4 из-за работы с 4-байтовыми указателями:

Примеры можно найти в архиве ниже.

8. Использование заголовочных файлов

Си использует заголовочные файлы (.h), которые могут содержать объявления функций или констант. Заголовочный файл можно импортировать в код двумя способами: если файл предоставляется компилятором, используйте #include <string.h>, а если файл написан вами — #include "mystring.h". В сложных программах есть риск того, что вы можете подключить один и тот же заголовочный файл несколько раз.

Предположим, что у нас есть простой заголовочный файл, header1.h, содержащий следующие определения:

Затем создадим другой файл header2.h, содержащий это:

Добавим в нашу программу, main.c, это:

При компиляции программы мы получим ошибку компиляции, потому что T_SIZE будет объявлена дважды (её определение в header1 подключено к двум разным файлам). Мы должны подключить header1 к header2 для того, чтобы header2 компилировался в тех случаях, когда header1 не используется. И как это исправить? Можно написать макрос для header1:

Эта проблема настолько распространена, что многие IDE делают это за вас. Тем не менее, если вы будете делать это вручную, делайте это осторожно.

9. Скобки: нужны ли они?

Вот несколько простых правил:

1. Скобки нужно использовать для изменения порядка выполнения операторов. Например, 3 * (4 + 3) — не то же самое, что 3 * 4 + 3 .
2. Скобки можно использовать для улучшения читаемости. Здесь они, очевидно, не нужны:t = items > 0 ? items : -items;Приоритет оператора || ниже, чем < и >. Однако, в этом случае скобки точно не будут лишними:(x > 0) || (x < 100 & y > 10) || (y < 0)
3. Скобки стоит использовать в макросах:#define MYCONST (4 + 3)Вы не знаете, где будете использовать эту константу, поэтому скобки нужны. Рассмотрим такой случай применения:3 * MYCONSTБез скобок результат получился бы неверным из-за порядка выполнения операторов.

Но в одном месте скобки точно не нужны: в выражении после return. Например, это…

…выполнится так же, как это:

10. Массивы как адреса

Программисты, которые учат Си после какого-то другого языка, часто удивляются, когда Си работает с массивами как с адресами и наоборот. Массив — это контейнер фиксированного размера, а адрес — это число, связанное с местом в памяти; разве они связаны?

Выходит, что да.

Си прав: массив — это просто адрес базы в блоке памяти, а форма записи массива, например, в Java или JavaScript — просто синтаксический сахар.

Присмотритесь к этому коду:

Первый цикл здесь копирует адрес каждого элемента массива в сам массив:

На каждой итерации адрес увеличивается на i. Поэтому адрес переменной _x будет первым элементом, а каждый следующий адрес — адресом  _x плюс 1. Когда мы прибавляем 1 к адресу массива, компилятор Си вычисляет подходящий сдвиг в зависимости от типа данных (в нашем случае 4 байта для массива целых).

Второй цикл выводит значения, хранящиеся в массиве, сперва выводя адрес элемента _x + i, затем значение элемента через привычный вид массива _x[i], а потом содержимое массива с использованием адресной нотации (где оператор * возвращает содержимое памяти по адресу в скобках): *(_x + i). Во всех случаях значения будут одинаковыми. Это наглядно демонстрирует, что массив и адрес — это одно и то же.

Обратите внимание, что для получения адреса массива вам не нужен оператор &, поскольку компилятор считает, что массив и есть адрес.

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

Разработка ведётся на Linux, весь исходный код доступен на GitHub. В первых двух статьях автор использует ассемблер для написания ядра, после этого — Rust.

Статьи написаны простым, понятным даже начинающим программистам языком, все термины либо объясняются в статье, либо снабжены ссылками на другие Интернет-ресурсы.

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

Итак, вот список статей:

1. Пишем простое x86-ядро.
2. Переход в 64-битный режим.
3. Настройка Rust.
4. Настройка интерфейса вывода.
5. Аллокатор фреймов.
6. Таблицы страниц.
7. «Ремап» ядра.
8. Куча.
9. Обработка исключений.
10. Сообщения об исключениях.
11. Возврат из исключений.
12. Двойные ошибки (ошибки исключений).

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

Введение

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

Я расскажу о следующих побитовых операторах:

• | (Побитовое ИЛИ (OR)),
• & (Побитовое И (AND)),
• ^ (Исключающее ИЛИ (XOR)),
• ~ (Побитовое отрицание (NOT)),
• << (Побитовый сдвиг влево),
• >> (Побитовый сдвиг вправо).

Битовые операции изучаются в дискретной математике, а также лежат в основе цифровой техники, так как на них основана логика работы логических вентилей — базовых элементов цифровых схем. В дискретной математике, как и в цифровой технике, для описания их работы используются таблицы истинности. Таблицы истинности, как мне кажется, значительно облегчают понимание битовых операций, поэтому я приведу их в этой статье. Их, тем не менее, почти не используют в объяснениях побитовых операторов высокоуровневых языков программирования.

О битовых операторах вам также необходимо знать:

1. Некоторые побитовые операторы похожи на операторы, с которыми вы наверняка знакомы (&&, ||). Это потому, что они на самом деле в чем-то похожи. Тем не менее, путать их ни в коем случае нельзя.
2. Большинство битовых операций являются операциями составного присваивания.

Побитовое ИЛИ (OR)

Побитовое ИЛИ действует эквивалентно логическому ИЛИ, но примененному к каждой паре битов двоичного числа. Двоичный разряд результата равен 0 только тогда, когда оба соответствующих бита в равны 0. Во всех других случаях двоичный результат равен 1. То есть, если у нас есть следующая таблица истинности:

38 | 53 будет таким:

В итоге мы получаем 1101112 , или 5510 .

Побитовое И (AND)

Побитовое И — это что-то вроде операции, противоположной побитовому ИЛИ. Двоичный разряд результата равен 1 только тогда, когда оба соответствующих бита операндов равны 1. Другими словами, можно сказать, двоичные разряды получившегося числа — это результат умножения соответствующих битов операнда: 1х1 = 1, 1х0 = 0. Побитовому И соответствует следующая таблица истинности:

Пример работы побитового И на выражении 38 & 53:

Как результат, получаем 1001002 , или 3610 .

С помощью побитового оператора И можно проверить, является ли число четным или нечетным. Для целых чисел, если младший бит равен 1, то число нечетное (основываясь на преобразовании двоичных чисел в десятичные). Зачем это нужно, если можно просто использовать %2? На моем компьютере, например, &1 выполняется на 66% быстрее. Довольно неплохое повышение производительности, скажу я вам.

Исключающее ИЛИ (XOR)

Разница между исключающим ИЛИ и побитовым ИЛИ в том, что для получения 1 только один бит в паре может быть 1:

Например, выражение 138^43 будет равно…

… 101000012 , или 16010

С помощью ^ можно поменять значения двух переменных (имеющих одинаковый тип данных) без использования временной переменной.

Также с помощью исключающего ИЛИ можно зашифровать текст. Для этого нужно лишь итерировать через все символы, и ^ их с символом-ключом. Для более сложного шифра можно использовать строку символов:

Исключающее ИЛИ не самый надежный способ шифровки, но его можно сделать частью шифровального алгоритма.

Побитовое отрицание (NOT)

Побитовое отрицание инвертирует все биты операнда. То есть, то что было 1 станет 0, и наоборот.

Вот, например, операция ~52:

Результатом будет 20310

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

Дополнительный код

Здесь мне стоит рассказать вам немного о способе представления отрицательных целых чисел в ЭВМ, а именно о дополнительном коде (two’s complement). Не вдаваясь в подробности, он нужен для облегчения арифметики двоичных чисел.

Главное, что вам нужно знать о числах, записанных в дополнительном коде — это то, что старший разряд является знаковым. Если он равен 0, то число положительное и совпадает с представлением этого числа в прямом коде, а если 1 — то оно отрицательное. То есть, 10111101 — отрицательное число, а 01000011 — положительное.

Чтобы преобразовать отрицательное число в дополнительный код, нужно инвертировать все биты числа (то есть, по сути, использовать побитовое отрицание) и добавить к результату 1.

Например, если мы имеем 109:

Представленным выше методом мы получаем -109 в дополнительном коде.
Только что было представлено очень упрощенное объяснение дополнительного кода, и я настоятельно советую вам детальнее изучить эту тему.

Побитовый сдвиг влево

Побитовые сдвиги немного отличаются от рассмотренных ранее битовых операций. Побитовый сдвиг влево сдвигает биты своего операнда на N количество битов влево, начиная с младшего бита. Пустые места после сдвига заполняются нулями. Происходит это так:

Интересной особенностью сдвига влево на N позиций является то, что это эквивалентно умножению числа на 2N. Таким образом, 43<<4 == 43*Math.pow(2,4). Использование сдвига влево вместо Math.pow обеспечит неплохой прирост производительности.

Побитовый сдвиг вправо

Как вы могли догадаться, >> сдвигает биты операнда на обозначенное количество битов вправо.

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

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

Вывод

Итак, теперь вы знаете больше о битовых операциях и не боитесь их. Могу предположить, что вы не будете использовать >>1 при каждом делении на 2. Тем не менее, битовые операции неплохо иметь в своем арсенале, и теперь вы сможете воспользоваться ими в случае надобности или же ответить на каверзный вопрос на собеседовании.

Да, да, я знаю. И все-таки, зачем? Ну, например, это хороший учебный пример. Но главная причина — потому что могу.

Самоизменяющиеся программы сами по себе не очень полезны. Они сложны в отладке, платформо-зависимы, код ужасно нечитаем, если вы, конечно, не эксперт в ассемблере. Единственное хорошее применение им — скрытие вредоносного кода. Но мой интерес чисто академический, поэтому ничего такого тут не будет.

Дисклеймер: в этой статье очень много ассемблерного кода под x86_64, в котором я не эксперт. Многому я научился в процессе написания статьи, поэтому возможно (почти наверняка) в тексте есть ошибки. Если вы найдете ошибку, пришлите мне е-мейл, чтобы я мог ее исправить.

Первый шаг к написанию самоизменяющейся программы — получение возможности изменять код во время выполнения. Когда-то давно программисты поняли, что это плохая идея и с тех пор добавили защиту на изменение выполняемого кода. Для начала разберемся, где хранятся инструкции, когда программа выполняется. Перед выполнением загрузчик помещает всю программу целиком в память. Затем программа запускается в виртуальном адресном пространстве, управляемом ядром ОС. Адресное пространство разбито на различные области, как показано на рисунке.

В нашем случае, нас интересует только область инструкций (text segment). Именно туда загружаются команды процессора. Адресное пространство размечено на страницы, которыми и управляет ядро. Страницы соответствуют физической памяти компьютера. Ядро также управляет правами доступа к страницам. По умолчанию область инструкций можно читать и выполнять оттуда команды. Писать в нее нельзя. Для того, чтобы изменять инструкции в этой области памяти, мы должны изменить права доступа.

Изменить права доступа можно функцией mprotect() (man mprotect). Единственная сложность в том, что указатель, передаваемый в функцию, должен быть выровнен по началу страницы памяти. Вот функция, которая по данному ей указателю находит адрес начала страницы и устанавливает права на чтение, запись и выполнение на ней.

Теперь, если мы передадим функции указатель, она сделает страницу памяти с этим адресом перезаписываемой. Важно заметить, что некоторые ОС могут отказаться устанавливать права доступа на запись в область инструкций. Я использую Linux, который позволяет сделать это. Если вы используете другую систему, убедитесь, что проверяете значение, возвращенное mprotect(). В примера дальше по тексту предполагается, что код, который мы будем менять, находится целиком на одной странице памяти. Для длинных участков кода это может не сработать.

Итак, мы можем писать в область инструкций. Следующий вопрос — что мы будет туда записывать?

Давайте начнем с простого. Допусти, у меня есть такая функция:

foo() создает локальную переменную i и присваивает ей значение 0, затем инкрементирует это значение и выводит в stdout. Посмотрим, сможем ли мы поменять число, которое прибавляется к i.

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

Теперь, когда у нас есть программа, использующая foo(), мы можем ее скомпилировать.

И вот тут начинается самое интересное. Нам надо дизассемблировать бинарник, созданный gcc и посмотреть, какие инструкции соответствуют foo(). Мы можем это сделать с помощью утилиты objdump.

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

Если вы раньше не сталкивались с ассемблерным кодом под x86_64, вы можете потеряться. Вот что здесь происходит: мы смещаем стек на 4 байта (размер int на моей машине) для того, чтобы освободить место для переменной i. Затем инициализируем эти 4 байта нулями и прибавляем 1 к этому значению. Все, что после адреса 40054b — это подготовка к вызову функции printf().

Итак, если мы хотим изменить число, прибавляемое к i, надо поменять вот эту инструкцию:

Прежде чем продолжать, давайте посмотрим, из чего состоит инструкция.

Рассмотрим саму инструкцию и ее операнды:

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

Здесь возникают сложности. Дело в том, что инструкции для x86_64 могут иметь переменную длину, их разбор вручную сложен и занимает много времени. Задачу облегчают различные источники документации. На x86ref.net есть отличная документация. Для смелых есть также документация Intel в виде PDF на 3000 страниц.

В нашем случае эти байты означают следующее:

В документации есть полезная таблица, в которой объясняется значение каждого ModR/M байта. Также эта таблица есть в руководстве, упомянутом выше, таблица 2-2 в разделе 2-5 тома 2A (455 страница PDF-файла).

Теперь мы знаем какой байт в какой инструкции небходимо поменять, осталось понять, как это сделать.

Итак, мы хотим поменять байт 01 в инструкции addl $0x1,-0x4(%rbp).

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

1. Посмотреть на дизассемблированный код и посчитать число байт между началом функции и интересующим байтом.
2. Написать функцию, которая последовательно напечатает инструкции foo() со смещением относительно начала функции

Почему бы не сделать и то, и другое?

Посмотрим сначала на дизассемблированную функцию:

Функция начинается с адреса 400538, а байт, который нас интересует — на 400550 (400547 + 3), следовательно, смещение будет равно 400550 – 400538 = 18.

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

Заметьте, что для того, чтобы определить длину функции foo(), я добавил пустую функцию bar() после foo(). Теперь, когда сразу после foo() расположена bar(), мы можем определить длину foo() вычитанием адреса bar() из адреса foo().

Вот что выводит эта программа:

Наш байт 0x1 расположен по адресу 0x40057e. Можем убедиться, что смещение действительно 18.

Примечание переводчика: На текущей версии gcc этот код требует для компиляции специальных опций. Поскольку в редакции использовалась система, отличная от той, что у автора статьи, мы приводим код, который работает у нас: http://ideone.com/Ufvzba

Теперь все готово для изменения кода во время выполнения. Имея указатель на foo() мы можем получить указатель типа unsigned char на байт, которым хотим поменять.

Если мы все сделали правильно, эта строка поменяет аргумент команды addl на 0x2A или 42. Теперь, когда мы вызовем foo(), она напечатает 42 вместо 1.

Теперь соберем все вместе:

Скомпилируем это:

И запустим:

Ура! Первый вызов foo() выводит 1, как и указано в коде. Затем, после того, как мы его изменили, она выводит 42.

Теперь у нас есть самоизменяющаяся программа! Однако, она довольно скучная. Все что мы сделали — поменяли 1 на 42. Было бы круто, если бы мы смогли заставить foo() делать что-то совсем другое. Например вызывать шелл код с помощью exec().

Итак, как мы можем заставить foo() вызывать шелл код? Самый простой способ — использовать системный вызов execve. Но это уже сложнее, чем просто замена байта.

Если мы хотим подменить foo() системным вызовом, нам потребуются код для этого вызова. К счастью для нас, специалисты по безопасности любят использовать машинный код для запуска шелла, так что мы може этим воспользоваться. Поиск по «x86_64 shellcode» дал вот такой результат:

Я взял этот код отсюда и немного изменил:

• Я добавил xor %rax, %rax для того, чтобы обнулить %rax. Иначе он мог вызвать сегфолт.
• Я заменил значение $0x68732f6e69622f2f на $0x68732f6e69622f00. Таким образом я избавился от сдвига и сохранил размер кода в пределах 30 байт. Обычно шелл код вроде этого инжектируется через переполнение буфера или другими способами атаки. Строки в C заканчиваются нулевым байтом. Поэтому большинство функций для работы со строками из стандартной библиотеки возвращают результат когда встречают нулевой байт. Специалисты по безопасности избегают использования нуль-терминатора по этой причине, но в нашем случае в этом нет ничего страшного, поэтому мы заменяем 0x2f на 0x00 и избавляемся от команды сдвига. См. оригинал кода по ссылке.

Прежде чем продолжать, давайте разберемся, как работает вышеприведенный код. Сначала рассмотрим системный вызов. Системный вызов — это вызов функции ядра ОС с запросом о каком-либо действии. Это может быть что-то, на что есть права доступа только у ядра, поэтому мы к нему и обращаемся. В нашем случае системный вызов execve говорит ядру, что мы хотим запустить другой процесс и заменить адресное пространства нашего процесса адресным пространством нового. Это значит, что при успешном вызове execve наш процесс завершится.

Для того, чтобы вызвать системную функцию на x86_64, нам необходимо его подготовить, поместив в правильные регистры определенные значения, а затем, собственно, вызвать системную функцию. Значения и регистры зависят от конкретной системы. Я пишу под Linux, поэтому привожу документацию для execve в Linux.

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

Полный список системных вызовов можно найти здесь.

Если вы знакомы с прототипом execve() в C (я привел его ниже для справки), вы заметите, насколько системный вызов в C похож на вызов функции.

Стоит также заметить, что вызов системной процедуры отличается в x86 и x86_64. Отдельной инструкции для системного вызова на x86 вообще нет, вместо этого он производится вызовом прерывания. Более того, на Linux, номер системного вызова execve разный для x86 и x86_64. (11 на x86; 59 на x86_64).

Теперь, когда мы знаем, как вызвать системную функцию, рассмотрим подробно каждый шаг нашего кода:

Ух! Тут много всего. Но зато теперь мы можем заменить foo() на вызов шелла.

Теперь, вместо того, чтобы изменить один байт в теле функции foo(), нам надо поменять ее полностью. Это можно сделать с помощью memcpy(). Имея указатель на начало foo() и указатель на шелл код, мы можем скопировать шелл код на место foo() так:

Нужно быть осторожным, чтобы не зайти за пределы foo(). В нашем случае foo() занимает 41 байт, а шелл код — 29 байт, так что все в порядке. Заметьте, что наш шелл код это строка, и в ее конце стоит нулевой байт. Так как мы хотим скопировать только код, то мы вычитаем единицу из sizeof(shellcode) когда передаем аргумент в memcpy()

Отлично! Теперь соберем все вместе:

И скомпилируем:

Пора скрестить пальцы и запустить.

Вот! Теперь у нас есть самоизменяющаяся программа на C.

Перевод статьи «Writing a Self-Mutating x86_64 C Program»