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

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

Продолжаем разговор о безопасности UEFI.
На этот раз речь пойдет об опубликованной в конце 2014 года серьезной уязвимости в реализации ACPI S3 (Sleep Mode), ее эксплуатации и последствиях. Основная «фишка» этой уязвимости в том, что она вскрыла целый класс проблем безопасности UEFI, вообще не считавшихся до этого проблемами, и потому и заслуживает отдельной статьи.
Тем, кто не читал предыдущие статьи цикла — раз и два, предлагаю прочесть сначала их, остальных жду под катом.

Здравствуйте, уважаемые читатели!

Жизнь не стоит на месте, и вот в «O'Reilly» задумались об издании первой фундаментальной книги о языке программирования Rust:



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

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

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

Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI "полумифическим". С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».
В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.

Автор оригинала на английском языке — хабраюзер dzeban

Введение

В прошлый раз мы обсудили, как можно искусственно ограничить доступную программе память. В качестве бонуса я заполучил себе libmemrestrict – библиотеку с обёртками функций вроде malloc для отслеживания использования памяти, и ptrace-restrict — инструмент на базе ptrace, перехватывающий вызовы brk, sbrk и mmap с той же целью.

Так зачем нам пытаться организовывать ограничение памяти – так ли это часто встречается? Когда в последний раз ООМ прибил ваше приложение? Вы всегда думаете о потреблении памяти во время программирования? Память – штука дешёвая, и если вам не хватает памяти, добавьте ещё пару гигабайт.

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

И вот я занялся подобными задачами, начав с простой – как отсортировать миллион целых чисел (4 MiB данных) при наличии 2 MiB памяти? Эту задачу можно обобщить на тот случай, когда у вас недостаточно памяти, чтобы вместить все данные.

Дано

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

Программа должна выдавать отсортированный массив на stdout в виде текста

Она должна измерить время работы и вывести его на stderr. Нельзя просто запустить программу через утилиту time, потому что она посчитает время на чтение файла и время на его вывод.

Она должна работать, имея памяти как минимум в два раза меньше объёма файла. Для этого мы применим libmemrestrict или ptrace-restrict.

Для некоторых методов эти утилиты не пригодятся. Например, для mmap они не сработают – придётся физически ограничить использование памяти.

Они будут проверяться для решения оригинальной задачи (сортировки 4 MiB в 2 MiB). Также я запущу их на виртуалке со 128 MiB памяти для сортировки 500 Mb (125 миллионов четырёхбайтных целых).

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

В этом году проекту OpenVZ исполнится 10 лет. Мы разрабатывали технологию изолированных окружений для ОС Linux ещё тогда, когда это было не модно. 19 сентября мы собираем первую встречу людей из OpenVZ-сообщества, тех, кто пользуется нашими технологиями и Linux-контейнерами вообще. Послушать доклады пользователей и разработчиков OpenVZ, задать им вопросы, пообщаться в перерывах.

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

Виртуальная память процесса

Перед тем, как окунуться в разные методы ограничения памяти, необходимо знать, как устроена виртуальная память процесса. Лучшая статья на эту тему — «Анатомия программы в памяти».

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

Первое: уменьшение объёма адресного пространства. Это довольно просто, но не совсем корректно. Мы не можем уменьшить всё пространство до 1 Мб — не хватит места для ядра и библиотек.

Второе: уменьшение объёма кучи. Это не так-то просто сделать, и обычно так никто не делает, поскольку это доступно только через возню с компоновщиком. Но для нашей задачи это был бы более корректный вариант.

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

Для тестирования будем использовать небольшую программу по имени big_alloc, размещающую, и затем освобождающую 100 MiB.

После нашего последнего интервью с Brian McKenna для This is not a Monad tutorial мы взяли интервью у Nenad Rakocevic, создателя языка программирования Red.

С моей субъективной точки зрения Red и Rebol довольно странные создания! Но не поймите меня неправильно, это не значит ничего плохого. Например, я не знаю многих высокоуровневых языков с такими возможностями как встраиваемые DSL для стандартного низкоуровневого программирования или имеющего 50 встроенных типов. Вам следует попробовать его, вы найдете много интересных идеи в программировании на Red.

Пишите мне на твиттер @unbalancedparen свои комментарии или предложения по интервью для This is not a Monad tutorial. Оставайтесь с нами!



Расскажите нам немного о появлении Red. Для чего он был создан?

Управление памятью – одна из главных задач ОС. Она критична как для программирования, так и для системного администрирования. Я постараюсь объяснить, как ОС работает с памятью. Концепции будут общего характера, а примеры я возьму из Linux и Windows на 32-bit x86. Сначала я опишу, как программы располагаются в памяти.

Каждый процесс в многозадачной ОС работает в своей «песочнице» в памяти. Это виртуальное адресное пространство, которое в 32-битном режиме представляет собою 4Гб блок адресов. Эти виртуальные адреса ставятся в соответствие (mapping) физической памяти таблицами страниц, которые поддерживает ядро ОС. У каждого процесса есть свой набор таблиц. Но если мы начинаем использовать виртуальную адресацию, приходится использовать её для всех программ, работающих на компьютере – включая и само ядро. Поэтому часть пространства виртуальных адресов необходимо резервировать под ядро.



Это не значит, что ядро использует так много физической памяти – просто у него в распоряжении находится часть адресного пространства, которое можно поставить в соответствие необходимому количеству физической памяти. Пространство памяти для ядра отмечено в таблицах страниц как эксклюзивно используемое привилегированным кодом, поэтому если какая-то программа пытается получить в него доступ, случается page fault. В Linux пространство памяти для ядра присутствует постоянно, и ставит в соответствие одну и ту же часть физической памяти у всех процессов. Код ядра и данные всегда имеют адреса, и готовы обрабатывать прерывания и системные вызовы в любой момент. Для пользовательских программ, напротив, соответствие виртуальных адресов реальной памяти меняется, когда происходит переключение процессов:

На Хабре уже есть несколько статей о том, как разрабатывать модульные тесты на языке Си. Я не собираюсь критиковать описанные подходы, а лишь предложу ещё один — тот, которым мы пользуемся в проекте Embox. Пару раз мы уже ссылались на него на Хабре.

Кому интересно, прошу подкат! Но предупреждаю: там много портянок из макросов и «линкерской» магии.

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

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

Если вы плохо знакомы с применением эксплойтов, вам cледует сначала прочитать мою прошлую статью про взлом игр DS с помощью уязвимости целостности стека (stack smash) в файлах сохранений.

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

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

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

Управляемые ресурсы в ядре Linux (также известны как Device Resource Management или devres API), о которых я писал небольшую заметку ранее, — вещь крайне полезная, но не стоит воспринимать этот вспомогательный набор функций как серебрянную пулю при написании драйверов или модификации существующих. Рассмотрим случаи, где нужно аккуратно применять данные методы.

В этом посте я хочу рассказать о наших усилиях по использованию российского процессора с оригинальной архитектурой Мультиклет. Нам интересен перенос нашей ОСРВ Embox на данную платформу, так как это даст возможность использовать довольно большое количество приложений, которые у нас имеются — например, SIP-телефон, о котором мы уже рассказывали.

Речь пойдёт о проблемах, с которыми мы столкнулись в процессе переноса, и о том, как мы эти проблемы устраняли. Возможно, это будет интересно не только тем, кто планирует использовать данный процессор, но и тем, кому по каким-то причинам будет необходимо перейти со стандарта c99 и gcc на стандарт c89 и какой-нибудь несовместимый с gcc компилятор. Также в заключении я позволю себе добавить личные ощущения от взаимодействия с данной платформой.

Приветствую!

В прошлый раз мы остановились на том, что подняли DMA в FPGA.
Сегодня мы реализуем в FPGA примитивный LCD-контроллер и напишем драйвер фреймбуфера для работы с этим контроллером.

Вы ещё раз убедитесь, что разработка под FPGA и написание драйверов под Linux дело очень простое, но интересное.

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

С чего все началось

Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.

Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.

Однажды появилась такая необходимость обновить версии темплейтов OpenVZ загруженных в кэш Proxmox'а.

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

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

Итак, есть желание и пора приступать к его осуществлению. Для начала решим, что же конкретно должен делать наш скрипт.

Вторая часть

С чего всё начиналось

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

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

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



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