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

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, и он не продолжит работу, пока отладчик его не «разморозит».

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