Системное программирование *

Я очень люблю видеоуроки. Почему-то информацию с текста лично я воспринимаю весьма и весьма плохо. А есть вещи, в которых информации на бумаге не так много. Возьмём, к примеру, уроки игры на балалайке: на YouTube есть замечательные разборы, как играть ту или иную мелодию (кому интересно, ищем по имени «Сергей Воронцов»), но повторить и заучить последовательность с потокового видео сложно. Надо или записывать на бумагу (судя по комментариям под уроками, некоторые так и делают), или докупать дополнительные материалы (но я не жадный, а домовитый).



В общем, в моём балалаечном случае, да и при многих других, надо идти так: посмотрел фрагмент, поставил на паузу, повторил несколько раз за автором, продолжил просмотр. Если что-то непонятно — отмотал назад, посмотрел повнимательнее. Но как это всё мотать, если руки заняты? Тем более, в моём случае они заняты пусть не огромным баяном, но всё-таки какой-никакой, а балалайкой. Значит, работать надо при помощи ног.

Первая часть
Вторая часть

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

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

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

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

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

Этот цикл статей опубликован выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи лежат в этой ветке.

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

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

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

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

В статье на примере описания реализации алгоритма шифрования по ГОСТ 28147–89, построенного на сети Фейстеля, показаны возможности двухъядерного процессора BE-T1000 (aka Байкал-Т1) и проведены сравнительные испытания реализации алгоритма с помощью векторных вычислений с сопроцессором SIMD и без него. Здесь будет проведена демонстрация применение SIMD-блока для задачи шифрования по ГОСТ 28147-89, режим ECB.

Эту статью в прошлом году написал для журнала "Электронные Компоненты" Алексей Колотников, ведущий программист компании "Байкал Электроникс". И поскольку читателей у этого журнала не очень много, а статья полезная для тех, кто профессионально занимается криптографией, я с позволения автора и его небольшими дополнениями публикую её здесь.

TL;DR. В этой статье мы исследуем защитные схемы (hardening schemes), которые из коробки работают в пяти популярных дистрибутивах Linux. Для каждого мы взяли конфигурацию ядра по умолчанию, загрузили все пакеты и проанализировали схемы защиты во вложенных двоичных файлах. Рассматриваются дистрибутивы OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 и 7, а также Ubuntu 14.04, 12.04 и 18.04 LTS.

Результаты подтверждают, что даже основные схемы, такие как стековые канарейки и независимый от позиции код, ещё не всеми используются. Ситуация ещё хуже у компиляторов, когда речь идёт о защите от уязвимостей вроде столкновения стека (stack clash), которые попали в центр внимания в январе после публикации информации об уязвимостях в systemd. Но не всё так безнадёжно. В значительной части бинарников реализованы базовые методы защиты, и их число растёт от версии к версии.

Проверка показала, что наибольшее количество методов защиты реализовано в Ubuntu 18.04 на уровне ОС и приложений, затем следует Debian 9. С другой стороны, в OpenSUSE 12.4, CentOS 7 и RHEL 7 тоже реализованы базовые схемы защиты, а защита от столкновения стека применяется ещё шире при гораздо более плотном наборе пакетов по умолчанию.

При разработке аппаратной части комплекса REDD, описанного в этой статье, мы рассматривали различные варианты реализации. PSoC рассматривался, так как для него имеется готовый относительно стандартизованный, пусть и де-факто, вариант переходника USB-I2C. К сожалению, по причинам, описанным в статье про DMA, сделать что-то сложное для данного конкретного комплекса на PSoC не удалось, а простое — экономически нецелесообразно. Оказалось, дешевле взять микросхемы от FTDI. Но пока велись эксперименты с PSOC, вскрылись интересные подробности, которые имеет смысл опубликовать.

Наиболее полный источник информации о жизни создателя TempleOS Терри Дэвиса

