Driver release что это такое

Обновлено: 08.05.2024

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

Итак, прежде всего, я бы хотел выделить два типа сертификатов, которые я буду рассматривать в рамках данной статьи — тестовый и настоящий. Разница состоит в том, что настоящий сертификат подписан доверенным CA (Certification Authorities — доверенный издатель), типа VeriSign, GlobalSign ну или самим Microsoft, а тестовый подписан самопальным сертификатом типа от Васи Пупкина.

Сгенерить сам сертификат и установить его. Это можно сделать с помощью тулзы makecert, например так:
Makecert -r -pe -ss PrivateCertStore -n "CN=TestCertforWDK" TestCert.cer
где
PrivateCertStore — название хранилища
TestCertforWDK — название самого сертификата
TestCert.cer — имя файла с сертификатом
(эта тулза входит в комплект WDK 6000/6001 и расположена bin/SelfSign, в WDK 7600 она почему то не входит. )
Добавить этот сертификат в хранилище с доверенным корневыми CA. Открываем в mmc консоль Сертификаты (Run->mmc->File->Add/Remove Snap-in->Certificates) там находим свой сертификат (например в хранилище PrivateCertStore), копируем его в доверенные корневые издатели (Trusted Root Certification Authorities).
Разрешить тестовые подписи. Для этого прописываем в администраторской консоли:
bcdedit.exe –set TESTSIGNING ON
и перезагружаемся, в итоге на десктопе, после перезагрузки, по углам красоваться соответствующие надписи.

Настоящий сертификат
Тут тоже не все так просто. Дело в том, что не любой CA может выдавать сертификаты для подписи драйверов Windows, а только те, которые авторизованы самой Microsoft, это значит, что корневые сертификаты этих издателей должны быть подписаны Microsoft — что, как раз и выражается в виде этого кросс-сертификата. Вот именно из-за отсутствия кросс-сертификата — тестовая подпись, никогда не будет работать как настоящая. Список доверенных CA, которые обладают такими кросс-сертификатами — представлен тут, там же можно скачать и сами кросс-сертификаты.
После того, как вы выложите несколько сотенок $$$ доверенному центру сертификации, они выдадут вам .pfx файл в котором будут содержаться публичный и приватный ключи. Вы его запустите и с помощью нехитрого диалога (как на рисунке ниже), установите в систему.

Как работает драйвер и для чего он нужен?

Основное назначение драйвера – это упрощение процесса программирования работы с устройством.

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

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

Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).

Драйвер устройства и с чем его едят

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

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

Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.

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

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

What does “signed by: Driver Release” mean?

Something was delivered by UPS yesterday but the package is nowhere to be found. Usually there’s a note on the tracking site that says “front yard” or “garage area.” But this one says, “The delivery was signed by: DRIVER RELEASE”?

What does that mean? Does it have anything to do with why my packaging is missing?

(Also, this delivery was in a very large but rural area. There’s no way the package could have been signed for by a neighbor or even stolen by one. There are no neighbors)

My package said it was delivered on Tuesday but was nowhere to be found. Today (Thursday) there was a package on the front porch right next to the door, in plain sight. I don’t know who or when this delivery happened and my tracking info hasn’t changed.

I’m glad the delivery arrived but I’ve already reordered the product thinking it was lost. Now I will have two which is kind of a bummer. But I’m hoping at least one of the purchase will be refunded

Windows Kernel Drivers — Стандартные ошибки – IRQL

Данная статья нацелена на тех, кто только недавно начал разрабатывать kernel-драйвера под ОС Windows. В 100-ый раз видишь ненавистную надпись IRQL_NOT_LESS_OR_EQUAL и этот грустный смайлик? Тогда прошу пройти под кат.

Одной из основных ошибок, которую я и сам совершал, является жонглирование IRQL так, как душе угодно, и неполное понимание внутреннего устройства работы приоритетов потоков в ядре Windows.

К примеру, у вас есть кусок кода, который генерирует какое-либо событие по PID-процесса.

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

Уже увидели ошибку в данном фрагменте?

PsLookupProcessByProcessId() – требует соблюдения условия: IRQL <= APC_LEVEL.

Так что, подобный код будет часто выдавать BSOD с кодом ошибки IRQL_NOT_LESS_OR_EQUAL.

И вот дальше, начинается самое интересное. Первое решение, которое придёт в голову новичкам, будет менять уровень IRQL перед вызовом данной функции так, чтобы условие соблюдалось.

То есть, переписать код — вот так:

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

И тут нужно вспомнить одно из правил написания драйверов, а именно:
«Понижать IRQL можно только в том случае, если вы его собственноручно повышали, и только до его предыдущего значения!»

Если какой-либо код вызвал вашу функцию на IRQL = APC_LEVEL, то вы не имеете права опустить его ниже данного уровня. Вы можете поднять IRQL до DISPATCH_LEVEL, потом опустить обратно до APC_LEVEL, но не ниже.

Таким образом, более приемлемым вариантом кода, будет:

А вспомогательные функции по типу SetIrql() из 2-го примера, в принципе не являются адекватными с точки зрения интерфейса, т.к. при проектировании отдельных методов в вашем драйвере, важно продумывать ограничения накладываемые на предусловия вызова вашей функции.

Для описания данных предусловий, удобно использовать аннотации SAL, их список вы можете посмотреть тут:

Также Microsoft предоставляет небольшой whitepaper(в самом низу статьи) по управлению приоритетами потоков в ядре, и более подробно рассказывает некоторые тонкости по работе с ними:

Если же, вам всё-таки нужно каким-либо образом вызвать какое-либо Api, требующее более низких значений IRQL, то одним из вариантов решения данной проблемы могут стать WorkItem’ы. Но о них, я расскажу уже в другой статье.

Как создается драйвер устройства

Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.

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

Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.

И чем драйвер не является

Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:

Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.

Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.

Читайте также: