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

Привздохнув, произнесла:
«Как же долго я спала!»

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

Все примеры относятся к Linux, хотя многие из них справедливы для других *nix систем, я просто взял за основу самую активно развивающуюся ОС, к тому же ту, которая у меня перед глазами и где я могу быстро проверить предлагаемый код.

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

В пятой части нашей серии статей мы показали, как можно использовать прерывания BIOS'а после перехода в защищенный режим, и в качестве примера определили размер оперативной памяти. Сегодня мы разовьем этот успех и реализуем полноценную поддержку работы с дисками с файловой системой FAT16 и FAT32. Работу с файлами на диске можно разбить на 2 части: работа с файловой системой и работа с диском на уровне чтения/записи секторов. Можно сказать, что для этого нам нужно написать «драйвер» файловой системы и «драйвер» диска.

Здравствуйте, уважаемые читатели Хабра.
С вами снова я и мы продолжаем копаться в различных реализациях UEFI во имя добра. Есть у меня один старый китайский GSM-модем, который на моем Dell Vostro 3360 определяется через раз, а на более старых ноутбуках — нормально. После нескольких экспериментов с подключением его через переходник к основному ПК выяснилось, что ему почему-то не нравится подключение через PCIe Gen2, и хотелось бы переключить порт на Gen1, но в UEFI Setup нужной настройки не оказалось. Печально, но не смертельно, ведь очень часто производители устройств не удаляют оригинальные меню производителя UEFI, а просто скрывают их, либо показывают на их месте свои, поэтому после небольшого реверс-инжиниринга оригинальное меню можно вернуть на место, что у меня и получилось. В этот раз одной IDA Demo уже не обойтись, т.к. DXE-драйверы в большинстве современных UEFI собираются для архитектуры x86-64, поэтому вместо нее будем использовать radare2.
На лавры первооткрывателя не претендую и подобным модификациям сто лет в обед, но постараюсь показать, как сделать подобную модификацию самостоятельно.
Если вам все еще интересно — добро пожаловать под кат.

И снова здравствуйте, уважаемые хабрачитатели.

В рамках борьбы за возможность модификации UEFI на ноутбуках HP пришлось отломать еще одну защиту, на этот раз более современную. Видимо, отдел разработки прошивок в HP догадался, что предыдущая защита была не ахти, и потому они решили радикально её улучшить, поэтому метод обхода защиты DXE-тома из предыдущей статьи перестал работать, и мне опять понадобилось вооружаться дизассемблером, разрабатывать конвертер из TE в PE и отвечать на те же вопросы: где находится цифровая подпись, кто именно ее проверяет и как сделать так, чтобы проверка всегда заканчивалась успехом.

Если вас интересуют ответы и описание процесса их поиска — прошу под кат.

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

После долгого перерыва с вами опять я и мы продолжаем копаться во внутренностях UEFI. На этот раз я решил показать несколько техник, которые позволяют упростить реверс и отладку исполняемых компонентов UEFI на примере устаревшего-но-все-еще-популярного PEI-модуля SecureUpdating, который призван защищать прошивку некоторых ноутбуков HP от модификации.

Предыстория такова: однажды вечером мне написал знакомый ремонтник ноутбуков из Беларуси и попросил посмотреть, почему ноутбук с замененным VideoBIOS'ом не хочет стартовать, хотя такой же точно рядом успешно стартует. Ответ оказался на поверхности — не стартующий после модификации ноутбук имел более новую версию UEFI, в которую добрые люди из HP интегрировали защиту от модификации DXE-тома (а там и находится нужный нам VideoBIOS вместе с 80% кода UEFI), чтобы злобные вирусы и не менее злобные пользователи ничего там не сломали ненароком. Тогда проблема решилась переносом PEI-модуля SecureUpdating из старой версии UEFI в новую, но через две недели тот же человек обратился вновь, на этот раз на похожем ноутбуке старая версия модуля работать отказалась, и моя помощь понадобилась вновь.
Если вас заинтересовали мои дальнейшие приключения в мире UEFI PEI-модулей с дизассемблером и пропатченными переходами — добро пожаловать под кат.

Мы публикуем обзор нового сервера HP ProLiant ML350 Gen9 от Евгения KorP Елизарова

В конце 2014 года большая тройка производителей серверов анонсировала новые модели серверов. Компания HP представила больше 10 обновлённых моделей серверов, среди которых был и HP ProLiant ML350 Gen9.



Главными особенностями нового сервера являются:
— поддержка процессоров нового поколения Intel Xeon E5-2600 v3
— поддержка памяти HP SmartMemory DDR4
— обновлённый контроллер HP Smart Array P440ar (SAS 12 Гбит/с)
— обновлённый контроллер HP Dynamic Smart Array, поддерживающий совместную работу с контроллерами HP Flexible Smart Array и Smart SAS HBA.

С удивлением обнаружил, что это ожидаемое многими событие почему-то обошло Хабр стороной. Думаю, что для многих программистов, следящих за этим языком программирования, будет полезно узнать, что тот самый релиз версии Rust 1.0.0 Alpha состоялся 9 января. В этой версии наконец-то стабилизировали ядро языка и большую часть стандартной библиотеки, так что теперь можно начинать писать на Rust'е программы не боясь, что через неделю что-то сломается после обновления компилятора.

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

Соавтор: Святослав Размыслов SvyatoslavMC.

В рекламных целях мы решили попробовать проверить ядро Linux с помощью нашего статического анализатора кода. Эта задача интересна своей сложностью. Исходные коды Linux чем только не проверялись и проверяются. Поэтому найти хоть что-то новое, весьма сложная задача. Но если получится, то это будет хорошая рекламная заметка о возможностях анализатора PVS-Studio.

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

• когда запись в файл — консоль драматически сказывалось на воспроизодимости бага;
• когда мульти(процессорное/поточное) приложение часто обращается к драйверу и ты не можешь сопоставить временные метки и потоки;
• когда баг воспроизводится на стороне кастомера, сеанс teamviewer бесполезен, да к тому же версия с отладочными символами private;
• когда системное приложение падает до того, как система успеет скинуть логирование на диск;
• или когда макрос для логирования выглядит в лучшем случае как

  #define TraceDbg(format, ...) \
      printf( "(p %d, t %d) - (%s,%d) %s(): " format, GetCurrentProcessId(), GetCurrentThreadId(), __FILE__, __LINE__,__FUNCTION__, __VA_ARGS__ );
  

• когда придумываешь очередной способ вывести на экран ipaddr или UUID

В статье я представлю быстрый, надежный и универсальный для отладки с минимальным оверхедом инструмент диагностики, предлагаемой MS для системных приложений — WPP, рассмотренный частично в публикации «EventTrace for Windows. Высокоскоростная передача отладочных сообщений драйвера по сети».

Периодически, как правило во вторую среду месяца, можно услышать истории о том, что Windows после очередного обновления перестает загружаться, показывая синий экран смерти. В большинстве случаев причиной такой ситуации оказывается либо руткит, либо специфичное системное ПО, фривольно обращающееся со внутренними структурами ОС. Винят, конечно, все равно обновление, ведь «до него все работало». С таким отношением не удивительно, что «Майкрософт» не поощряет использование всего, что не документировано. В какой-то момент, а именно с релизом Windows Server 2003, MS заняла более активную позицию в вопросе борьбы с чудо-поделками сторонних разработчиков. Тогда появился механизм защиты целостности ядра — kernel patch protection, более известный как PatchGuard.

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

Четвертая часть перевода D Programming Language Tutorial от Ali Çehreli.

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

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

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

В данной статье рассматривается использование реализации двусвязного списка ядра Linux.

Двусвязный список в ядре Linux реализован в файле include/linux/list.h. Мы будем использовать адаптированный вариант list.h [1], который отличается от оригинального возможностью использовать его в userspace. Например, создадим очередь — структуру данных с доступом к элементам по принципу «первый пришёл — первый вышел» для произвольного типа данных на основе list.h.

Продолжаем изучать планирование маленьких потоков. Я уже рассказала про два средства в ядре Linux, которые часто используются для отложенной обработки прерываний. Сегодня речь пойдет о совсем другой сущности — protothread Adam Dunkels, которые хоть и выбиваются из ряда, но в контексте рассматриваемой темы совсем не лишние.

А также:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

Продолжаем тему многопоточности в ядре Linux. В прошлый раз я рассказывала про прерывания, их обработку и tasklet’ы, и так как изначально предполагалось, что это будет одна статья, в своем рассказе о workqueue я буду ссылаться на tasklet’ы, считая, что читатель уже с ними знаком.
Как и в прошлый раз, я постараюсь сделать мой рассказ максимально подробным и детальным.

Статьи цикла:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

В этой статье я попытаюсь описать терминологию, используемую для описания систем, способных исполнять несколько программ параллельно, то есть многоядерных, многопроцессорных, многопоточных. Разные виды параллелизма в ЦПУ IA-32 появлялись в разное время и в несколько непоследовательном порядке. Во всём этом довольно легко запутаться, особенно учитывая, что операционные системы заботливо прячут детали от не слишком искушённых прикладных программ.



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

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

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

На этот раз я хочу подойти к вопросу планирования с другой стороны. А именно, теперь я постараюсь рассказать про планирование не потоков, а их “младших братьев”. Так как статья получилась довольно объемной, в последний момент я решила разбить ее на несколько частей:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

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

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

В последнее время все более активно развивается тематика встроенных (embedded) систем и многие крупные компании такие как Google, Microsoft, Intel вкладывают огромные ресурсы в исследования и разработки в данной области. Взять, например, проект Майкрософт по созданию специализированной ОС для умных домов homeos или процессоры от Intel для встроенных решений Intel Quark, а о различных исследовательских проектах от Google по робототехнике и говорить не стоит, они и так на слуху.

Подобные системы всегда имели свои особенности: ограниченность вычислительных ресурсов, различные процессорные архитектуры, порядок байт и многое другое. Всё это накладывает отпечаток на процесс разработки встроенного ПО. Несмотря на то, что в последнее время для создания встроенных систем все чаще применяются принципы и технологии из области “обычных” десктопных систем, сам процесс остается специфичным. Поэтому считается, что порог вхождения при разработке системного и встроенного ПО очень высокий. Для подготовки хороших специалистов в этой области на Мат-Мехе СПбГУ организовали исследовательский проект по созданию ОС реального времени для встроенных применений Embox, в котором активную роль играют студенты.



В четверг, 27 ноября, в 20:00 в бизнес-инкубаторе «Ингрия» состоится встреча CodeFreeze с Антоном Бондаревым, техническим руководителем проекта Embox. В докладе будет раскрыты аспекты разработки встроенного ПО на примере этой ОС.

Мечта Карлсона сбывается

Помните из классики:

— Карлсон, ты знаешь, она хочет попасть в телевизор!
— Она? В телевизор?
— Да.
— Вот эта толстая домомучительница хочет залезть в самую маленькую коробочку?! Ничего не получится. Её надо будет сложить вчетверо!

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

Сегодня мы совершим экскурсию по Производственному департаменту Консорциума «Кодекс» (ПД), сотрудники которого занимаются формированием начинки для профессиональных справочных систем «Кодекс» и «Техэксперт». Коллеги из разных подразделений из первых уст расскажут о нашем способе «наведения чистоты» в системе такого масштаба. Мы проследим весь жизненный путь документа от поиска до попадания к пользователю. Также выясним, есть ли у документа жизнь после смерти.

Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.



На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.