Легко заклеймить Терри Дэвиса параноидальным, нарциссическим, душевнобольным и психически нестабильным расистом, 12 лет своей жизни проведшим за созданием бесполезной операционной системы TempleOS, предназначенной для разговоров с богом; но перед тем, как выносить ему свою оценку, нужно сначала составить полное представление о нём. История Терри – это трагическое повествование о том, как психическая болезнь забрала у нас человека, объявившего себя «величайшим из когда-либо живших программистов».

Ранние годы Терри Дэвиса

Терри Дэвис родился 15 декабря 1969 года в г. Вест-Аллис, шт. Висконсин. Но затем в течение жизни переезжал в Орегон, Вашингтон, Мичиган и Аризону. Он родился в большой семье, был седьмым ребёнком из восьми, а отец его был промышленным инженером, работавшим над ракетной системой "Титан" в 70-х и 80-х.

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

Нам предстоит сделать предпоследний шаг в практическом освоении работы с UDB. Сегодня мы будем вести разработку не при помощи автоматизированного UDB Editor, а в полуручном режиме, с использованием Datapath Config Tool. Очень хорошим подспорьем в освоении этого инструмента является документ AN82156 — PSoC 3, PSoC 4, and PSoC 5LP – Designing PSoC Creator Components with UDB Datapaths. Собственно, я сам учился по нему.

Итак, сразу к делу. Писать будем под Linux, на NASM и с использованием QEMU. Установить это легко, так что пропустим этот шаг.

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

Первая часть с функциональными требованиями тут.

Заявленные как языки программирования с прицелом на надежность.

В алфавитном порядке — Active Oberon, Ada, BetterC, IEC 61131-3 ST, Safe-C.

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.33.0. Rust — это язык программирования, который дает возможность каждому создавать надежное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.33.0 вам достаточно выполнить:

$ rustup update stable

Если у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.33.0 можно ознакомиться на GitHub.

Что вошло в стабильную версию 1.33.0

Основные улучшения этого выпуска: значительное расширение возможностей const fn и стабилизация нового Pin API.

Расширение возможностей const fn

const fn теперь умеет гораздо больше, а именно:

• безусловное (irrefutable) сопоставление с образцом (например, const fn foo((x, y): (u8, u8)) { ... })
• let привязки (например, let x = 1;)
• изменяемые let привязки (например, let mut x = 1;)
• выражения присваивания (например x = y) и операторов присваивания (например, x += y), включая присваивание проекциям (например, полю структуры или результату оператора индексирования — x[3] = 42)
• инструкции выражений (expression statements) (например, 3;)

На написание данной статьи меня побудила длинная ветка комментариев (дискуссией это я назвать, к сожалению, не могу) к моей недавней статье “Многообразный мир embedded systems и место Embox в нем”. Меня в нескольких местах упрекнули в том, что я путаю RTOS и Embedded OS, что я назвал LynxOS, QNX и VxWorks не RTOS, хотя на мой взгляд, я такого, конечно, не делал. Автору данных комментариев я несколько раз предложил написать статью, в которой бы он изложил свое видение понятия “операционная система реального времени”, но он по каким-то причинам отказался. Ну что же, я изложу свое видение данного термина, и давайте обсудим, что же может называться RTOS, а что не может. В конце концов, этот вопрос часто задают применительно к Embox.

«В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки» — сообщает нам Википедия. Сами будучи поклонниками Linux, мы регулярно сталкиваемся с вопросом, какими именно инструментами её лучше осуществлять. И хотим поделиться переводом статьи программиста Хонгли Лая, который рекомендует bpftrace. Забегая вперёд, скажу, что заканчивается статья лаконично: «bpftrace — это будущее». Так чем же он так впечатлил коллегу Лая? Развёрнутый ответ под катом.

На Хабре уже писали про перехват системных вызовов с помощью ptrace; Алекса написал про это намного более развёрнутый пост, который я решил перевести.

