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

Я работаю с программными моделями центральных процессоров в составе полноплатформенного симулятора. Занятие это, конечно же, очень интересное — приходится иметь дело с технологиями интерпретации, двоичной трансляции, виртуализации (об этом я уже писал здесь). Однажды моё внимание привлёк тот факт, что значительную часть времени я вожусь над единственной, казалось бы, не самой вычислительно интенсивной инструкцией. Причина в том, что типов процессоров существует много, и все они во многом похожи; однако при этом критически важно очень точно представлять различия между ними.
В этой статье я описываю, зачем и как процессоры умеют сообщать о своих возможностях, и как к этому вопросу подошли разные производители. В её продолжении я расскажу об эволюции и особенностях инструкции CPUID для Intel IA-32, например, почему её описание занимает в Intel SDM [1] около 40 страниц.

Суть проблемы

МФУ Xerox 3220 поддерживает сетевое сканирование через приложение (Network Scan), установленное на один из компьютеров в сети, в котором это МФУ регистрируется по IP адресу. Но однажды производственная необходимость потребовала пользоваться на данном компьютере VPN подключениями (Cisco VPN Client и OpenVPN). И в момент подключения любого из соединений связь со сканером из приложения моментально терялась. О моем процессе исследования и решении этой проблемы и будет дальше идти речь.

На днях у нас вышло второе издание замечательной книги «Linux. Системное программирование. 2-е изд.». Как обычно для Хабра-читателей действует скидка 20%. Акция продлится до 20 апреля. При покупке книги введите код: 1f8e5be3.
Книга доступна в печатном и электронном виде.

Аннотация:

Пишите программы, опирающиеся непосредственно на службы ядра Linux и на основные системные библиотеки. Автор этой универсальной книги, Роберт Лав, участвовал в разработке ядра Linux. Книга представляет собой руководство по системному программированию для Linux, справочный мануал по системным вызовам Linux, а также инсайдерский рассказ о том, как писать более быстрый и умный код.

Rust — компилируемый мультипарадигмальный язык, позиционируется как альтернатива С/С++ с уклоном в параллельные вычисления, безопасность и удобство работы с памятью.

Что нового в Rust 0.10:

Читая новости о запрете на поставку электронной компонентной базы из США для отдельных производителей в РФ, мы решили рассказать об одноплатном микрокомпьютере Module МВ 77.07, который был разработан в российском научно-техническом центре «Модуль» на базе одного из наиболее производительных российских процессоров архитектуры ARM. Также мы рассмотрим установку Linux-дистрибутива Debian на этот микрокомпьютер.

Мы решили поделиться своей новой разработкой – системой, способной читать мысли системных администраторов и предугадывать их действия!

Netwrix Auditor улавливает мозговую активность пользователей, прогнозирует их дальнейшие действия и оповещает об их планах.

О системе OpenStack была масса статей на Хабре, однако ни одна не затрагивала вопросы разработки и тестирования составных сервисов. Скажу сразу, настраивать среду голыми руками дело не из легких и не совсем уж благодарное. К счастью, существует официальная программа под названием Devstack, которая представляет собой набор скриптов для автоматической установки OpenStack на локальную виртуальную машину. Ну вот, хотелось бы тут и закончить статью, однако не все так складно с этим Devstack. А именно, установить его — это целый процесс танца с бубнами и выбора правильных конфигурационных параметров. К тому же проект движется своим шагом, и то, что работало сегодня может вылететь при любом новом комите.

Задача

Необходимо построить среду разработки под OpenStack для тестирования, багфиксинга и добавления фич в сервисы системы (nova, keystone, swift, heat, etc.). Среда должна собираться почти автоматически, чтобы было возможно в любой момент стереть созданную виртуальную машину, создать новую, запустить скрипты и получить готовую среду через несколько минут. Причем среда должна быть такой же, как на прежней VM. Так как интересующий меня сервис на момент написания статьи является heat, то конфигурация будет ориентирована под него, однако путем замены пары строчек можно адаптировать всю конфигурацию под любой другой сервис.

Понадобилось мне перехватывать вызовы GDS32.DLL. Решил написать прокси-dll.

Пишем исследовательский стенд

