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

Все современные микропроцессоры и микроконтроллеры содержат какие-либо механизмы прерывания. Эти механизмы необходимы для обеспечения «отзывчивости», требуемой многими приложениями. Безусловно, отзывчивость и предсказуемость являются основной целью при использовании ОСРВ, но при этом они противостоят друг другу. Использование прерываний может нарушить целостность реального времени ОС. Эта проблема и ее решение были затронуты в одной из предыдущих статей (#4 и #6). В этой статье мы рассмотрим стратегию обработки прерываний, используемую в Nucleus SE. Во всех случаях прерывания НЕ управляются Nucleus SE: они обрабатываются при возникновении согласно приоритету и векторам обычным способом. Время их выполнения просто «крадется» из доступного времени в коде основного приложения и планировщика. Очевидно, из этого следует, что все обработчики прерывания должны быть простыми, короткими и быстрыми.

Добрый день! Мы в проекте Embox запустили Qt на STM32F7-Discovery и хотели бы об этом рассказать. Ранее, мы уже рассказывали как нам удалось запустить OpenCV.

Qt — это кроссплатформенный фреймворк, который включает в себя не только графические компоненты, но и такие вещи как QtNetwork, набор классов для работы с базами данных, Qt for Automation (в том числе, для реализации IoT) и многое другое. Разработчики команды Qt заранее предусмотрели использование Qt во встроенных системах, поэтому библиотеки довольно хорошо конфигурируются. Однако до недавних пор, мало кто задумывался о портировании Qt на микроконтроллеры, вероятно потому, что такая задача выглядит сложной — Qt большое, MCU маленькие.

Эта статья является частью серии «Fileless Malware». Все остальные части серии:

• Приключения неуловимой малвари, часть I
• Приключения неуловимой малвари, часть II: Скрытные VBA-скрипты
• Приключения неуловимой малвари, часть III: запутанные VBA-скрипты для смеха и прибыли (мы тут)

В последних двух постах (тут и тут) мы говорили о безфайловых, но при этом довольно безобидных методах атаки. Теперь мы готовы, наконец, взяться за настоящую fileless малварь. Сайт для гибридного анализа (hybrid analysis, далее HA) – это ресурс, на который я полагаюсь, чтобы найти этих вредоносных «тварей». Как правило, информации, которую HA предоставляет для каждого образца: системные вызовы, интернет-трафик и т.д. – достаточно, чтобы удовлетворить типичные запросы ИТ-безопасности. Меня неумолимо тянет погрузиться в один из этих сильно запутанных образцов кода, чтобы увидеть, что же на самом деле там происходит.

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



Открыть коробочку с такими платами и быстро взять одну для решения каких-то задач — в порядке вещей. Именно так, недавно я взял очередную плату, прошил уже хорошо отлаженной и проверенной «прошивкой» и… получил неопознанное USB-устройство. Взял другую плату, «прошил» её, там устройство заработало. Тут бы делу и конец, но интересно же, в чём дело. Поэтому, как пришли выходные, я занялся детальным исследованием, почему же она не работает.

В предыдущей части был реализован более-менее работающий контроллер памяти, а точнее — обёртка над IP Core из Quartus, являющаяся переходником на TileLink. Сегодня же в рубрике «Портируем RocketChip на малоизвестную китайскую плату с Циклоном» вы увидите работающую консоль. Процесс несколько затянулся: я уже было думал, что сейчас по-быстрому запущу Linux, и пойдём дальше, но не тут то было. В этой части предлагаю посмотреть на процесс запуска U-Boot, BBL, и робкие попытки Linux kernel инициализироваться. Но консоль есть — U-Boot-овская, и довольно-таки продвинутая, имеющая многое из того, что вы ожидаете от полноценной консоли.

В аппаратной части добавится SD-карта, подключённая по интерфейсу SPI, а также UART. В программной части BootROM будет заменён с xip на sdboot и, собственно, добавлены следующие стадии загрузки (на SD-карте).

В прошлой статье я сказал, что нам пора переходить к потоковым протоколам. Но начав подготовку рассказа о них, я понял, что сам плаваю в одной очень важной теме. Как уже отмечалось, у меня с Линуксом достаточно своеобразные отношения. В общем, я понял, что сам не могу создать с нуля приложение на С++, которое удовлетворяло бы всем принципам программирования для Redd. Можно было бы попросить кого-то сделать это, а затем просто воспользоваться готовым шаблоном, но цикл статей призван научить всех вести разработку под Redd с нуля. Поэтому я попросил своего начальника (большого специалиста по Линуксу), и он разъяснил мне, что за чем нажимать. Затем я чуть переосмыслил его слова и теперь считаю нужным зафиксировать все знания письменно. Это избавит таких, как я, от мучительных раздумий: «Так… Что он сделал – понятно, но как мне это повторить?». В общем, кто работает под Линуксом, можете пробежать следующие два раздела по диагонали. Вряд ли вы найдёте там что-то новое (дальше – найдёте). А остальным я предлагаю на выбор две методики разработки, которые соответствуют декларируемым принципам работы под Redd: низкие трудозатраты на разработку и удалённая отладка.

Я один из разработчиков операционной системы Embox, и в этой статье я расскажу про то, как у меня получилось запустить OpenCV на плате STM32746G.

Если вбить в поисковик что-то вроде "OpenCV on STM32 board", можно найти довольно много тех, кто интересуется использованием этой библиотеки на платах STM32 или других микроконтроллерах.
Есть несколько видео, которые, судя по названию, должны демонстрировать то, что нужно, но обычно (во всех видео, которые я видел) на плате STM32 производилось только получение картинки с камеры и вывод результата на экран, а сама обработка изображения делалась либо на обычном компьютере, либо на платах помощнее (например, Raspberry Pi).

Недавно (10-11 июня) в Москве прошла очередная научно-практическая конференция OSDay. На этот раз конференция проходила в математическом институте им. В.А. Стеклова РАН. Формально она была посвящена инструментам разработки операционных платформ и системного программного обеспечения. Как обычно, темы, затрагиваемые на конференции, не ограничились формально заявленными, а поднятые вопросы рассматривались с разных сторон и обсуждались различные подходы к их решению. Различные взгляды и подходы — это, на мой взгляд, то, что выделяет конференцию среди остальных. Так, например, в конце второго дня конференции, буквально под занавес, Дмитрий Завалишин ( dzavalishin ), один из организаторов, спровоцировал бурную дискуссию, о том, что язык программирования Си вообще-то устарел и разрабатывать (в том числе и операционные системы) нужно, как минимум, на языках с управляемой памятью. Свое видение об этой дискуссии и других интересных мне темах, поднятых на конференции, я изложу в данной статье. Кому интересно прошу под кат.

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

Идея программных таймеров была введена в одной из предыдущих статей. Они являются объектами ядра, предоставляющими задачам простой способ запуска событий по времени, или, чаще всего, способ выполнять действия на регулярной основе. Все детали функционала, связанного со временем (точность, обработка прерываний и т.д.) в Nucleus SE были рассмотрены в предыдущей статье.

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

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

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

Завтрак с Чарльзом Уэзереллом, автором культовой книги «Этюды для программистов», затянулся на четыре часа. В конце-концов официантка попросила нас из ресторана в Пало-Альто, сказав что в ресторан большая очередь, а мы тут с восьми утра заседаем. За это время мы обсудили массу интересных вещий: работу Чарльза в Ливерморской лаборатории и Оракле, объектно-ориентированное и функциональное программирование, компиляторы и языки описания аппаратуры, закладки в процессоры, неэффективность нейронных сетей и незаслуженно забытый Пролог, посещение Чарльзом России, обработку текста конечным автоматом в аппаратном сопроцессоре и создание школьниками видеоигр на ПЛИС.



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

Итак, в прошлой статье мы разработали простейшую процессорную систему, с помощью которой планируем провести тест микросхемы ОЗУ, подключённой к ПЛИС комплекса Redd. Сегодня же мы сделаем для этой аппаратной среды программу на языке С++, а также разберёмся, как эту программу вливать, а главное — отлаживать.

Когда я исследую безопасность ПО, то одним из пунктов проверки является работа с динамическими библиотеками. Атаки типа DLL hijack («подмена dll» или «перехват dll») встречаются очень редко. Скорее всего, это связано с тем, что и разработчики Windows добавляют механизмы безопасности для предотвращения атак, и разработчики софта аккуратнее относятся к безопасности. Но тем интереснее ситуации, когда целевое ПО уязвимо.

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

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



Под катом будет несколько вариантов создания таких библиотек — как в виде кода, так и утилитами.

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

Я прочитал книгу «Но откуда он знает?» Кларка Скотта с детальным описанием простого 8-битного компьютера: начиная с логических вентилей, ОЗУ, транзисторов процессора, заканчивая арифметико-логическим устройством и операциями ввода-вывода. И мне захотелось реализовать всё это в коде.

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

Не так давно на Хабре появилась прекрасная статья Оптимизация сборки мусора в высоконагруженном .NET сервисе. Эта статья очень интересна тем, что авторы, вооружившись теорией сделали ранее невозможное: оптимизировали свое приложение, используя знания о работе GC. И если ранее мы не имели ни малейшего понятия, как этот самый GC работает, то теперь он нам представлен на блюдечке стараниями Конрада Кокоса в его книге Pro .NET Memory Management. Какие выводы почерпнул для себя я? Давайте составим список проблемных областей и подумаем, как их можно решить.

На недавно прошедшем семинаре CLRium #5: Garbage Collector мы проговорили про GC весь день. Однако, один доклад я решил опубликовать с текстовой расшифровкой. Это доклад про выводы относительно оптимизации приложений.

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

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

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

#include <stdint.h>

extern uint8_t *__afl_area_ptr;
extern uint64_t prev;

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

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

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

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

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