---

С чего начать

Общение между отлаживаемой программой и отладчиком происходит при помощи сигналов. Это существенно усложняет и без того непростые вещи; ради развлечения можете прочесть раздел BUGS в man ptrace.

Есть как минимум два разных способа начать отладку:

1. ptrace(PTRACE_TRACEME, 0, NULL, NULL) сделает родителя текущего процесса отладчиком для него. Никакого содействия от родителя при этом не требуется; man ненавязчиво советует: «A process probably shouldn't make this request if its parent isn't expecting to trace it.» (Где-нибудь ещё в манах вы видели фразу «probably shouldn't»?) Если у текущего процесса уже был отладчик, то вызов не удастся.
2. ptrace(PTRACE_ATTACH, pid, NULL, NULL) сделает текущий процесс отладчиком для pid. Если у pid уже был отладчик, то вызов не удастся. Отлаживаемому процессу шлётся SIGSTOP, и он не продолжит работу, пока отладчик его не «разморозит».

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

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

Конечно, писать универсальную ОС даже с какими-то фишками никто не собирался. Слоган Embox — “Essential toolbox for embedded development” — подразумевает, что проект нацелен на embedded systems. Однако данное понятие очень широко, к нему относят: интернет вещей (IoT) и роботов, различные малинки (RaPi) и бортовые системы, ардуинки и АСУ-ТП, …. Список, как вы понимаете, можно продолжать очень долго, в нем есть места, где прекрасно живет Linux, а есть места, где Linux избыточен и используются различные маленькие RTOS. В данной статье я хотел бы поговорить об embedded-мире во всем его многообразии, ну и о месте Embox в нем.

Продолжаем рассматривать настройку прерываний от внешних устройств в системе x86.
В части 1 (Эволюция контроллеров прерываний) мы рассмотрели теоретические основы контроллеров прерываний и общие термины, в части 2 (Опции загрузки ядра Linux) посмотрели как на практике ОС осуществляет выбор между контроллерами. В этой части мы рассмотрим как BIOS настраивает роутинг IRQ на контроллеры прерываний в чипсете.

Никакие современные компании по разработке BIOS (AwardBIOS/AMIBIOS/Insyde) не раскрывают исходники своих программ. Но к счастью есть Coreboot — проект по замене проприетарного BIOS на свободное программное обеспечение. В его коде мы и посмотрим, как настраивается роутинг прерываний в чипсете.

Недавно внимание автора привлекла статья на LWN о новом интерфейсе ядра для опроса (polling). В ней обсуждается новый механизм опроса в Linux AIO API (интерфейс для асинхронной работы с файлами), который добавили в ядро версии 4.18. Идея довольно интересная: автор патча предлагает использовать Linux AIO API для работы с сетью.

Но постойте! Ведь Linux AIO был создан для работы с асинхронным вводом-выводом с диска / на диск! Файлы на диске — это не то же самое, что сетевые соединения. Возможно ли вообще использовать Linux AIO API для работы с сетью?

Оказывается, да, возможно! В этой статье объясняется, как использовать сильные стороны Linux AIO API для создания более быстрых и лучших сетевых серверов.

Но давайте начнём с разъяснения, что представляет собой Linux AIO.

Предлагаю вашему вниманию субъективную подборку ржавых новостей за январь. В этой подборке: Rust 1.32, уход Стива Клабника и Ника Камерона, киш от Cloudflare, устройство rust-analyzer и страничной памяти, поиски GUI и async, Oxydyze конференция для встроенщиков.

Rust 1.32

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

• Новый вспомогательный макрос для отладки dbg!;
• По умолчанию убран jemalloc.
• Стабилизированы "единообразные пути" ("uniform paths")

Подробности в переводе новости.

Стив Клабник и Ник Камерон уходят из Mozilla

Печальные новости: Стив Клабник и Ник "nrc" Камерон покидают Мозиллу.