Первое, что нам нужно — это получить список всех экспортируемых функций из настоящей dll.
Сделаем это следующим кодом:

1.	program GetFuncsDll;
2.	  {$APPTYPE CONSOLE}
3.	  uses   Windows;
4.	  var
5.	    ImageBase: DWORD;                  //адрес образа dll
6.	    pNtHeaders: PImageNtHeaders;       // PE заголовок dll
7.	    IED: PImageExportDirectory;        // адрес таблицы экспорта
8.	    ExportAddr: TImageDataDirectory;   // таблица экспорта
9.	    I: DWORD;                          // переменная для цикла
10.	    NamesCursor: PDWORD;               // указатель на адрес имени функции
11.	    OrdinalCursor: PWORD;              // указатель на адрес номера функции
12.	    LIB_NAME:AnsiString;               // имя dll
13.	BEGIN
14.	  LIB_NAME:='MiniLib.dll';
15.	  loadlibraryA(PAnsiChar(LIB_NAME));
16.	  ImageBase := GetModuleHandleA(PAnsiChar(LIB_NAME));
17.	  pNtHeaders := Pointer(ImageBase + DWORD(PImageDosHeader(ImageBase)^._lfanew));
18.	  ExportAddr := pNtHeaders.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
19.	  IED := PImageExportDirectory(ImageBase+ExportAddr.VirtualAddress);
20.	  NamesCursor := Pointer(ImageBase + DWORD(IED^.AddressOfNames));
21.	  OrdinalCursor := Pointer(ImageBase + DWORD(IED^.AddressOfNameOrdinals));
22.	  For I:=0 to Integer(IED^.NumberOfNames-1) do begin
23.	    WriteLn(output,PAnsiChar(ImageBase + PDWORD(NamesCursor)^),'=',OrdinalCursor^ + IED^.Base);
24.	    Inc(NamesCursor);
25.	    Inc(OrdinalCursor);
26.	  end;
27.	Readln;
28.	end.
Листинг 1

Здесь трудностей вроде нет. Добираемся последовательно до таблицы экспорта (строка 19) указателей на массив имен(NamesCursor) и массива номеров(OrdinalCursor) и читаем функцию за функцией, имена и номера. Количество функций находится в поле NumberOfNames. Этот код был добыт на просторах интернета, потом доработан и упрощён.

Для чего эта статья?

Все эмбеддеры, рано или поздно, сталкиваются с проблемой нехватки ПЗУ микроконтроллера для своих проектов. Ну банально, Вам нужно разработать систему управления простеньким ЧПУ станком, где управляющая программа хранится на самом девайсе или систему сбора данных, скажем, от датчиков какого-нибудь эксперимента – очевидно, что микроконтроллер изначально не предназначался для хранения таких массивов информации.

В посте речь пойдет о консольной утилите ReadPE собственной разработки, которая парсит исполняемые файлы формата Portable Executable.

Отвечая на возможный вопрос: «Почему потребовался свой велосипед, если уже есть dumpbin?» скажу, что меня перестали удовлетворять многие известные утилиты подобного класса из-за их неспособности работать с хитровыдуманными и вручную созданными файлами. Взятые файлы входящие в известный набор Corkami и поданные на вход dumpbin, идущая в поставке с Visual Studio или pedump Мэтта Питрека в большинстве случаев откажутся работать с подобным файлом. Это связано с тем, что очень часто при написании подобных утилит опираются исключительно на официальное описание этого формата предоставляемого Microsoft. Несмотря на то, что сам формат достаточно простой, он тем не менее обладает весьма большим количеством подводных камней и лучшим руководством по этому формату является листинг кода из системного загрузчика в IDA Pro.

Некоторое время назад я писал вводную статью о хуках (что это, зачем нужно, Hello world). Статья задумывалась простой, минималистичной и, вроде бы, такой и получилась. Единственный упрёк, который я услышал в комментариях — «Зачем же брать библиотеку Microsoft Detours, которая для коммерческого использования стоит 10 000$ ?». Замечание справедливое. В этой статье я приведу тот же пример с использованием другой библиотеки ценой примерно в 20 раз меньше (что уже вполне себе в рамках разумного) — madCodeHook.

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

Привет, Хабр! Эту статью я задумал довольно давно. Речь в ней пойдет о простейшем копирующем сборщике мусора на С++. У него довольно много ограничений (часть не мешает, часть можно обойти, если задаться целью написать какую-то серьезную библиотеку, а для кое-чего неплохо было бы заиметь зачаточную поддержку от языка), зато и кода в нем чуть больше 100 строк. Заинтересовавшихся прошу под кат. Там минимум ООП, простейшие шаблоны и жуткие магические ритуалы с указателями.

Хочу поговорить об устройстве управления памятью (Memory Management Unit, MMU). Как вы, разумеется, знаете, основной функцией MMU является аппаратная поддержка виртуальной памяти. Словарь по кибернетике под редакцией академика Глушкова говорит нам, что виртуальная память — это воображаемая память, выделяемая операционной системой для размещения пользовательской программы, ее рабочих полей и информационных массивов.

У систем с виртуальной памятью четыре основных свойства:

1. Пользовательские процессы изолированы друг от друга и, умирая, не тянут за собой всю систему
2. Пользовательские процессы изолированы от физической памяти, то есть знать не знают, сколько у вас на самом деле оперативки и по каким адресам она находится.
3. Операционная система гораздо сложнее, чем в системах без виртуальной памяти
4. Никогда нельзя знать заранее, сколько времени займет выполнение следующей команды процессора

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

К сожалению, по какой-то причине все вышеперечисленные товарищи недостаточно почтительно относятся к MMU, а их знакомство с виртуальной памятью обычно начинается и заканчивается изучением страничной организации памяти и буфера ассоциативной трансляции (Translation Lookaside Buffer, TLB). Самое интересное при этом остается за кадром.

Несколько дней назад Роберт Грэм начал работу над серией статей C10M и планирует закончить работу в июле этого года.

Сегодня уже доступны следующие главы:

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

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

В самой первой части нашей серии «Как запустить программу без операционной системы» мы остановились на том, что загрузили ядро с помощью GRUB’а и распечатали на экран классический “Hello World!”. Теперь мы покажем, как можно использовать прерывания BIOS’а в ядре ОС. А для начала — рассмотрим, что же такое прерывания BIOS’а, для чего они используются, и почему возникают проблемы с их вызовом.

Многим пользователям Linux, особенно тем, кто по тем или иным причинам перешёл на эту ОС с Windows, не хватает возможности удаления файлов «в корзину». Кроме того, наверняка, каждый, кто пользовался Linux'ом и по ошибке удалял какой-либо файл, испытывал смешанные чувства от отсутствия простой возможности восстановить утраченные данные.

В продолжение предшествующего материала, посвящённого перехвату функций ядра Linux, представляю способ использования разработанного ранее фреймворка для создания модуля ядра Linux, реализующего возможность удаления файлов «в корзину» (just for fun).

Я работаю системным администратором Unix. Однажды к нам в отдел эксплуатации сервисов упал тикет от программиста с выдержой из лога application-сервера в заголовке: "pgbouncer cannot connect to server". Посмотрев логи pgbouncer'ов, я увидел, что периодически возникают lookup fail'ы при обращении к нашим DNS. Было установленно, что это связано не с работой наших DNS-серверов, а с ненадёжностью самого протокола UDP: иногда возникают потери пакетов по разным причинам.

В результате, было решено установить на каждом сервере с pgbouncer'ами по кэширующему BIND. И тут возникла интересная проблема: pgbouncer не перечитывал по сигналу HUP файл /etc/resolv.conf и продолжал обращаться к старым DNS-серверам. А перезагружать баунсеры категорически нельзя: есть проблемные проекты, которые очень болезненно относятся к разрывом сессий с базой.

В данной статье я расскажу как можно pgbouncer или любую другую программу, использующую библиотечный вызов getaddrinfo(), заставить перечитать resolv.conf и начать использовать новый DNS-сервер совершенно безболезненно для клиентов (без даунтайма).

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

Данная статья является практическим обобщением представленных ранее статей:

1. Управляемый PageFault в ядре Linux
2. Кошерный способ модификации защищённых от записи областей ядра Linux

Далее будет рассмотрено каким образом использование данных материалов может быть применимо в обеспечении возможности перехвата функций ядра Linux.