Treiber - WHQL Zertifizierung oder Comodo Signierung

Hallo,

ich habe in unserer Firma bereits für einen Treiber die 
WHQL-Zertifizierung erfolgreich durchgeführt und bin gerade erneut 
dabei, einen weiteren Treiber vorzubereiten.

Die Ausführungen von "bluppdidupp" sind korrekt, auch die genannten 
Kosten sind so aktuell. Wir hatten jedoch die Möglichkeit, im Rahmen der 
verwendeten "unclassified certification" unseren Treiber in einem Rutsch 
von XP bis Win7 zertifizieren zu lassen und mußten lediglich für die 
32-bit und 64-bit Ausprägungen je einmal zahlen.

Ein Cross-Zertifikat bestätigt lediglich die Herkunft eines Treibers, 
statt "Dieser Treiber stammt aus einer nicht-vertrauenswürdigen Quelle" 
kommt dann die Meldung "Dieser Treiber stammt vom vertrauenswürdigen 
Hersteller XYZ". Das gibt zwar dem Anwender eine gewisse Sicherheit, ist 
aber für Kernel-Treiber unter 64-Bit-Windows nicht ausreichend. Diese 
verlangen für solche Treiber zwingend die WHQL-Signatur, es sei denn, 
man schaltet die Signaturprüfung temporär, z.B. durch F8 beim Booten, 
aus.

Die WHQL-Signatur setzt voraus, daß man einen Account auf der 
Winqual-Site einrichtet und auch ein Codesigning-Zertifikat besitzt. 
Weiterhin muß der Treiber die Windows Logo Kit Testsuite in der 
zugehörigen Kategorie und für die geplanten Plattformen erfolgreich 
absolviert haben. Dadurch wird die Kompatibilität zu Windows überprüft. 
Solange hier einzelne Tests fehlschlagen, ist der Treiber nicht 
zertifizierungsfähig.

Je nach Treiberkategorie ist dieser Testvorgang mehr oder weniger 
aufwändig und produziert manchmal heftige Nacharbeiten am Treiber oder 
Endgerät.

Für das aktuell zu entwickelnde Gerät, das über USB und einen 
entsprechenden zertifizierten Treiber angesprochen werden soll, führen 
wir bereits mit der Entwicklung der Betriebssystemschicht auf dem 
Endgerät parallel die WHQL-Tests durch, um frühstmöglich die 
Kompatibilität sicherzustellen.


Gruß...Maschinist

User Mode Treiber? Alles, was auf eine Hardware zugreift, braucht einen 
Kernel Mode Treiber. Es sei denn, du nutzt irgendwas, wofür das System 
bereits Treiber mitbringt. HID oder CDC oder sowas. Wobei bei CDC 
wiederum das Inf-File signiert sein muss. Wenn du HW-Treiber für Windows 
x64 anbieten willst, kommst du um die Signierung nicht herum.

Christian R. schrieb:
> User Mode Treiber? Alles, was auf eine Hardware zugreift, braucht einen
> Kernel Mode Treiber.

Mit "Vista" wurde das UMDF (user mode driver framework) eingeführt:


http://www.microsoft.com/whdc/driver/wdf/umdf.mspx

1

UMDF supports the creation of user-mode drivers that support 

2

protocol-based or serial-bus-based devices. Such drivers handle 

3

the same types of I/O requests as kernel-mode drivers and are 

4

installed by INF files, just as kernel-mode drivers are.

[Nachtrag]

Q.  Which device classes and driver models does UMDF support?
A.

UMDF supports devices such as the following:
• Digital cameras
• Portable media players
• Cell phones
• Personal digital assistants (PDAs)
• Other devices, such as USB, that connect to a protocol bus

You can implement a UMDF driver for any device that can comply with the 
constraints listed in "What are the constraints on user-mode drivers?" 
You can also implement software-only drivers with UMDF.

Q.  What are the constraints on user-mode drivers?
A.

A user-mode driver cannot directly access hardware or use kernel-mode 
resources. For example, it cannot perform direct memory access (DMA), 
handle interrupts, or allocate memory from nonpaged pool. However, you 
might be able to split your driver so that part of it runs in kernel 
mode and part of it runs in user mode.

A user-mode driver cannot have kernel-mode clients because Windows does 
not allow calls from kernel mode to user mode. The majority of drivers 
for input, display, and most network and storage devices cannot be 
migrated to user mode because they have kernel-mode clients. For the 
same reason, user-mode drivers must be at the top of the device stack; 
they cannot attach to the middle of the stack. However, a stack can 
contain more than one user-mode driver; that is, a user-mode driver can 
have user-mode children.

Ja, ich weiß schon, was ein User Mode Driver ist. Das Fragezeichen bezog 
sich eher da drauf, ob das für das Gerät überhaupt passend ist. Das geht 
ja nicht für alle Geräte. Soweit ich verstanden hab, geht das für 
generische Geräteklassen, für die Windows dann einen eigenen 
Kernel-Treiber mitbringt, zum Beispiel die USB Geschichten: "...such as 
USB, that connect to a protocol bus". Für Geräte, die nicht da rein 
fallen, brauchts dann einen (signierten) Kernel Mode Driver: "A 
user-mode driver cannot directly access hardware..."

Mein Beitrag bezog sich nicht primär auf Dich, sondern sollte Peter die 
Chance geben, herauszufinden, was für einen Treiber er dort verwendet; 
schließlich fragte er nach Unterscheidungsmöglichkeiten zwischen 
Kernelmode- und Usermode-Treiber. Peter sollte wissen, für was für eine 
Art von Gerät sein Treiber ist ...