Driver interface что это
Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:
- Минипорт-драйверы (драйверы адаптера)
- Промежуточные драйверы (например, psched.sys)
- Драйверы протокола (например, tcpip.sys)
Минипорт-драйверы
- производит инициализацию своего устройства (адаптера)
- создание /включение/выключение/удаление сетевых подключений
- выдача клиенту или изменение параметров адаптера
- отправка пакетов
- получение пакетов
- оповещение ОС о состоянии адаптера
- перезагрузка и остановка адаптера
Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).
Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.
Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.
- LBFO (Load Balancing and Fail Over) — позволяет понимающим его адаптерам распределять между собой исходящий трафик и исправлять ошибки друг друга. Впрочем, что имеет смысл только на backbone routers (центральных маршрутизаторах больших сетей), на которые редко ставят Windows
- FFP (Fast Forwarding Path) — позволяет понимающим его адаптерам маршрутизировать/фильтровать пакеты чисто аппаратно, вообще без участия ОС и не нагружая основные процессоры компьютера
Промежуточные драйверы
Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.
- организуют «справедливый» доступ разных клиентских программ к адаптерам дабы программы не мешали друг другу
- фильтруют и перехватывают трафик
- маршрутизируют пакеты из одной сети в другую, если эти сети различаются (например, Ethernet и WI-FI)
Драйверы протоколов
Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.
К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).
Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).
Intel® Management Engine (Intel® ME) - подсистема, встроенная в чипсет, предназначенная для различных задач связанных с мониторингом и обслуживанием компьютера во время сна, загрузки, а также в процессе его работы. Для корректной работы Intel ME потребуется драйвер, отсутствие которого приведёт к восклицательным знакам в "Диспетчере Устройств". Требуется ME для старта и первоначальной настройки материнской платы. Выход из строя Intel Management Engine (если плата/ноутбук при этом живы) чаще всего приводит к тому, что вентиляторы работают на полную катушку (без регулировки оборотов, чем в том числе и занимается Intel ME).
Кроме того, на базе ME реализованы другие технологии:
Intel AMT (удалённое администрирование/управление компьютером)
Intel AT (противоугонный модуль)
Intel SMB (урезанный/модифицированный вариант AMT для малого бизнеса)
Этот процессор "никак не связан" с Intel — это лицензированный у фирмы ARC International (многократно перекупленной, сейчас ею владеет фирма Synopsis на которую, в частности, и стоит перенаправленные с уже бывшего официального сайта www.arc.com) RISC-процессор (т. е. не x86-архитектура). 32-битный, характерный представитель семейства IP-процессоров - специально конфигурируемых "под заказчика", возможности/фичи которых можно задать самостоятельно. Прямой конкурент ставших так популярными в связи с развитием смартфонов-планшетов-андроидов, ARM-процессоров. Имеет все плюсы последних - крайне малое потребление, при этом достаточные для большинства "нужных задач" возможности, среди которых в том числе своя постоянная и оперативная память.
На базе этого процессора и работает Management Engine (просто ME дальше для краткости). Для взаимодействия ОС с ME имеется MEI - Management Engine Interface. А для настройки ME в BIOS Setup есть MEBx (ME BIOS Extensions) - отдельный модуль, поставляемый для OEM-производителей либо встроенный в BIOS Setup подпункт (у случае EFI/BIOS от Intel). Для корректной работы MEI с ОС соответственно потребуется драйвер.
Network Driver Interface Specification - (спецификатор интерфейса сетевых драйверов), представляет собой mini-port. Грубо говоря, это библиотека функций, позволяющая драйверам сетевых протоколов "гонять" сетевые пакеты, не вникая в детали реализации. Фаервол работающий на NDIS-уровне, перехватывает практически весь трафик, который только проходит через компьютер. "Практически" - потому что обращения к обратной петле через NDIS не проходят и остаются незамеченными, то есть, если дать команду ping 127.0.0.1, пакетный фильтр даже не пикнет. А это значит, что NDIS-брандмауэры хронически не способны обнаруживать подключения к локальным службам. Если на компьютере установлен Proxy-сервер (а он установлен практически на всех домашних сетях), любое приложение может свободно выходить в Сеть и гулять по любым адресам, осуществляя информационный обмен во всех направлениях. К тому же на NDIS-уровне не разберешься, что за приложение ломится в сеть, а без этого невозможно принять решение, пропускать его или нет.
NDIS драйвер способен
распозновать поступающие пакеты и передавать их соответствующим частям
вашего софта, да еще так, что этот самый софт думает что он единолично
передает и принимет сетевые пакеты.
NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку: Как видно из этой иллюстрации NDIS-драйверы бывают трёх типов: Минипорт-драйверы (драйверы адаптера). Промежуточные драйверы (например, psched.sys). Драйверы протокола (например, tcpip.sys) Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т. п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку.
Как уважаемый хабрапользователь наверняка знает, «драйвер устройства» — это компьютерная программа управляющая строго определенным типом устройства, подключенным к или входящим в состав любого настольного или переносного компьютера.
Основная задача любого драйвера – это предоставление софтового интерфейса для управления устройством, с помощью которого операционная система и другие компьютерные программы получают доступ к функциям данного устройства, «не зная» как конкретно оно используется и работает.
Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.
Любой драйвер является зависимым от самого устройства и специфичен для каждой операционной системы. Обычно драйверы предоставляют схему прерывания для обработки асинхронных процедур в интерфейсе, зависимом от времени ее исполнения.
Любая операционная система обладает «картой устройств» (которую мы видим в диспетчере устройств), для каждого из которых необходим специфический драйвер. Исключения составляют лишь центральный процессор и оперативная память, которой управляет непосредственно ОС. Для всего остального нужен драйвер, который переводит команды операционной системы в последовательность прерываний – пресловутый «двоичный код».
Как работает драйвер и для чего он нужен?
Основное назначение драйвера – это упрощение процесса программирования работы с устройством.
Он служит «переводчиком» между хардовым (железным) интерфейсом и приложениями или операционными системами, которые их используют. Разработчики могут писать, с помощью драйверов, высокоуровневые приложения и программы не вдаваясь в подробности низкоуровневого функционала каждого из необходимых устройств в отдельности.
Как уже упоминалось, драйвер специфичен для каждого устройства. Он «понимает» все операции, которые устройство может выполнять, а также протокол, с помощью которого происходит взаимодействие между софтовой и железной частью. И, естественно, управляется операционной системой, в которой выполняет конкретной приложение либо отдельная функция самой ОС («печать с помощью принтера»).
Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).
Как создается драйвер устройства
Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.
При создании драйвера для Линукса, вам необходимо знать не только тип шины и ее адрес, но и схематику самого устройства, а также весь набор электрических прерываний, в ходе исполнения которых устройство отдает результат драйверу.
Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.
И чем драйвер не является
Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:
- Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
- Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.
Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.
Напомним, что основным компонентом Intel ME является встроенный в чипсет микроконтроллер с кастомной архитектурой. Известна лишь базовая модель, это 32-х разрядный ARCtangent-A4 (ME 1.x — 5.x), ARCtangent-A5 (ME 6.x — 10.x), SPARC (TXE) или x86 (ME 11.x — . ).
Начиная с 6-й версии, ME-контроллер встраивают во все чипсеты Intel.
[рисунок взят отсюда]
Загрузчик его прошивки хранится во внутренней ROM и недоступен для анализа. Сама прошивка располагается в регионе ME во внешней SPI флэш-памяти (т.е. в той же памяти, где хранится BIOS). Структура этой прошивки такова, что весь исполнимый код разбит на модули, которые хранятся в сжатом виде (либо кастомной реализацией алгоритма Хаффмана, либо LZMA). Эти кодовые модули криптографически защищены от модификаций.
Если есть желание поревёрсить прошивку, рекомендуем воспользоваться этими двумя инструментами для изучения её структуры и распаковки кодовых модулей.
Итак, рассматриваемая подсистема является аппаратно-программной основой для различных системных функций (некоторые раньше реализовывали в BIOS) и технологий Intel. Их имплементация включается в состав прошивки Intel ME. Одной из таких технологий, использующих несколько особых привилегий Intel ME, является Active Management Technology (AMT).
AMT – технология удалённого администрирования компьютерных систем, для которых заявлена официальная поддержка Intel vPro (это бренд, объединяющий несколько технологий, в том числе, AMT). Речь идёт о системах с чипсетами линейки Q (например, Q57 или Q170).
Учитывая высокую стоимость таких платформ, вряд ли кто-то случайно приобретёт компьютер с AMT для того, чтобы принципиально этой технологией не пользоваться. Тем не менее, если под рукой именно такой продукт, и есть необходимость убедиться, что AMT на текущий момент выключена, следует воспользоваться утилитой ACUwizard:
[рисунок взят отсюда]
или средством Intel Management and Security Status (входит в состав ПО Intel ME для vPro-платформ, можно обнаружить в трее):
В продуктах, не относящихся к разряду vPro-платформ AMT включить нельзя, однако в состав прошивки Intel ME входят сетевые драйверы:
Это означает, что ME-контроллер (не будем забывать, что он всегда включен) имеет техническую возможность использования сетевого интерфейса.
Поэтому проблему стоит решать основательно – пытаться выключить подсистему Intel ME.
- Прошивку Intel ME в бинарном виде;
- Модули MEBx для BIOS;
- ПО Intel ME для ОС;
- Intel System Tool Kit (STK) — комплект программных средств и документации для сборки образов SPI флэш-памяти, применения этих образов и получении информации о текущем состоянии Intel ME.
Несмотря на то, что этот комплект распространяется по NDA (судя по меткам «Intel Confidential» в прилагаемых документах), многие вендоры забывают его вырезать из архива с ПО Intel ME, который передаётся пользователям. А ещё не закрывают свои ftp-серверы от внешнего доступа. В результате, утекших версий STK очень много. Здесь можно слить комплект для любой версии Intel ME.
Важно, чтобы major и minor version (первая и вторая цифры) используемого STK совпадала с версией Intel ME целевой системы, информацию о которой можно получить, например, воспользовавшись ME analyzer:
Проверять текущее состояние Intel ME можно при помощи утилиты MEinfo, которая через Management Engine Interface (MEI) получает информацию о работе этой подсистемы:
Напомним, что MEI является интерфейсом для связи основного CPU с подсистемой Intel ME и представляет собой набор регистров в конфигурационном пространстве PCI и в MMIO. Команды этого интерфейса не документированы, как и сам протокол.
Flash Image Tool
На старых платформах (Intel ME версии 5.x и ниже) выключить данную подсистему можно, воспользовавшись Flash Image Tool (утилита из STK, предназначенная для сборки образов SPI флэш-памяти из отдельно взятых регионов BIOS, ME, GbE). При сборке задаются параметры, которые прописываются в этих регионах и в регионе Flash Descriptors. В последнем есть один очень интересный флаг, «ME disable»:
Таким образом, для выключения Intel ME на целевой компьютерной системе, в её SPI флэш-память следует записать (программатором) новый образ с выставленным флагом «ME disable».
Работает ли этот способ, нам неизвестно. Но звучит правдоподобно, учитывая, что ME-контроллер в тех версиях интегрировался только в чипсеты линейки Q, т.е. был не обязательным компонентом для всех платформ.
Flash Programming Tool
Начиная с Intel ME 9 версии, в утилиту Flash Programming Tool, предназначенную для программирования SPI флэш-памяти компьютерных платформ, была добавлена возможность временно выключать Intel ME:
Выключение выполняется отправкой команды в MEI. После отработки Intel ME не подаёт «признаков жизни», не отвечает даже MEI:
Согласно документации, в таком состоянии подсистема Intel ME находится до следующего запуска компьютера или перезагрузки.
На vPro-платформах возможность отправки этой команды есть и в более ранних версиях. Для этого необходимо воспользоваться разделом конфигурирования ME/AMT в BIOS, где должна быть опция «Intel ME disable»:
[рисунок взят отсюда]
Нельзя говорить о том, что этот способ позволяет полностью отключить Intel ME, хотя бы потому, что до момента принятия команды на отключение ME-контроллер успеет загрузиться, а значит, выполнить некоторую часть кода прошивки.
Несмотря на то, что Intel ME не подаёт «признаков жизни» после этой операции, неизвестно, может ли эту подсистему заново включить какой-нибудь сигнал извне. Также неясно, насколько Intel ME выключена.
В интересах исключения возможности исполнения ME-контроллером кода прошивки, логично попробовать ограничить ему доступ к ней. А что? Нет кода – нет проблемы.
Проанализировав документацию, которая прилагается к STK, и, немного подумав, мы предположили, что это можно сделать следующими способами.
1. Вырезать (обнулить) ME регион из SPI флэш-памяти.
Те, кто пробовал так делать сообщают о том, что их платформа либо не загружалась без наличия подлинной прошивки ME, либо выключалась ровно после 30 минут работы.
Отказ компьютерной системы грузиться без прошивки Intel ME можно объяснить важностью ME-контроллера в процессе инициализации аппаратной составляющей. А 30-минутный таймаут наводит на мысль о WDT (Watch Dog Timer).
- стереть первые 0x20 байт в ней (таким образом повредив сигнатуру 0x0FF0A55A, которая определяет режим работы флэш-памяти);
- выставить джампер HDA_SDO (если он есть).
Таким образом, ME-контроллер не получит доступ к своему региону, и, следовательно, не будет исполнять прошивку.
С одной стороны, ME-контроллер так же, как и в предыдущем случае, может препятствовать нормальной работе компьютерной системы. С другой стороны, не дескрипторный режим включает т.н. manufacturing mode, который используется вендорами в отладочных целях, и есть шанс, что система запустится.
3. Известно, что прошивка Intel ME распаковывается в выделенную и скрытую от основного CPU область оперативной памяти – ME UMA. Выделение и блокировку этой области осуществляет BIOS во время конфигурирования карты памяти. Тогда почему бы не вырезать эти фрагменты кода из BIOS, чтобы данная область не выделялась. Тогда прошивка ME не будет распаковываться и исполняться.
Проведённые эксперименты показали, что такой способ тоже не годится, и система не запускается. К тому же, у ME-контроллера есть внутренняя SRAM, которая используется при недоступности ME UMA. Поэтому часть прошивки всё равно будет исполняться.
- отключение при каждом старте командой в MEI или отключение флагом в регионе flash descriptors (в зависимости от версии);
- ограничение доступа ME-контроллеру к своей прошивке либо перевод компьютерный платформы в manufacturing mode.
- препятствование нормальной работе ME-контроллера не обеспечивая его runtime-памятью.
Очевидно, что некоторые предложенные решения влекут за собой неработоспособность компьютерной системы, остальные не дают никакой гарантии того, что подсистема Intel ME действительно выключена. В связи с этим, мы пришли к выводу, что полностью выключить Intel ME крайне сложно.
Вероятно, это связано с тем, что, отключая Intel ME, мы нейтрализуем важный компонент в архитектуре компьютерной системы. Например, без ME некому будет решать важные системные задачи вроде ACPI или ICC (которые когда-то реализовывались в BIOS). Чтобы заставить платформу стабильно работать без ME, как минимум, необходимо вернуть реализацию этих технологий в BIOS.
Так или иначе, вопрос о том, как отключить Intel ME без потери работоспособности компьютерной системы, остаётся открытым.
Читайте также: