### Teilaufgabe 1: RECHERCHE WINDOWS-GRAFIKTREIBER. Belege mit Quellen (URLs, moeglichst learn.microsoft.com und docs.kernel.org). Beantworte praezise und mit Zitatstellen: (1) Was ist der 'Microsoft Basic Display Adapter' / 'Microsoft Basic Display Driver' (BDD) technisch? Welcher Treiber-Dateiname, welcher Mechanismus (UEFI GOP Framebuffer, VESA/VBE), was kann er NICHT (keine 3D-Beschleunigung, feste Aufloesung, kein Modewechsel)? Ab welcher Windows-Version? (2) WDDM: die Zweiteilung in Kernel-Mode-Display-Miniport-Driver (KMD, .sys, gegen dxgkrnl.sys) und User-Mode-Display-Driver (UMD, DLL, gegen D3D-Runtime). Welche DDI-Schnittstellen genau (DXGKRNL_INTERFACE, DriverEntry/DxgkInitialize, D3DDDI)? (3) Die WDDM-VERSIONEN 1.0/1.1/1.2/1.3/2.0/2.1/...3.0/3.1/3.2 - welche Windows-Version bringt welche, und was heisst 'ein WDDM-2.x-Treiber laeuft auf einem Windows, das WDDM 3.x hat' (Abwaertskompatibilitaet der DDI). (4) Wie wird ein Treiber zur LAUFZEIT geladen: INF-Datei, PnP, Service Control Manager, ein Kerneltreiber ist ein Dienst vom Typ SERVICE_KERNEL_DRIVER, ZwLoadDriver/StartService, der Kernel-Loader (ntoskrnl) mappt das PE-Image und ruft DriverEntry. (5) SIGNATURPFLICHT: Kernel Mode Code Signing (KMCS) ab Vista x64, ab Windows 10 1607 muss ein neuer Kerneltreiber vom Microsoft Dev Portal per Attestation/WHQL signiert sein (EV-Zertifikat + Microsoft-Gegensignatur), Secure Boot / HVCI. Nenne die genauen Regeln und ab welcher Version. Gib zu JEDER Aussage die Quell-URL. Wenn du etwas nicht belegen kannst, sage das ausdruecklich. I have sufficient primary-source material. Here is the result. --- # Windows-Grafiktreiber — Recherchebericht Alle Aussagen mit Quell-URL. Wo ich etwas **nicht** belegen konnte, steht das explizit als „⚠️ NICHT BELEGT". --- ## (1) Microsoft Basic Display Adapter / Basic Display Driver (BDD) **Quelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/display/microsoft-basic-display-driver ### Technische Fakten (wörtlich belegt) | Punkt | Beleg | |---|---| | **Dateiname** | `BasicDisplay.sys` — „The Microsoft Basic Display Driver (*BasicDisplay.sys*) is a generic display driver that ships with the Windows operating system." | | **Zweck** | „*BasicDisplay*'s primary purpose is to enable Windows to write to the display controller's **linear frame buffer**." | | **Wann geladen** | Default-Treiber, wenn „An IHV graphics driver isn't present" oder „the inbox installed graphics IHV driver isn't working or is disabled"; außerdem im **Safe Mode** und in frühen Setup-Phasen: „In the early phases of Windows setup, just before the final boot, only the *BasicDisplay* is loaded." | | **UEFI GOP** | „*BasicDisplay* supports Unified Extensible Firmware Interface (UEFI) Graphics Output Protocol (GOP)." | | **Feste Auflösung auf UEFI** | „On UEFI platforms, *BasicDisplay* **inherits the linear frame buffer that is set during boot**. In this case, **no mode or resolution changes are possible**." ← das ist die exakte Belegstelle für „feste Auflösung / kein Modewechsel" | | **Video-BIOS-Pfad (Legacy)** | „*BasicDisplay* can use the **video BIOS** to manage modes and resolutions **on a single monitor**." → auf Legacy-BIOS-Systemen sind Modewechsel via VBE möglich, aber nur ein Monitor | | **XDDM-Hardware** | „*BasicDisplay* works on both WDDM and legacy XDDM hardware." | | **Ersetzt** | laut Doc-Metadaten (`description`): „the in-box display driver that **replaces the XDDM VGA Save and VGA PnP drivers**" | | **Rendering / 3D** | „*BasicDisplay* is **always used with *BasicRender***, which is the system-supplied module that exposes the functionality of **WARP** from an adapter in the kernel." | | **Windows 11** | „Starting in Windows 11, both *BasicDisplay* and *BasicRender* run from their *DriverStore* locations in `c:\Windows\System32\DriverStore`." | ### Wichtige Präzisierung zu „keine 3D-Beschleunigung" Die verbreitete Aussage „BDD kann kein 3D" ist **so nicht ganz korrekt** und die Doku sagt es anders: - BDD ist **DirectX-kompatibel**: „*BasicDisplay* helps to enable a consistent end user and developer experience because it's **compatible with DirectX APIs** and technologies such as the Desktop Composition." - 3D funktioniert, aber **rein in Software über WARP** (Windows Advanced Rasterization Platform), bereitgestellt durch `BasicRender`. Es gibt also 3D-**Funktionalität**, aber **keine Hardware-Beschleunigung** durch die GPU. - WARP-Referenz: https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp **Korrekte Formulierung:** BDD bietet keine *hardwarebeschleunigte* 3D-Grafik; 3D wird von der CPU via WARP emuliert. ### Ab welcher Windows-Version? ⚠️ **NICHT direkt belegt.** Die verlinkte Doc-Seite nennt **kein Einführungs-Release**. Indirekte Hinweise auf derselben Seite: das Beispiel spricht von „no in-box graphics driver support for **Windows 8 or later**", und BDD ersetzt die XDDM-VGA-Treiber — was zu **Windows 8** passt (dort wurde WDDM verpflichtend, siehe Abschnitt 3). Ich habe dafür aber **keine explizite Belegstelle** gefunden; behandle „ab Windows 8" als plausibel, nicht als belegt. --- ## (2) WDDM-Zweiteilung: KMD und UMD **Quelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-architecture ### Grundaufbau (wörtlich) > „The Windows Display Driver Model (WDDM) has user-mode and kernel-mode components." **Vom Hardwarehersteller zu liefern — beide Teile sind Pflicht:** > „The UMD is a **dynamic-link library (DLL)** that the Direct3D runtime loads." > „The KMD communicates with *Dxgkrnl* and the graphics hardware." > „**A graphics hardware vendor must supply both a UMD and KMD.**" ### Systemseitige Module | Modul | Rolle (Zitat) | |---|---| | **Direct3D runtime** | „a user-mode component that provides an application API… manages the interaction between an application, the user-mode graphics driver (UMD), and *gdi32.dll*" | | **gdi32.dll** | „A runtime or client calls a *gdi32* **'thunk'** that routes the call to the appropriate kernel-mode function in the DirectX kernel subsystem (*Dxgkrnl*)." | | **dxgkrnl.sys** | „handles everything else in the DirectX kernel subsystem, including loading the needed *dxgmms.sys* file, **initial processing of `D3DKMT*Xxx*` calls from user mode**, display modes, GPU virtualization, power management, interface with the kernel executive" | | **dxgmms2.sys** | „implements the GPU/NPU scheduler and video memory manager for **WDDM versions 2.0 and later**" | | **dxgmms1.sys** | „…for **WDDM versions before 2.0**" | Dxgkrnl enthält Subkomponenten: „the display port driver, the memory manager (**VidMm**), and the scheduler (**VidSch**)". ### Die konkreten DDI-Schnittstellen **a) `DriverEntry` → `DxgkInitialize`** Quelle: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dispmprt/nf-dispmprt-dxgkinitialize > „A kernel-mode display miniport driver's (KMD) **DriverEntry** routine calls the system-supplied **DxgkInitialize** function to load and initialize the DirectX graphics kernel subsystem (*Dxgkrnl.sys*)." ```c NTSTATUS DxgkInitialize( [in] PDRIVER_OBJECT DriverObject, [in] PUNICODE_STRING RegistryPath, [in] PDRIVER_INITIALIZATION_DATA DriverInitializationData ); ``` - Header: `dispmprt.h`, Lib: `Displib.lib`, IRQL: `PASSIVE_LEVEL` - Minimum supported client: **Windows Vista (WDDM 1.0)** - `RegistryPath` = „the path to the driver's **service registry key**" ← Bindeglied zu Abschnitt (4) **b) `DRIVER_INITIALIZATION_DATA` — KMD → OS (Callback-Tabelle nach unten)** Quelle: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dispmprt/ns-dispmprt-_driver_initialization_data > „…supplies *Dxgkrnl* with pointers to functions implemented by the KMD." Der Treiber setzt `DriverInitializationData.Version = DXGKDDI_INTERFACE_VERSION;` und füllt die `DxgkDdi*`-Funktionszeiger, u.a. `DxgkDdiAddDevice`, `DxgkDdiStartDevice`, `DxgkDdiInterruptRoutine`, `DxgkDdiDpcRoutine`, `DxgkDdiQueryAdapterInfo`, `DxgkDdiCreateAllocation`, `DxgkDdiPatch`, `DxgkDdiSubmitCommand`, `DxgkDdiBuildPagingBuffer`, `DxgkDdiPresent`, `DxgkDdiRender`, `DxgkDdiSetVidPnSourceAddress`, `DxgkDdiCommitVidPn`, `DxgkDdiResetFromTimeout` (TDR) usw. (vollständiges Codebeispiel auf der DxgkInitialize-Seite). **c) `DXGKRNL_INTERFACE` — OS → KMD (Callbacks nach oben)** Quelle: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dispmprt/ns-dispmprt-_dxgkrnl_interface > „The **DXGKRNL_INTERFACE** structure contains a handle to a display adapter and a set of pointers to functions implemented by the **display port driver**, which is a part of *Dxgkrnl*." **Wie der Treiber sie bekommt (wichtig):** > „The display port driver provides the display miniport driver with the handle and function pointers by passing a **DXGKRNL_INTERFACE** structure to **`DxgkDdiStartDevice`**." Struktur-Member: - `Size`, `Version` — „A positive integer that indicates the version of the functional interface implemented by the display port driver. **Version** can be one of the **`DXGKDDI_INTERFACE_VERSION_XXX`** values defined in **`D3dukmdt.h`**." - `DeviceHandle` — „A handle, generated by the display port driver, that represents a display adapter. The display miniport driver passes the handle as an argument each time it calls any of the functions in **DXGKRNL_INTERFACE**." - Callbacks (`DxgkCb*`): `DxgkCbMapMemory`, `DxgkCbQueryServices`, `DxgkCbQueueDpc`, `DxgkCbNotifyInterrupt`, `DxgkCbNotifyDpc`, `DxgkCbQueryVidPnInterface`, `DxgkCbEvalAcpiMethod`, `DxgkCbAcquirePostDisplayOwnership`, … bis `DxgkCbDisconnectDoorbell` (WDDM 3.1). **d) `D3DDDI` — die User-Mode-Seite** Die UMD implementiert die `D3DDDI_*` / `pfnCreateDeviceCb`-Schnittstellen gegen die D3D-Runtime; sie ruft in den Kernel über die `D3DKMT*`-Funktionen (siehe dxgkrnl-Zitat oben: „initial processing of **D3DKMT*Xxx*** calls from user mode"). ⚠️ Ich habe die dedizierte D3DDDI-Referenzseite in dieser Recherche **nicht einzeln abgerufen**; die Existenz und Rolle ist über das dxgkrnl-Zitat und die Architekturseite belegt, die genaue Funktionsliste nicht. **Datenfluss:** App → D3D-Runtime → **UMD (DLL, User Mode)** → gdi32-Thunk → **dxgkrnl.sys / dxgmms2.sys (Kernel)** → **KMD (.sys)** → GPU. --- ## (3) WDDM-Versionen und Windows-Zuordnung **Quelle (offizielle Tabelle):** https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-display-driver-model-design-guide > „Microsoft introduced WDDM in Windows Vista (WDDM 1.0) and continues to evolve it with every Windows release." > „**Windows 8 (WDDM 1.2) requires WDDM.**" | WDDM | Windows-Version | Hauptfeatures (laut MS-Tabelle) | |---|---|---| | 1.0 | Windows Vista | GPU scheduling, virtual memory management, TDR | | 1.1 | Windows 7 | GDI hardware acceleration, Direct3D 11, multi-adapter | | 1.2 | Windows 8 | Stereoscopic 3D, preemptive multitasking, reduced memory footprint | | 1.3 | Windows 8.1 | Miracast wireless displays, multi-plane overlays | | 2.0 | Windows 10 (1507) | GPU virtual addressing, driver residency model, Direct3D 12 | | 2.1 | Windows 10 (1607) | Shader Model 6.0, HDR10 | | 2.2 | Windows 10 (1703) | Virtual/mixed reality | | 2.3 | Windows 10 (1709) | HDR, display color space transforms | | 2.4 | Windows 10 (1803) | GPU paravirtualization, IOMMU, HDR improvements | | 2.5 | Windows 10 (1809) | DirectX Raytracing (DXR), HDR brightness compensation | | 2.6 | Windows 10 (1903) | Hardware-accelerated GPU scheduling, variable rate shading | | 2.7 | Windows 10 (2004) | Mesh shaders, DXR 1.1, sampler feedback | | 3.0 | Windows 11 (21H2) | WSL GPU support, Direct3D 12 video encoding | | 3.1 | Windows 11 (22H2) | Shader Model 6.7, IOMMU DMA remapping | | 3.2 | Windows 11 (24H2) | Shader Model 6.8, work graphs, generic programs | **Anmerkungen:** - Die Tabelle listet **2.8 und 2.9 nicht**, obwohl beide real existieren — die `DXGKRNL_INTERFACE`-Doku referenziert explizit „Supported starting with **WDDM 2.8**" (`DxgkCbNotifyCursorSupportChange`) und „**WDDM 2.9**" (`DxgkCbCreatePhysicalMemoryObject` u.a.). Die Übersichtstabelle ist hier also unvollständig. (Beleg: DXGKRNL_INTERFACE-Seite, s.o.) In der Praxis: 2.8 = Win10 20H2/21H1, 2.9 = Win10 21H2 — ⚠️ **diese Zuordnung 2.8/2.9→Release habe ich NICHT belegen können.** - Die Seite „Version Numbers for WDDM Drivers" (https://learn.microsoft.com/en-us/windows-hardware/drivers/display/version-numbers-for-windows-vista-display-drivers) ist **nicht** die WDDM-Feature-Level-Tabelle, sondern regelt die `DriverVer`-INF-Versionsstrings zur DirectX-Kompatibilität (WDDM+DX9: `7.14.x`, WDDM+DX10: `7.15.x`, XDDM+DX9: `6.14.x`). Häufige Verwechslungsquelle. ### „Ein WDDM-2.x-Treiber auf einem Windows mit WDDM 3.x" **Mechanismus (belegt):** Der Treiber deklariert seine DDI-Version selbst in `DRIVER_INITIALIZATION_DATA.Version` (= `DXGKDDI_INTERFACE_VERSION`), und `Dxgkrnl` teilt seine Version über `DXGKRNL_INTERFACE.Version` mit — beides aus `D3dukmdt.h`, Werte von `DXGKDDI_INTERFACE_VERSION_VISTA` aufwärts. Dxgkrnl kennt damit den DDI-Stand des Treibers und ruft nur die Callbacks auf, die dieser Stand definiert. Belege: DxgkInitialize-Seite und DXGKRNL_INTERFACE-Seite (beide oben). Dass die Struktur **additiv gewachsen** ist (jedes Member mit „Supported starting with WDDM 2.4 / 2.6 / 3.1" annotiert, ältere Member unverändert am selben Offset), ist auf der DXGKRNL_INTERFACE-Seite direkt sichtbar und ist die strukturelle Grundlage der Abwärtskompatibilität. **Praktische Bedeutung:** Ein WDDM-2.x-Treiber läuft auf Windows 11 (WDDM 3.x) — er nutzt dann eben nur den 2.x-Funktionsumfang; WDDM-3.x-Features (z.B. Work Graphs, D3D12 Video Encoding) stehen nicht zur Verfügung. Umgekehrt gilt das **nicht**: ein 3.x-Treiber setzt einen 3.x-fähigen Dxgkrnl voraus. ⚠️ **Ehrlichkeitsvorbehalt:** Ich habe **keine** Microsoft-Seite gefunden, die den Satz „ältere WDDM-Treiber laufen garantiert auf neueren Windows-Versionen" *explizit als Policy* formuliert. Belegt ist nur die Versionsaushandlung über die `Version`-Member und die additive Struktur. Gegenläufig dokumentiert Microsoft für *Feature-Interfaces*: „Feature interfaces **aren't required to be backwards compatible** with older versions of the same interface" (https://learn.microsoft.com/en-us/windows-hardware/drivers/display/querying-wddm-feature-support-and-enablement) — das betrifft die neueren, optionalen Feature-Interfaces, nicht die Kern-DDI. --- ## (4) Laden eines Treibers zur Laufzeit ### Kerneltreiber = Dienst vom Typ `SERVICE_KERNEL_DRIVER` **Quelle:** https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-createservicea > „If the service type is **SERVICE_KERNEL_DRIVER** or SERVICE_FILE_SYSTEM_DRIVER, the name is the **driver object name** that the system uses to load the device driver." > „The `CreateService` function creates a service object and installs it in the service control manager database by creating a key with the same name as the service under `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services`." Also: SCM-Datenbank == Registry-Key `HKLM\SYSTEM\CurrentControlSet\Services\` mit Werten `Type` (Diensttyp) und `Start` (boot / system / automatic / demand / disabled). ### `ZwLoadDriver` **Quelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwloaddriver > „**ZwLoadDriver** dynamically loads a device or file system driver into the currently running system." > Parameter: „a path to the driver's registry key, `\Registry\Machine\System\CurrentControlSet\Services\`" ### `DriverEntry` **Quelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/driverentry-s-optional-responsibilities > „The **DriverEntry** routine's `RegistryPath` parameter points to a counted Unicode string that specifies a path to the driver's registry key, `\Registry\Machine\System\CurrentControlSet\Services\DriverName`." ### INF `AddService` **Quelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-addservice-directive Die INF-Datei registriert den Treiber als Dienst über die `AddService`-Direktive (im `DDInstall.Services`-Abschnitt), die u.a. `ServiceType`, `StartType`, `ServiceBinary` setzt — das ist der deklarative Weg, um genau den oben beschriebenen `Services`-Key anzulegen. ### Ablauf (Synthese aus obigen Belegen) 1. **INF-Datei** beschreibt Hardware-IDs (`[Manufacturer]`/`[Models]`) und via `AddService` den Kerneldienst. 2. **PnP-Manager** erkennt das Gerät, matcht Hardware-ID gegen INFs im Driver Store, installiert das Paket und legt den `Services`-Key an. 3. **Laden:** Beim Boot bzw. bei Geräteankunft lädt der Kernel das Image; ein manueller/dynamischer Ladevorgang geht über `StartService()` (User Mode, SCM) bzw. `ZwLoadDriver()` (Kernel). 4. **Kernel-Loader (`ntoskrnl`)** mappt das PE-Image in den Kernel-Adressraum, löst Importe auf und ruft **`DriverEntry(DriverObject, RegistryPath)`**. 5. Beim WDDM-Display-Miniport ruft `DriverEntry` seinerseits **`DxgkInitialize()`** und übergibt die `DxgkDdi*`-Funktionstabelle an Dxgkrnl (Abschnitt 2). ⚠️ Punkt 4 („ntoskrnl mappt das PE-Image, löst Importe auf, ruft DriverEntry") habe ich **nicht mit einer einzelnen Learn-Seite belegt** — es folgt implizit aus den `DriverEntry`- und `ZwLoadDriver`-Seiten, ist aber dort nicht so ausformuliert. Sachlich korrekt, formal unbelegt. --- ## (5) Signaturpflicht **Hauptquelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- ### Die zentrale Regel — ab Windows 10, Version 1607 > „**Starting with Windows 10, version 1607, Windows will not load any new kernel-mode drivers which are not signed by the Dev Portal.** To get your driver signed, first Register for the Windows Hardware Dev Center program. Note that an **EV code signing certificate is required to establish a dashboard account**." **Wichtige Präzisierung:** Das EV-Zertifikat dient dem **Aufbau/Nachweis des Dashboard-Accounts** — die eigentlich gültige Signatur auf dem Treiber ist die **Microsoft-Signatur des Dev Portals**. Das EV-Zertifikat allein macht einen Treiber nicht ladbar. Bestätigend: https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-attestation — „To submit binaries for attestation signing, your Hardware Dev Center dashboard account must have at least one EV certificate associated with it." ### Zwei Signierwege | Weg | Anforderung | Ziel | |---|---|---| | **WHQL / HLK** | volle HLK-Testpässe, Logs pro Windows-Version, gemerged mit der neuesten HLK, Einreichung im Dashboard | Produktionstreiber, alle Windows-Versionen | | **Attestation Signing** | **kein HLK-Testing nötig**, nur EV-Cert + Dashboard-Submission | „For testing on **Windows 10 client only** systems" | Zitat: „For production drivers, you should submit HLK/HCK test logs… For testing on Windows 10 client only systems, you can submit your drivers for attestation signing, **which does not require HLK testing**." ### Ausnahmen — wann Cross-Signing noch akzeptiert wird (wörtlich) > „Cross-signed drivers are still permitted if any of the following are true: > - The PC was **upgraded** from an earlier release of Windows to Windows 10, version 1607. > - **Secure Boot is off** in the BIOS. > - Driver was signed with an end-entity certificate **issued prior to July 29th 2015** that chains to a supported cross-signed CA." Plus: „To prevent systems from failing to boot properly, **boot drivers will not be blocked**, but they will be removed by the Program Compatibility Assistant." ### Vor 1607 — klassisches KMCS > „Before Windows 10, version 1607, the following types of drivers require an **Authenticode certificate used together with Microsoft's cross-certificate for cross-signing**: Kernel-mode device drivers; User-mode device drivers; Drivers that stream protected content (PUMA, PAP, PVP-OPM)." ### Signaturmatrix (Original-Tabelle) | | Vista, Win7; Win8+ mit **Secure Boot aus** | Win8, 8.1, Win10 1507/1511 mit Secure Boot an | Win10 1607/1703/1709 mit Secure Boot an | Win10 **1803+** mit Secure Boot an | |---|---|---|---|---| | **Architekturen** | nur 64-bit, **32-bit ohne Signaturzwang** | 64-bit **und 32-bit** | 64-bit und 32-bit | 64-bit und 32-bit | | **Signatur** | embedded oder Katalogdatei | embedded oder Katalog | embedded oder Katalog | embedded oder Katalog | | **Algorithmus** | SHA2 | SHA2 | SHA2 | SHA2 | | **Zertifikat** | Standard-Roots, die Code Integrity vertraut | Standard-Roots | **Microsoft Root Authority 2010 / Microsoft Root Certificate Authority / Microsoft Root Authority** | dieselben MS-Roots | **Explizite Notiz aus der Quelle:** „Note that **Secure Boot does not apply to Windows Vista and Windows 7**." → **KMCS ab Vista x64** ist über die erste Tabellenspalte belegt („64-bit only, no signature required for 32-bit"). Der Wechsel von „beliebige vertrauenswürdige Roots" zu „nur Microsoft-Roots" passiert bei **1607 mit Secure Boot an** — genau die Durchsetzung der Dev-Portal-Regel. ### Cross-Signing heute abgeschafft **Quelle:** https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing > Cross-signing wird nicht mehr akzeptiert; „Using cross certificates to sign kernel-mode drivers is a violation of the Microsoft Trusted Root Program (TRP) policy." Und: „If you sign a kernel-mode driver with an EV certificate **after the issuing cross-certificate expires**, the resulting driver **doesn't load, run, or install**." ### PnP-Installationssignatur (zusätzlich!) > „In addition to driver code signing, you also need to meet the **PnP device installation signing requirements** for installing a driver." https://learn.microsoft.com/en-us/windows-hardware/drivers/install/pnp-device-installation-signing-requirements--windows-vista-and-later- Also **zwei getrennte Hürden**: (a) Code Integrity beim Laden des Images, (b) PnP-Signatur beim Installieren des Pakets. ### HVCI ⚠️ **NICHT BELEGT in dieser Recherche.** Ich habe die HVCI-Treiberkompatibilitätsanforderungen (Memory Integrity / hypervisor-enforced code integrity: keine W+X-Sections, keine ausführbaren Pool-Allokationen, `NX`-Compliance) **nicht** über eine Learn-Quelle verifiziert. Die oben zitierte Signing-Policy-Seite erwähnt HVCI nicht. Bitte separat gegen `learn.microsoft.com/windows-hardware/design/device-experiences/oem-hvci-enablement` prüfen, bevor du das als Fakt verwendest. --- ## Nicht belegbare Punkte — Zusammenfassung 1. **BDD-Einführungsversion** — kein Release explizit genannt; „Windows 8" ist plausibel, nicht belegt. 2. **WDDM 2.8 / 2.9 → Windows-Release-Zuordnung** — Versionen existieren nachweislich (DXGKRNL_INTERFACE), Release-Mapping fehlt in der offiziellen Tabelle. 3. **Explizite MS-Policy-Aussage zur WDDM-Abwärtskompatibilität** — nur der Mechanismus (Version-Member, additive Struktur) ist belegt, nicht die Garantie. 4. **`D3DDDI`-Funktionsliste im Detail** — Rolle belegt, Referenzseite nicht abgerufen. 5. **ntoskrnl PE-Mapping-Detail** — sachlich korrekt, aber nicht wörtlich in einer Learn-Seite gefunden. 6. **HVCI-Regeln** — gar nicht verifiziert. 7. **docs.kernel.org** — du hattest diese Quelle gewünscht; sie war für diese fünf Windows-spezifischen Fragen nicht einschlägig und wurde daher nicht herangezogen. Falls du einen Linux-DRM/KMS-Vergleich willst, sag Bescheid — das wäre eine eigene Recherche. --- ## Quellen - [Microsoft Basic Display Driver](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/microsoft-basic-display-driver) - [WDDM Overview (Versionstabelle)](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-display-driver-model-design-guide) - [WDDM Architecture](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-architecture) - [DxgkInitialize](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dispmprt/nf-dispmprt-dxgkinitialize) - [DRIVER_INITIALIZATION_DATA](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dispmprt/ns-dispmprt-_driver_initialization_data) - [DXGKRNL_INTERFACE](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dispmprt/ns-dispmprt-_dxgkrnl_interface) - [Version Numbers for WDDM Drivers (DriverVer, ≠ WDDM-Level)](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/version-numbers-for-windows-vista-display-drivers) - [Querying WDDM Feature Support and Enablement](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/querying-wddm-feature-support-and-enablement) - [Driver Signing Policy](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-) - [Attestation Sign Windows Drivers](https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-attestation) - [Cross-Certificates for Kernel Mode Code Signing](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing) - [PnP device installation signing requirements](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/pnp-device-installation-signing-requirements--windows-vista-and-later-) - [CreateService (winsvc.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-createservicea) - [ZwLoadDriver](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwloaddriver) - [DriverEntry's Optional Responsibilities](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/driverentry-s-optional-responsibilities) - [INF AddService Directive](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-addservice-directive) - [DirectX WARP](https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp) --- ### Teilaufgabe 2: RECHERCHE LINUX-KERNELMODULE. Belege mit Quellen (URLs, docs.kernel.org, kernel.org Git, LWN). Beantworte praezise: (1) Was ist eine .ko-Datei technisch genau? (ELF64 relocatable object, ET_REL, welche Sektionen: .text, .modinfo, .gnu.linkonce.this_module, __ksymtab/__ksymtab_gpl, .rela.*). (2) insmod/modprobe: der Systemaufruf init_module/finit_module, was der Kernel dann tut (module_load: Sektionen kopieren, Relokationen aufloesen mit apply_relocate_add fuer x86-64: R_X86_64_64, R_X86_64_PC32, R_X86_64_32S, PLT32, Symbole gegen die Kernel-Symboltafel binden via resolve_symbol/find_symbol, dann init-Funktion aufrufen). (3) vermagic: was steht genau drin (Kernelversion, SMP, preempt, gcc-Version, Modulversion?), wo (Sektion .modinfo), was passiert bei Nichtuebereinstimmung (ENOEXEC 'version magic ... should be ...'), und MODVERSIONS/CRC-Pruefsummen je Symbol. (4) Die POLITIK 'Linux has no stable in-kernel ABI' - Quelle: Documentation/process/stable-api-nonsense.rst - zitiere die Kernaussagen woertlich. (5) EXPORT_SYMBOL vs EXPORT_SYMBOL_GPL und MODULE_LICENSE, was 'tainted kernel' bedeutet. (6) NVIDIAs proprietaerer Treiber: warum er aus einem QUELLOFFENEN 'kernel interface layer' (nvidia.ko aus nv-kernel.o_binary + kompilierten Glue-Quellen) besteht, der bei jeder Installation gegen den laufenden Kernel neu uebersetzt wird (DKMS), und warum das der direkte Beweis dafuer ist, dass es keine stabile ABI gibt. Gib zu JEDER Aussage die Quell-URL. Wenn du etwas nicht belegen kannst, sage das ausdruecklich. # Linux-Kernelmodule (.ko) — Recherchebericht mit Quellen --- ## 1) Was ist eine .ko-Datei technisch genau? Eine `.ko` ist **kein ausführbares Programm**, sondern ein **ELF-Objekt vom Typ `ET_REL`** (relocatable object), auf x86-64 ELF64/LSB. Es ist im Prinzip das, was der Compiler als `.o` ausspuckt, plus einer vom Kernel-Build erzeugten Zusatzdatei `.mod.o`, die dazugelinkt wird. Der Kernel prüft beim Laden explizit den ELF-Header (Magic, Klasse, `e_type == ET_REL`, Architektur) und liefert sonst `-ENOEXEC` — siehe `elf_validity_cache_copy()` / `elf_validity_check()` in `kernel/module/main.c`: https://github.com/torvalds/linux/blob/master/kernel/module/main.c Relevante Sektionen: | Sektion | Inhalt | |---|---| | `.text`, `.data`, `.bss`, `.rodata` | normaler Code/Daten des Moduls | | `.init.text` / `.exit.text` | Init-/Exit-Code (Init wird nach dem Laden freigegeben) | | `.modinfo` | NUL-getrennte `key=value`-Strings: `vermagic=`, `name=`, `license=`, `srcversion=`, `depends=`, `author=`, `description=`, `parm=`, `retpoline=`, `import_ns=` … | | `.gnu.linkonce.this_module` | die `struct module`-Instanz `__this_module` des Moduls | | `__ksymtab`, `__ksymtab_gpl` | vom Modul selbst **exportierte** Symbole | | `__kcrctab`, `__kcrctab_gpl` | CRC-Prüfsummen zu den exportierten Symbolen (nur bei `CONFIG_MODVERSIONS`) | | `__versions` (bzw. `____versions[]`) | CRCs der vom Modul **benötigten** Symbole | | `.rela.text`, `.rela.data`, `.rela.*` | Relokationseinträge (x86-64 nutzt RELA, mit Addend) | | `.symtab`, `.strtab` | Symboltabelle (undefinierte Symbole = Kernel-Symbole, die aufgelöst werden müssen) | Belegt durch `scripts/mod/modpost.c`, das die `.mod.c` generiert — wörtlich aus dem Code (`add_header()`): ```c buf_printf(b, "__visible struct module __this_module\n"); buf_printf(b, "__section(\".gnu.linkonce.this_module\") = {\n"); buf_printf(b, "\t.name = KBUILD_MODNAME,\n"); ``` sowie `MODULE_INFO(name, ...)`, `MODULE_INFO(srcversion, "%s")`, `MODULE_INFO(depends, "...")`, `.init`/`.exit`-Zeiger, und bei `CONFIG_MODVERSIONS` die Arrays `____versions[]` (CRC + Symbolname) bzw. `____version_ext_crcs[]` / `____version_ext_names[]` für lange Symbolnamen. Quelle: https://github.com/torvalds/linux/blob/master/scripts/mod/modpost.c Export-Mechanik in `include/linux/export.h`: `EXPORT_SYMBOL(sym)` → `__EXPORT_SYMBOL(sym, "", ns)`, `EXPORT_SYMBOL_GPL(sym)` → License-String `"GPL"`. Der Eintrag wird per Assembler in eine Sektion geschrieben (`.section ".export_symbol","a"`), mit `.asciz license`, Namespace-String und Symbolreferenz; der Linker sortiert das in `__ksymtab`/`__ksymtab_gpl` ein. Quelle: https://github.com/torvalds/linux/blob/master/include/linux/export.h --- ## 2) insmod/modprobe → Syscall → was der Kernel tut **Syscalls:** `init_module(void *module_image, unsigned long len, const char *param_values)` und `finit_module(int fd, const char *param_values, int flags)`. Modernes `modprobe`/`insmod` (kmod) nutzt `finit_module()`, weil der Kernel die Datei dann selbst per fd liest (nötig u. a. für Signaturprüfung). Die Manpage sagt zur Funktion wörtlich: die Syscalls laden das ELF-Image und *"performs any necessary symbol relocations, initializes module parameters to values provided by the caller, and then runs the module's init function."* Quelle: https://man7.org/linux/man-pages/man2/init_module.2.html `ENOEXEC` u. a., wenn *"The binary image supplied in module_image is not an ELF image, or is an ELF image that is invalid or for a different architecture."* (ebd.) Flags für `finit_module`: `MODULE_INIT_IGNORE_MODVERSIONS`, `MODULE_INIT_IGNORE_VERMAGIC` (das ist das, was `insmod -f` bzw. `modprobe --force` macht → Taint-Flag `F`). (ebd.) **Ablauf im Kernel (`load_module()` in `kernel/module/main.c`):** 1. `elf_validity_check()` / `elf_validity_cache_copy()` — ELF-Header, `ET_REL`, Sektionsindizes für `.modinfo`, `.gnu.linkonce.this_module`, `__versions` etc. cachen. Dabei die Konsistenzprüfung, dass die `struct module` im Modul dieselbe Größe hat wie die des Kernels: ```c pr_err("module %s: .gnu.linkonce.this_module section size " "must match the kernel's built struct module size\n", ...); ``` 2. `check_modinfo()` — `vermagic`, `license`, Namespaces prüfen (Details unter Punkt 3). 3. `layout_and_allocate()` / `move_module()` — Speicher (Core-/Init-Bereich) allozieren, `SHF_ALLOC`-Sektionen dorthin kopieren, `sh_addr` auf die finalen Kernel-Adressen setzen. 4. `simplify_symbols()` → `resolve_symbol_wait()` → `resolve_symbol()` → `find_symbol()` — jedes undefinierte Symbol wird gegen die Kernel-Symboltafel (`__ksymtab` des Kernels + der bereits geladenen Module) aufgelöst; dabei CRC-Check (`check_version()`) und GPL-Check. Nicht auflösbar → `-ENOENT` („Unknown symbol …“). 5. `apply_relocations()` → **`apply_relocate_add()`** (arch-spezifisch) — schreibt die aufgelösten Adressen in den kopierten Code. 6. `post_relocation()`, `complete_formation()` (RO/NX-Schutz setzen, Modul in die Liste einhängen), Parameter aus `param_values` parsen. 7. `do_init_module()` ruft die Init-Funktion: ```c if (mod->init != NULL) ret = do_one_initcall(mod->init); ``` Danach wird der `.init`-Speicher freigegeben. Quelle für alle Codezitate: https://github.com/torvalds/linux/blob/master/kernel/module/main.c **Relokationen x86-64** (`arch/x86/kernel/module.c`, Funktion `__write_relocate_add()`, aufgerufen aus `apply_relocate_add()`). Behandelte Typen: - `R_X86_64_NONE` — no-op - `R_X86_64_64` — 8 Byte, absolut (`val = sym->st_value + rel[i].r_addend`) - `R_X86_64_32` — 4 Byte absolut, **unsigned** Overflow-Check - `R_X86_64_32S` — 4 Byte absolut, **signed** Overflow-Check - `R_X86_64_PC32` und `R_X86_64_PLT32` — 4 Byte PC-relativ (`val -= (u64)loc`); PLT32 wird auf x86-64 im Kernel wie PC32 behandelt, weil es keine PLT gibt - `R_X86_64_PC64` — 8 Byte PC-relativ Fehlermeldungen wörtlich aus dem Code: ``` overflow in relocation type %d val %llx sec %u idx %d `%s' likely not compiled with -mcmodel=kernel %s: Unknown rela relocation: %llu x86/modules: Invalid relocation target, existing value is nonzero for sec %u, idx %u, type %d, loc %lx, val %llx ``` Quelle: https://github.com/torvalds/linux/blob/master/arch/x86/kernel/module.c (Hintergrund `-mcmodel=kernel`: Module müssen in die oberen 2 GB des Adressraums gelinkt werden, damit die 32-Bit-Relokationen `32S`/`PC32` überhaupt passen — daher der Overflow-Hinweis.) --- ## 3) vermagic und MODVERSIONS **Was drinsteht** — `include/linux/vermagic.h`, `VERMAGIC_STRING` ist eine Konkatenation aus: - `UTS_RELEASE` — Kernelversion, aus `` (z. B. `6.12.0-rc1-custom`) - `MODULE_VERMAGIC_SMP` — `"SMP "` wenn `CONFIG_SMP`, sonst leer - `MODULE_VERMAGIC_PREEMPT` — `"preempt_rt "` / `"preempt "` / leer - `MODULE_VERMAGIC_MODULE_UNLOAD` — `"mod_unload "` wenn `CONFIG_MODULE_UNLOAD` - `MODULE_VERMAGIC_MODVERSIONS` — `"modversions "` wenn `CONFIG_MODVERSIONS` - `MODULE_ARCH_VERMAGIC` — arch-spezifisch, aus `` - `MODULE_RANDSTRUCT` — RANDSTRUCT-Seed, wenn aktiv Quelle: https://github.com/torvalds/linux/blob/master/include/linux/vermagic.h **Wichtige Korrektur zur Fragestellung:** Eine **gcc-Version steht im heutigen `VERMAGIC_STRING` nicht drin** — sie ist in der oben zitierten Definition nicht enthalten. (In sehr alten Kerneln, 2.4/frühe 2.6-Ära, war eine Compiler-Kennung Teil des vermagic; **das kann ich hier nicht mit einer Primärquelle belegen** und markiere es ausdrücklich als unbelegt.) Ebenso ist die *Modulversion* (`MODULE_VERSION()`) **nicht** Teil von vermagic — die steht separat als `version=` in `.modinfo`. **Wo:** als String `vermagic=<...>` in der Sektion `.modinfo`, eingefügt von `modpost` in die generierte `.mod.c`. Sichtbar mit `modinfo foo.ko` oder `strings -a foo.ko | grep vermagic`. Quelle: https://github.com/torvalds/linux/blob/master/scripts/mod/modpost.c **Bei Nichtübereinstimmung** — `check_modinfo()` in `kernel/module/main.c`: ```c if (!same_magic(modmagic, vermagic, info->index.vers)) { pr_err("%s: version magic '%s' should be '%s'\n", info->name, modmagic, vermagic); return -ENOEXEC; } ``` → Der Syscall scheitert mit **`ENOEXEC`**, im dmesg steht die Zeile `version magic '…' should be '…'`. Quelle: https://github.com/torvalds/linux/blob/master/kernel/module/main.c `same_magic()` in `kernel/module/version.c`: **wenn das Modul CRCs mitbringt** (`has_crcs`, also MODVERSIONS), wird bei beiden Strings per `strcspn(amagic, " ")` bis zum ersten Leerzeichen vorgespult — d. h. **der Versions-Präfix (`UTS_RELEASE`) wird ignoriert** und nur der Rest (SMP/preempt/mod_unload/arch) verglichen. Bei MODVERSIONS übernimmt die eigentliche Kompatibilitätsprüfung die CRC-Ebene. Quelle: https://github.com/torvalds/linux/blob/master/kernel/module/version.c **MODVERSIONS / CRC pro Symbol** (`check_version()`, `kernel/module/version.c`): - Für jedes benötigte Symbol steht im Modul ein CRC im `__versions`-Array; der Kernel vergleicht ihn mit dem CRC des exportierten Symbols (`__kcrctab`). - Der CRC ist eine Prüfsumme über die **erweiterte Typsignatur** des Symbols (Rückgabetyp, Argumenttypen, rekursiv aufgelöste Struct-Definitionen), erzeugt von `genksyms`. Ändert sich ein Feld in einer Struktur, die in der Signatur vorkommt, ändert sich der CRC → Modul wird abgelehnt. - Kein CRC vom exportierenden Modul: `"Exporting module didn't supply crcs? OK, we're already tainted."` → akzeptiert. - Symbol ohne Version im Modul: `pr_warn("%s: no symbol version for %s\n", ...)` → **tolerant**, gibt 1 zurück. - CRC-Mismatch: `"Found checksum %X vs module %lX\n"`, dann `pr_warn("%s: disagrees about version of symbol %s\n", ...)` → **0**, Modul wird abgelehnt (`-ENOEXEC`). Quelle: https://github.com/torvalds/linux/blob/master/kernel/module/version.c --- ## 4) „Linux has no stable in-kernel ABI" — Originalzitate Quelle: **`Documentation/process/stable-api-nonsense.rst`** → https://docs.kernel.org/process/stable-api-nonsense.html Wörtliche Kernaussagen: > **"Linux does not have a binary kernel interface, nor does it have a stable kernel interface."** > **"You think you want a stable kernel interface, but you really do not, and you don't even know it."** Die drei Begründungen für die Unmöglichkeit eines stabilen **Binär**-Interfaces, wörtlich: > **"Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures."** > **"Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel: different structures can contain different fields."** > **"Linux runs on a wide range of different processor architectures. There is no way that binary drivers from one architecture will run on another properly."** Und die vorgeschlagene Lösung, wörtlich: > **"Get your kernel driver into the main kernel tree … If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place."** Ergänzend, LWN „On binary drivers and stable interfaces" (2005) zur Position der Entwickler: *"The kernel API can and does change; that aspect of the kernel is not going away."* — und Torvalds 1999: *"I want people to know that when they use binary-only modules, it's THEIR problem."* Quelle: https://lwn.net/Articles/159313/ --- ## 5) EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL, MODULE_LICENSE, tainted kernel **Export-Makros** (`include/linux/export.h`, https://docs.kernel.org/core-api/symbol-namespaces.html): - `EXPORT_SYMBOL(sym)` → Symbol landet in `__ksymtab`, License-String `""` — für **alle** Module verfügbar. - `EXPORT_SYMBOL_GPL(sym)` → `__ksymtab_gpl`, License-String `"GPL"` — nur für Module mit GPL-kompatibler `MODULE_LICENSE`. - Zusätzlich: `EXPORT_SYMBOL_NS()` / `MODULE_IMPORT_NS()` (Namespaces) und `EXPORT_SYMBOL_FOR_MODULES()` (nur für benannte In-Tree-Module). - Quellen: https://github.com/torvalds/linux/blob/master/include/linux/export.h , https://docs.kernel.org/core-api/symbol-namespaces.html **Durchsetzung beim Laden** — in `resolve_symbol()`: ```c if (fsa.license == GPL_ONLY) mod->using_gplonly_symbols = true; ``` Ein Nicht-GPL-Modul, das ein `_GPL`-Symbol referenziert, bekommt „Unknown symbol … (err -EACCES)" bzw. das Symbol wird nicht gefunden. Quelle: https://github.com/torvalds/linux/blob/master/kernel/module/main.c **MODULE_LICENSE** — steht als `license=` in `.modinfo`. Als GPL-kompatibel gelten u. a. `"GPL"`, `"GPL v2"`, `"GPL and additional rights"`, `"Dual BSD/GPL"`, `"Dual MIT/GPL"`, `"Dual MPL/GPL"`. Nicht kompatibel: `"Proprietary"` — und **fehlende oder unbekannte Lizenz gilt als proprietär**. In `module_license_taint_check()`: ```c if (!license_is_gpl_compatible(license)) add_taint_module(mod, TAINT_PROPRIETARY_MODULE, LOCKDEP_NOW_UNRELIABLE); ``` Quelle: https://github.com/torvalds/linux/blob/master/kernel/module/main.c **Tainted kernel** — Definition laut Doku: Der Kernel wird markiert, wenn Ereignisse eintreten, *"[that] might be relevant later when investigating problems"*. Das Flag bleibt **dauerhaft** gesetzt, auch wenn das Modul wieder entladen wird. Entwickler ignorieren Bugreports von getainteten Kerneln oft, weil das Problem vom auslösenden Ereignis herrühren kann. Relevante Flags: | Flag | Bit | Bedeutung | |---|---|---| | `P` (statt `G`) | 0 | *"any proprietary module has been loaded"* — Modul ohne erkannte/GPL-kompatible `MODULE_LICENSE` | | `F` | 1 | Modul mit `insmod -f` force-geladen (vermagic/modversions übergangen) | | `O` | 12 | out-of-tree / extern gebautes Modul | | `E` | 13 | unsigniertes Modul in einem Kernel mit Modulsignaturen | Abfragbar via `/proc/sys/kernel/tainted` (0 = untainted, sonst Bitmaske). Quelle: https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html Praktische Konsequenz: Ein NVIDIA-System zeigt typischerweise `P` **und** `O` (`taint 4097` o. ä.), und GPL-only-Funktionen (z. B. viele Scheduler-, dma-buf-, tracing-Interna) sind für das proprietäre `nvidia.ko` schlicht nicht linkbar. --- ## 6) NVIDIA: warum ein quelloffener „kernel interface layer" existiert **NVIDIAs eigene Doku sagt es wörtlich** (README, Kapitel „Installing the NVIDIA Driver"): > **"The NVIDIA kernel module has a kernel interface layer that must be compiled specifically for each kernel. NVIDIA distributes the source code to this kernel interface layer."** > **"After the correct kernel interface has been compiled, the kernel interface will be linked with the closed-source portion of the NVIDIA kernel module."** > **"When `nvidia-installer` runs, it searches for a pre-compiled kernel interface layer for the target kernel: if one is found, then the complete kernel module can be produced by linking the precompiled interface with `nv-kernel.o`, instead of needing to compile the kernel interface on the target system."** Quelle: https://download.nvidia.com/XFree86/Linux-x86/384.59/README/installdriver.html **Aufbau:** - `nv-kernel.o_binary` — der OS-agnostische, **binäre, geschlossene** Kern. Er enthält keine Kernel-Symbolreferenzen, sondern ruft nur NVIDIAs eigene Abstraktionsschicht (`nv_*`/`os_*`-Funktionen) auf. - `kernel-open/` bzw. `nv*.c`, `nv-linux.h`, … — der **quelloffene Glue-Code**, der diese Abstraktion auf echte Kernel-APIs abbildet (`vmalloc`, `pci_*`, `dma_*`, `remap_pfn_range`, DRM/KMS-Hooks …). Dieser Teil wird bei jeder Installation gegen die Header des laufenden Kernels frisch übersetzt und dann mit `nv-kernel.o` zu `nvidia.ko` **gelinkt** (`ld -r`). - Analog für `nvidia-modeset.ko` (`nv-modeset-kernel.o_binary`), plus `nvidia-uvm.ko` und `nvidia-drm.ko`. Dieselbe Zweiteilung gilt auch für die *offenen* Module: Repo-Struktur `kernel-open/` = *"the component of each kernel module that is specific to the Linux kernel version and configuration"*, `src/` = *"the component of each kernel module that is independent of operating system"*. Quelle: https://github.com/NVIDIA/open-gpu-kernel-modules **`conftest.sh`** — der Beweis in Reinform: Vor dem Kompilieren läuft ein autoconf-artiges Skript, das gegen die Header des Zielkernels hunderte Mini-Testprogramme übersetzt, um festzustellen, **ob** eine bestimmte Kernelfunktion existiert, **wie viele Argumente** sie nimmt und **welchen Typ** sie zurückgibt. Ergebnis sind generierte Header unter `conftest/`, die den Glue-Code per `#if defined(NV_...)` umschalten. Quellen: https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/conftest.sh , https://deepwiki.com/NVIDIA/open-gpu-kernel-modules/2.1-kbuild-configuration **DKMS** — Dynamic Kernel Module Support: Modulquellen liegen mit einer `dkms.conf` im DKMS-Baum; bei jedem Kernel-Update wird das Modul für die neue Kernelversion neu gebaut und installiert. Deshalb heißt das Paket `nvidia-dkms-`. Quelle: https://github.com/dell/dkms *(Anmerkung: Der Satz „rebuilds automatically on kernel upgrade" ließ sich aus der GitHub-Landingpage nicht wörtlich zitieren — er ergibt sich aus der Distributions-Integration via Kernel-Postinst-Hooks. Als wörtliches Zitat markiere ich das ausdrücklich als **nicht belegt**.)* **Warum das der direkte Beweis für „keine stabile ABI" ist:** 1. Wäre die In-Kernel-ABI stabil, könnte NVIDIA ein einziges vorkompiliertes `nvidia.ko` ausliefern, das auf jedem Kernel lädt. Genau das ist unmöglich — daher die Zweiteilung. 2. Der geschlossene Teil ist so konstruiert, dass er **die Kernel-ABI nie direkt berührt**; alles, was die ABI berührt, muss Quellcode sein und neu übersetzt werden. Das ist eine Ingenieurslösung, die exakt um das Nichtvorhandensein einer stabilen ABI herumgebaut wurde. 3. `conftest.sh` misst die ABI zur Buildzeit empirisch nach, weil sie sich zwischen Kernelversionen ändert — genau die Situation, die `stable-api-nonsense.rst` beschreibt (*"different structures can contain different fields"*, Compiler- und Config-Abhängigkeit). 4. `vermagic` + MODVERSIONS-CRCs erzwingen das technisch: Selbst ein perfekt gebautes `.ko` lädt nach einem Kernel-Update nicht mehr (`version magic '…' should be '…'`, ENOEXEC), weshalb DKMS überhaupt existieren muss. 5. Nebeneffekt: Weil `MODULE_LICENSE` beim proprietären Treiber nicht GPL-kompatibel ist, sind `EXPORT_SYMBOL_GPL`-Symbole gesperrt und der Kernel wird `P`-tainted — die Lizenz-Grenze ist zusätzlich zur ABI-Grenze durchgesetzt. Der Wechsel zu den *open* GPU kernel modules (MIT/GPLv2, Turing+, GSP-Firmware nötig) ändert an Punkt 1–4 **nichts** — auch sie werden per DKMS gebaut. NVIDIA empfiehlt sie inzwischen: *"We recommend the use of open kernel modules on all GPUs that support it."* Quelle: https://download.nvidia.com/XFree86/Linux-x86_64/580.95.05/README/kernel_open.html --- ## Nicht belegbare Punkte (ausdrücklich markiert) - **gcc-Version in vermagic:** in der aktuellen `vermagic.h` **nicht** enthalten. Dass sie in alten Kerneln (2.4/frühes 2.6) Teil des Magic-Strings war, konnte ich mit keiner Primärquelle belegen. - **`ET_REL`-Prüfung:** aus `kernel/module/main.c` (`elf_validity_check`) rekonstruiert, aber nicht als wörtliches Codezitat aus einem Fetch bestätigt. - **`nv-kernel.o_binary` als exakter Dateiname im aktuellen proprietären Treiber:** belegt über NVIDIA-README (384.59) und Suchergebnisse; für die *aktuellste* Treiberversion nicht direkt aus einer NVIDIA-Seite verifiziert. - **DKMS „automatisches Rebuild bei Kernel-Upgrade":** kein wörtliches Zitat aus der Projektquelle gefunden. - **`ld -r`-Linkschritt:** aus der Beschreibung „linked with the closed-source portion" abgeleitet, nicht wörtlich belegt. --- **Sources:** - [Documentation/process/stable-api-nonsense.rst](https://docs.kernel.org/process/stable-api-nonsense.html) - [Symbol Namespaces (docs.kernel.org)](https://docs.kernel.org/core-api/symbol-namespaces.html) - [Tainted kernels (docs.kernel.org)](https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html) - [kernel/module/main.c](https://github.com/torvalds/linux/blob/master/kernel/module/main.c) - [kernel/module/version.c](https://github.com/torvalds/linux/blob/master/kernel/module/version.c) - [arch/x86/kernel/module.c](https://github.com/torvalds/linux/blob/master/arch/x86/kernel/module.c) - [include/linux/vermagic.h](https://github.com/torvalds/linux/blob/master/include/linux/vermagic.h) - [include/linux/export.h](https://github.com/torvalds/linux/blob/master/include/linux/export.h) - [scripts/mod/modpost.c](https://github.com/torvalds/linux/blob/master/scripts/mod/modpost.c) - [init_module(2) / finit_module(2) man page](https://man7.org/linux/man-pages/man2/init_module.2.html) - [LWN: On binary drivers and stable interfaces](https://lwn.net/Articles/159313/) - [LWN: Monitoring the internal kernel ABI](https://lwn.net/Articles/800452/) - [NVIDIA README — Installing the NVIDIA Driver](https://download.nvidia.com/XFree86/Linux-x86/384.59/README/installdriver.html) - [NVIDIA README — Open kernel modules](https://download.nvidia.com/XFree86/Linux-x86_64/580.95.05/README/kernel_open.html) - [NVIDIA/open-gpu-kernel-modules](https://github.com/NVIDIA/open-gpu-kernel-modules) - [conftest.sh](https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/conftest.sh) - [Kbuild Configuration (DeepWiki)](https://deepwiki.com/NVIDIA/open-gpu-kernel-modules/2.1-kbuild-configuration) - [dell/dkms](https://github.com/dell/dkms) --- ### Teilaufgabe 3: RECHERCHE TREIBER IM USERSPACE (Ring 3) und Signaturpflicht bei anderen Systemen. Belege mit Quellen. (1) Linux UIO (Userspace I/O): was uio_pci_generic kann, wie eine Unterbrechung an ein Programm zugestellt wird (read() auf /dev/uioX), wie MMIO gemappt wird (mmap auf /dev/uioX), und die ausdrueckliche Einschraenkung: UIO kann KEIN sicheres DMA. Quelle: Documentation/driver-api/uio-howto.rst. (2) VFIO: was es zusaetzlich kann, warum es eine IOMMU braucht, was eine IOMMU-Gruppe ist, der 'unsafe interrupts'-Schalter, und der Satz aus der Doku warum ohne IOMMU DMA unsicher ist. Quelle: Documentation/driver-api/vfio.rst. (3) DPDK/SPDK als reale Nutzer von Ring-3-Treibern fuer Netz und Speicher - welche Kosten/Nutzen werden dort genannt (Polling statt Interrupts, kein Kontextwechsel pro Paket, aber CPU-Kern voll belegt). (4) Mikrokerne: wie machen es seL4, QNX, MINIX3 und Google Fuchsia/Zircon - Treiber im Userspace, Neustart eines abgestuerzten Treibers, und was ein IOMMU-loses System dabei NICHT garantieren kann. (5) macOS: DriverKit/DEXT als Ablösung von KEXTs ab macOS 10.15 - Treiber laufen im Userspace, Apple signiert. Nenne konkret was Apple dazu sagt. Gib zu JEDER Aussage die Quell-URL. Wenn du etwas nicht belegen kannst, sage das ausdruecklich. # Treiber im Userspace (Ring 3) und Signaturpflicht — Rechercheergebnis **Vorbemerkung zur Belegqualität:** Ich kennzeichne unten explizit, wo eine von dir vermutete Aussage in der genannten Quelle *nicht* wörtlich steht. Zwei deiner Annahmen halten der Quellenprüfung nicht stand (UIO-DMA-Satz, `allow_unsafe_interrupts` in vfio.rst) — Details jeweils unter „⚠ Nicht belegbar". --- ## 1) Linux UIO (Userspace I/O) Quelle: `Documentation/driver-api/uio-howto.rst` → https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html · Rohtext: https://raw.githubusercontent.com/torvalds/linux/master/Documentation/driver-api/uio-howto.rst **uio_pci_generic** > „The generic driver is a kernel module named uio_pci_generic. It can work with any device compliant to PCI 2.3 (circa 2002) and any compliant PCI Express device." > „Interrupts are handled using the Interrupt Disable bit in the PCI command register and Interrupt Status bit in the PCI status register." > „uio_pci_generic detects this support, and won't bind to devices which do not support the Interrupt Disable Bit in the command register." → Folge: uio_pci_generic kann **nur Legacy-INTx**, keine MSI/MSI-X. Es macht ausschließlich zweierlei: Interrupt maskieren/quittieren und die BARs zum Mappen freigeben. Die eigentliche Gerätelogik liegt komplett in Ring 3. **Interrupt-Zustellung — `read()` auf `/dev/uioX`** > „A blocking `read()` from `/dev/uioX` will return as soon as an interrupt occurs." > „`/dev/uioX` is a read-only file. A `read()` will always block until an interrupt occurs. There is only one legal value for the `count` parameter of `read()`, and that is the size of a signed 32 bit integer (4)." > „The signed 32 bit integer read is the interrupt count of your device. If the value is one more than the value you read the last time, everything is OK." → Der Interrupt wird also **nicht** als Signal/Callback zugestellt, sondern als aufsteigender Zähler über einen blockierenden `read()` (alternativ `select()`/`poll()`). Verlorene Interrupts erkennt man an einer Lücke im Zähler. **MMIO-Mapping — `mmap()` auf `/dev/uioX`** > „To map the memory of mapping N, you have to use N times the page size as your offset: `offset = N * getpagesize();`" > „Remember that pointers returned by `mmap()` are always page aligned, so it is good style to always add this offset." (gemeint: `offset` aus `/sys/class/uio/uioX/maps/mapN/offset`) > „After you successfully mapped your devices memory, you can access it like an ordinary array." → Der Offset-Parameter von `mmap()` wird hier **zweckentfremdet als Map-Index**, nicht als Byte-Offset. Danach ist das BAR ein normaler Zeiger im Prozessadressraum — Ring 3 spricht direkt mit der Hardware. **⚠ Nicht belegbar wie von dir formuliert:** In `uio-howto.rst` steht **kein** ausdrücklicher Satz „UIO kann kein sicheres DMA". Das Dokument thematisiert DMA-Sicherheit schlicht **gar nicht**; die einzige DMA-Erwähnung betrifft `uio_dmem_genirq`: „In particular, being able to access memory made available through the dma-mapping API, may be particularly useful." Die Aussage „UIO hat keinen IOMMU-Schutz" ist stattdessen **an anderer Stelle** belegt: - `vfio.rst`: UIO/ähnliche Ansätze haben „no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space." → https://www.kernel.org/doc/html/latest/driver-api/vfio.html - DPDK: „Using UIO drivers is inherently unsafe due to this method lacking IOMMU protection, and can only be done by root user." → https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html **Fazit UIO:** Sobald ein UIO-Prozess Bus-Mastering aktiviert, kann das Gerät ohne IOMMU in **beliebigen** physischen Speicher schreiben. Der Ring-3-Prozess hat damit faktisch Kernel-Gewalt — die Ring-3-Schranke ist umgangen, nicht durchgesetzt. --- ## 2) VFIO Quelle: `Documentation/driver-api/vfio.rst` → https://www.kernel.org/doc/html/latest/driver-api/vfio.html **Was VFIO zusätzlich kann / warum IOMMU** > „Many modern systems now provide DMA and interrupt remapping facilities to help ensure I/O devices behave within the boundaries they've been allotted." > „DMA is by far the most critical aspect for maintaining a secure environment as allowing a device read-write access to system memory imposes the greatest risk to the overall system integrity." → Das ist der von dir gesuchte Kernsatz: **ohne IOMMU ist DMA unsicher, weil das Gerät Lese-/Schreibzugriff auf den Systemspeicher bekommt** — das größte Risiko für die Systemintegrität. VFIO liefert gegenüber UIO: IOMMU-erzwungene DMA-Isolation, vollen MSI/MSI-X-Support, geregelten Zugriff auf PCI-Config-Space, und Nutzung ohne Dauer-Root. **IOMMU-Gruppe** > „A group is a set of devices which is isolatable from all other devices in the system. Groups are therefore the unit of ownership used by VFIO." Granularitätsgrenzen laut Doku: Multifunktionsgeräte mit internen „Backdoors" zwischen den Funktionen, Bridges ohne **ACS** (Access Control Services), sowie PCIe-zu-PCI-Bridges, die die Identität der dahinterliegenden Geräte maskieren. → Praxisfolge: Du kannst nie ein einzelnes Gerät durchreichen, sondern immer nur die **ganze Gruppe**. **No-IOMMU-Modus** > „VFIO also supports a no-IOMMU mode, intended for usages where unsafe DMA can be performed by userspace drivers w/o physical IOMMU protection." Schalter: `/sys/module/vfio/parameters/enable_unsafe_noiommu_mode`; Gerätedateien erscheinen dann als `/dev/vfio/noiommu-Y` bzw. `/dev/vfio/devices/noiommu-vfioX`. (Dieser Modus taintet den Kernel und ist bewusst als „unsafe" benannt.) **⚠ Korrektur zu deinem „unsafe interrupts"-Schalter:** `allow_unsafe_interrupts` steht **nicht** in `vfio.rst`. Es ist ein Modulparameter von `vfio_iommu_type1` und im Quelltext belegt → https://raw.githubusercontent.com/torvalds/linux/master/drivers/vfio/vfio_iommu_type1.c > MODULE_PARM_DESC: „Enable VFIO IOMMU support for on platforms without interrupt remapping support." — Default `false`. Der Prüfcode in `vfio_iommu_type1_attach_group()`: ```c if (!allow_unsafe_interrupts && !iommu_group_has_isolated_msi(iommu_group)) { pr_warn("%s: No interrupt remapping support. Use the module param " "\"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n", __func__); ret = -EPERM; ``` → Ohne **Interrupt-Remapping** verweigert VFIO die Gruppenanbindung mit `-EPERM`. Grund: Ein DMA-fähiges Gerät kann MSIs fälschen, indem es in den MSI-Adressbereich schreibt, und so beliebige Interrupt-Vektoren auf der CPU auslösen. `allow_unsafe_interrupts=1` schaltet genau diese Schutzprüfung ab. Ergänzend DPDK zur Praxis: „If there is no IOMMU available on the system, VFIO can still be used, but it has to be loaded with an additional module parameter." / „Since no-IOMMU mode forgoes IOMMU protection, it is inherently unsafe." → https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html --- ## 3) DPDK / SPDK — reale Ring-3-Treiber für Netz und Speicher **DPDK (Netz)** — https://doc.dpdk.org/guides/prog_guide/overview.html > „Poll Mode Drivers (PMDs) for 1 GbE, 10 GbE and 40 GbE, and para virtualized virtio Ethernet controllers which are designed to work without asynchronous, interrupt-based signaling mechanisms." > „Most of the sample applications use a polling mode for performance but some of the samples use an interrupt driven model that is useful for saving power but has additional performance overhead." → Der zweite Satz ist der ehrlichste Beleg für die Kosten/Nutzen-Bilanz: Interrupt-Modell = **stromsparend, aber langsamer**; Polling = schnell, aber der Kern dreht durch. Ergänzend: „In addition to the run-to-completion model, a pipeline model may also be used by passing packets or messages between cores via the rings." — Kerne werden also fest zugewiesen, nicht geteilt. Bindung an UIO/VFIO ist bei DPDK Pflicht (https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html): VFIO braucht „both kernel and BIOS must support and be configured to use IO virtualization (such as Intel® VT-d)"; bei UIO-Bindung dagegen „please make sure that the IOMMU is disabled or is in passthrough mode" — d.h. **man schaltet den Schutz bewusst ab**, um Durchsatz zu bekommen. **SPDK (Speicher/NVMe)** — https://spdk.io/doc/about.html > „Moving all of the necessary drivers into userspace, which avoids syscalls and enables zero-copy access from the application." > „Polling hardware for completions instead of relying on interrupts, which lowers both total latency and latency variance." > „Avoiding all locks in the I/O path, instead relying on message passing." **Kosten/Nutzen-Bilanz (Synthese aus obigen Zitaten):** | | Nutzen | Preis | |---|---|---| | Polling statt Interrupts | niedrigere Latenz **und** geringere Latenz-Varianz (SPDK) | Kern läuft dauerhaft auf 100 %, auch bei 0 Paketen/s; „additional performance overhead" nur beim Interrupt-Modell (DPDK) | | Treiber in Ring 3 | keine Syscalls, Zero-Copy in die Anwendung (SPDK); kein Kernel-Netzwerkstack | Gerät braucht DMA → ohne IOMMU „inherently unsafe" (DPDK) | | Lockfreiheit / Queue pro Kern | keine Synchronisationskosten | Kerne sind exklusiv gebunden, nicht mehr für andere Last verfügbar | ⚠ Der oft zitierte Satz „kein Kontextwechsel pro Paket" steht in dieser Wortwahl **nicht** wörtlich in den DPDK-Kerndokumenten, die ich geprüft habe. Belegbar ist nur die schwächere, aber gleichbedeutende SPDK-Formulierung „avoids syscalls" plus DPDKs „designed to work without asynchronous, interrupt-based signaling mechanisms". Ich führe die „kein Kontextwechsel"-Formulierung daher als **Ableitung, nicht als Zitat**. --- ## 4) Mikrokerne **seL4** — https://sel4.systems/About/FAQ.html > „seL4, like any real microkernel, runs all device drivers in user mode." > „Device support must be provided by user-level code." (im Kernel nur Timer für Preemption + Vermittlung des Interrupt-Controllers; Serial-Treiber nur in Debug-Builds) Und — das ist der entscheidende Punkt für deine Frage nach dem, was ein IOMMU-loses System **nicht** garantieren kann: > „The formal verification of seL4 assumes that the MMU has complete control over memory, which means the proof assumes that DMA is off." > „You can still use DMA devices safely, but you have to separately assure that they are well-behaved … drivers and hardware for DMA devices need to be trusted." → seL4 bietet (unverifizierte) Konfigurationen mit ARM System-MMU bzw. x86 VT-d, um DMA einzuschränken, ohne den Treiber vertrauen zu müssen. **Ohne IOMMU fällt der DMA-fähige Treiber wieder in die Trusted Computing Base zurück — der mathematische Beweis deckt ihn nicht ab.** Das ist die sauberste Formulierung des Prinzips, die ich in allen fünf Systemen gefunden habe. **QNX Neutrino** — https://www.qnx.com/products/intl/neutrino_rtos/ · https://www.qnx.com/developers/docs/6.5.0SP1/neutrino/sys_arch/kernel.html > „Every driver, protocol stack, filesystem, and application runs in the safety of memory-protected user space, outside the kernel. If a component should fail, it can usually be automatically restarted without affecting other components or the kernel." > „a faulty driver isn't likely to crash the OS, and you can usually stop and restart a driver without rebooting the system." ⚠ Zu QNX habe ich **keine** offizielle Aussage zu IOMMU/DMA-Grenzen gefunden — die Doku spricht nur von MMU-Speicherschutz. Nicht belegt. **MINIX 3** — https://wiki.minix3.org/doku.php?id=www:documentation:reliability > „In MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform I/O, or write to absolute memory." > „A special process, called the reincarnation server, periodically pings each device driver. If the driver dies or fails to respond correctly to pings, the reincarnation server automatically replaces it by a fresh copy." > „In MINIX 3, when a user expects data from, for example, the file system, it builds a descriptor telling who has access and at what addresses." ⚠ Die MINIX3-Zuverlässigkeitsseite behandelt **DMA/IOMMU nicht**. Der Schutz beruht auf Kernel-Berechtigungsprüfungen und Deskriptoren — nicht auf Hardware-DMA-Schutz. Ein DMA-fähiges Gerät unter einem kompromittierten MINIX3-Treiber ohne IOMMU wäre also durch diese Mechanismen **nicht** eingefangen. (Das ist meine Schlussfolgerung aus dem Fehlen jeder DMA-Aussage, kein Zitat.) **Fuchsia / Zircon** — https://fuchsia.dev/fuchsia-src/concepts/kernel · https://fuchsia.dev/fuchsia-src/concepts/drivers/driver_framework · https://fuchsia.dev/fuchsia-src/reference/kernel_objects/bus_transaction_initiator > „Zircon is composed of a kernel … as well as a small set of userspace services, drivers, and libraries … necessary for the system to boot, talk to hardware, load userspace processes and run them." - Treiber sind **User-Space-Komponenten**; sie werden als Shared Libraries in **Driver-Host-Prozessen** geladen. „Driver host is a binary that is launched by driver manager to host one or more drivers. It facilitates sandboxing of drivers." - Neustart nach Absturz: das Feld `host_restart_on_crash` „tells the driver framework that it should restart the driver host for the node that the driver binds to should the driver go down unexpectedly." Ist es `false`, wird der Node stattdessen aus der Topologie entfernt. Setzbar nur vom Root-Treiber des Hosts. - DMA-Kapselung über **BTI-Objekte**: „Bus Transaction Initiators (BTIs) represent the bus mastering/DMA capability of a device, and can be used for granting a device access to memory." — „A bus transaction ID in this context is a hardware transaction identifier that may be used by an IOMMU (e.g. PCI addresses on Intel's IOMMU and StreamIDs on ARM's SMMU)." Speicher muss über die BTI **gepinnt** werden, der Aufrufer erhält geräte-physische Adressen. → Zircon ist damit das System, das die IOMMU **am direktesten in seine Kernel-Objekt-Abstraktion eingebaut** hat: DMA-Recht ist ein Capability-Objekt, kein Nebeneffekt. ⚠ Was die offizielle BTI-Referenzseite **nicht** sagt: wie sich BTIs auf Systemen ganz ohne IOMMU verhalten (ein „dummy IOMMU" ist dort nicht dokumentiert). Nicht belegt. **Gemeinsamer Nenner (4):** Alle vier Systeme isolieren Treiber per MMU und können sie neu starten. Aber **keines davon kann ohne IOMMU garantieren, dass ein bus-mastering-fähiges Gerät die Isolation respektiert** — seL4 sagt das als einziges ausdrücklich und mathematisch präzise („the proof assumes that DMA is off"). Der MMU-Schutz gilt für die *CPU*-Sicht des Treibers, nicht für die *Geräte*-Sicht. --- ## 5) macOS: DriverKit / DEXT statt KEXT **Was Apple sagt (wörtlich):** - „Drivers built with DriverKit run in user space, rather than as kernel extensions, for improved system security and stability." → https://support.apple.com/guide/security/driverkit-security-for-macos-secd0a47c14c/web - „system extensions and drivers built with DriverKit run in user space, where they can't compromise the security or stability of macOS" → https://support.apple.com/guide/deployment/system-extensions-in-macos-depa5fb8376f/web - „The user downloads the app (installers aren't necessary when using system extensions or DriverKit), and the extension is enabled only when required." (Apple Platform Security) - **Signatur-/Freigabepflicht:** „To deploy drivers built with DriverKit or use the EndpointSecurity API, you'll need an entitlement from Apple." → https://developer.apple.com/support/kernel-extensions/ (Antragsformular: https://developer.apple.com/contact/request/system-extension/) - **KEXT-Abschaltung:** „Starting with macOS Big Sur, macOS releases no longer load kernel extensions that use deprecated kernel programming interfaces (KPIs) by default." — „Any kernel extension using an unsupported KPI will not load." — Ausnahme: „Kernel extension deprecation policies are not enforced when SIP is disabled or if a kernel extension is approved through a MDM profile." **Zeitleiste laut Apples Deprecation-Tabelle** (alles https://developer.apple.com/support/kernel-extensions/): | KEXT-Familie | Status | Ersatz (Userspace) | |---|---|---| | IOHIDFamily | deprecated 10.15 Catalina, **unsupported** Big Sur 11.0 | HIDDriverKit | | IOUSBFamily | deprecated seit 10.11, unsupported Big Sur | USBDriverKit / IOUSBHost / DriverKit | | USB Networking | deprecated 10.15, unsupported Big Sur | NetworkingDriverKit | | USB Serial | deprecated 10.15, unsupported Big Sur | SerialDriverKit / USBSerialDriverKit | | **PCI Networking** | deprecated 10.15, unsupported Big Sur | PCIDriverKit + NetworkingDriverKit | | Network Filter / Socket KPIs | deprecated 10.15, unsupported Big Sur | NetworkExtension | | KAUTH | deprecated 10.15, unsupported Big Sur | EndpointSecurity | | IOAudioFamily | deprecated 12.3 Monterey | AudioDriverKit | | IOSCSIParallelFamily | deprecated 12.3 Monterey | SCSIControllerDriverKit | **Der entscheidende Punkt für deine Fragestellung:** Apple ersetzt die *Kernel*-Schranke durch eine *Signatur*-Schranke. Ein DEXT läuft in Ring 3 — aber er ist kein freier Ring-3-Prozess: Er braucht ein von Apple **einzeln beantragtes und individuell gewährtes** Entitlement, das in die Signatur eingebacken wird. Wer ohne Apples Freigabe einen PCI- oder USB-Treiber schreiben will, kommt weder in den Kernel (KPI abgeschaltet) noch in DriverKit (Entitlement fehlt). Die Sicherheit stützt sich also auf **zwei** Säulen: Userspace-Isolation *plus* zentral kontrollierte Signatur. ⚠ **Nicht belegbar:** Apple dokumentiert öffentlich **nicht**, ob und wie DriverKit-DMA per IOMMU (DART auf Apple Silicon, VT-d auf Intel) eingeschränkt wird. Die DriverKit-Security-Seite erwähnt IOMMU/DMA mit keinem Wort. Eine Aussage „PCIDriverKit-Treiber sind DMA-isoliert" kann ich aus Apple-Primärquellen **nicht** stützen. --- ## Querschnitt-Fazit 1. **Ring 3 allein reicht nicht.** Die MMU schützt vor dem, was die *CPU* im Treiberprozess tut. DMA umgeht die MMU vollständig. Der einzige Satz, der das in einer Primärquelle auf den Punkt bringt, ist aus `vfio.rst`: „allowing a device read-write access to system memory imposes the greatest risk to the overall system integrity." 2. **UIO = Bequemlichkeit, VFIO = Sicherheit.** UIO gibt dir `read()` für Interrupts und `mmap()` für MMIO — mehr nicht, und ohne jeden DMA-Schutz. VFIO fügt IOMMU-Gruppen, MSI/MSI-X und Interrupt-Remapping-Zwang hinzu. Beide Schutzstufen lassen sich per Modulparameter abschalten (`enable_unsafe_noiommu_mode`, `allow_unsafe_interrupts`) — und genau das tut die Performance-Praxis (DPDK-Doku empfiehlt für UIO ausdrücklich IOMMU „disabled or in passthrough mode"). 3. **Die Mikrokerne lösen Verfügbarkeit, nicht DMA.** Neustart abgestürzter Treiber ist bei QNX, MINIX3 (Reincarnation Server) und Fuchsia (`host_restart_on_crash`) belegt. Aber seL4 sagt als einziges offen, wo die Garantie endet: „the proof assumes that DMA is off." 4. **Apple ersetzt Ring-0-Vertrauen durch Signatur-Vertrauen.** DEXTs laufen in Ring 3, aber nur mit einem von Apple erteilten Entitlement — die Gatekeeper-Funktion wandert vom Kernel zur Zertifizierungsstelle. **Sources:** - [Linux UIO HOWTO (HTML)](https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html) · [uio-howto.rst (Rohtext)](https://raw.githubusercontent.com/torvalds/linux/master/Documentation/driver-api/uio-howto.rst) - [Linux VFIO Doku](https://www.kernel.org/doc/html/latest/driver-api/vfio.html) · [vfio.rst (Rohtext)](https://raw.githubusercontent.com/torvalds/linux/master/Documentation/driver-api/vfio.rst) · [vfio_iommu_type1.c](https://raw.githubusercontent.com/torvalds/linux/master/drivers/vfio/vfio_iommu_type1.c) - [DPDK Overview](https://doc.dpdk.org/guides/prog_guide/overview.html) · [DPDK Linux Drivers (UIO/VFIO)](https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html) · [DPDK ethdev](https://doc.dpdk.org/guides/prog_guide/ethdev/ethdev.html) - [SPDK About](https://spdk.io/doc/about.html) - [seL4 FAQ](https://sel4.systems/About/FAQ.html) - [QNX Neutrino RTOS Overview](https://www.qnx.com/products/intl/neutrino_rtos/) · [QNX Neutrino Microkernel](https://www.qnx.com/developers/docs/6.5.0SP1/neutrino/sys_arch/kernel.html) - [MINIX 3 Reliability](https://wiki.minix3.org/doku.php?id=www:documentation:reliability) - [Zircon Kernel](https://fuchsia.dev/fuchsia-src/concepts/kernel) · [Fuchsia Driver Framework (DFv2)](https://fuchsia.dev/fuchsia-src/concepts/drivers/driver_framework) · [Fuchsia BTI](https://fuchsia.dev/fuchsia-src/reference/kernel_objects/bus_transaction_initiator) - [Apple: Deprecated Kernel Extensions](https://developer.apple.com/support/kernel-extensions/) · [Apple: DriverKit security for macOS](https://support.apple.com/guide/security/driverkit-security-for-macos-secd0a47c14c/web) · [Apple: System extensions in macOS](https://support.apple.com/guide/deployment/system-extensions-in-macos-depa5fb8376f/web) · [Apple: DriverKit Framework](https://developer.apple.com/documentation/driverkit) --- ### Teilaufgabe 4: RECHERCHE: GIBT ES HERSTELLERTREIBER FUER FREMDE BETRIEBSSYSTEME? Belege mit Quellen. Beantworte: (1) Haben NVIDIA oder AMD jemals GPU-Treiber fuer ein Hobby-/Nischenbetriebssystem herausgegeben (Haiku, ReactOS, SerenityOS, Redox, FreeBSD, Solaris/illumos)? Was gibt es tatsaechlich (NVIDIA FreeBSD-Treiber? AMDGPU auf FreeBSD?) und was gibt es nachweislich nicht. (2) Wie loesen Haiku, ReactOS, SerenityOS, Redox OS und FreeBSD das Grafikproblem konkret? (VESA/GOP Framebuffer als Grundlage, eigene Treiber, ReactOS' Ziel Windows-Treiberkompatibilitaet - klappt das wirklich?). (3) Welche freien, eigenen Modesetting-Treiber sind realistisch machbar: Bochs/QEMU VGA (Register 0x1CE/0x1CF, 'Bochs VBE'), VMware SVGA II, virtio-gpu, Intel GMA/i915 Modesetting, und wie gross ist so ein Treiber ungefaehr (Zeilen Code)? Quellen fuer die Bochs-VBE-Registerschnittstelle. (4) Wie gross ist der Aufwand fuer einen echten NVIDIA-/AMD-Modesetting-Treiber - was sagen die Entwickler von Nouveau bzw. amdgpu ueber Firmware-Signaturen (NVIDIA GSP/falcon signed firmware) und warum Nouveau bei modernen Karten ohne signierte Firmware nicht hochtakten kann. Gib zu JEDER Aussage die Quell-URL. Sage ausdruecklich, was du NICHT belegen kannst. # Herstellertreiber für fremde Betriebssysteme — Rechercheergebnis **Stand: 2026-09-02.** Jede Aussage mit Quelle. Nicht-Belegbares ist am Ende explizit markiert. --- ## (1) Herstellertreiber für Nischen-OS ### Was es NACHWEISLICH GIBT **NVIDIA → FreeBSD: JA, offiziell und aktiv.** NVIDIA pflegt eine eigene Treiberlinie „FreeBSD Display Driver – x64". Belegt bis Version **570.172.08** ([nvidia.com/en-us/drivers/details/249293](https://www.nvidia.com/en-us/drivers/details/249293/)), davor u.a. 565.57.01 (22.10.2024, [Link](https://www.nvidia.com/download/driverResults.aspx/234347/en-us/)) und 535.171.04 ([Link](https://www.nvidia.com/Download/driverResults.aspx/223760/en-us/)). Es existiert eine vollwertige FreeBSD-README-Doku inkl. GSP-Firmware-Kapitel: „Firmware files are built into `nvidia_gsp_*_fw.ko` and installed in `/boot/modules`" und „The GSP firmware will be used by default for all Turing and later GPUs" ([download.nvidia.com/XFree86/FreeBSD-x86_64/560.28.03/README/gsp.html](https://download.nvidia.com/XFree86/FreeBSD-x86_64/560.28.03/README/gsp.html)). **NVIDIA → Solaris: JA, historisch, zuletzt Beta.** „Solaris Display Driver – x64/x86" existiert offiziell, belegt bis **545.23.06** (Beta, 17.10.2023, [nvidia.com/en-us/drivers/details/212965](https://nvidia.com/en-us/drivers/details/212965)) sowie 460.80 ([Link](https://www.nvidia.com/en-us/drivers/details/175206/)). Eigene SunOS-README existiert ([us.download.nvidia.com/solaris/455.23.04/README/index.html](https://us.download.nvidia.com/solaris/455.23.04/README/index.html)). Oracle dokumentiert die Integration seitens Solaris ([docs.oracle.com/cd/E53394_01/html/E54838/gpokh.html](https://docs.oracle.com/cd/E53394_01/html/E54838/gpokh.html)). → **NVIDIA ist die große Ausnahme.** Es ist der einzige GPU-Hersteller mit nachweisbaren Erstanbieter-Treibern für Nicht-Linux/Nicht-Windows-Unixe. ### Was es NACHWEISLICH NICHT GIBT **AMD → FreeBSD: KEIN offizieller AMD-Treiber.** `amdgpu` auf FreeBSD ist ein **Community-Port des Linux-Codes**, nicht von AMD gepflegt. Die DRM-Treiber werden „ported from Linux to FreeBSD using linuxkpi" ([freshports.org/graphics/drm-kmod](https://www.freshports.org/graphics/drm-kmod/)), Repository unter [github.com/freebsd/drm-kmod](https://github.com/freebsd/drm-kmod). LinuxKPI ist explizit als Kompatibilitätsschicht beschrieben, die „allows Linux drivers to run in a FreeBSD environment with minor modification" ([cdaemon.com/posts/pwS7dVqV](https://cdaemon.com/posts/pwS7dVqV), [freebsddesktop.github.io/2018/12/08/drm-kmod-primer.html](https://freebsddesktop.github.io/2018/12/08/drm-kmod-primer.html)). Firmware-Blobs separat: [github.com/freebsd/drm-kmod-firmware](https://github.com/freebsd/drm-kmod-firmware). **Haiku, ReactOS, SerenityOS, Redox: KEINE Herstellertreiber — von niemandem.** Ich habe in der gesamten Recherche **keinen einzigen** von NVIDIA oder AMD veröffentlichten Treiber für eines dieser Systeme gefunden. Der „accelerated NVIDIA graphics driver" in Haiku ist ein Community-/Reverse-Engineering-Treiber von Rudolf Cornelissen (BeOS-Erbe), nicht von NVIDIA ([rudolfs-place.nl/BeOS/NVdriver/nvidia.html](http://rudolfs-place.nl/BeOS/NVdriver/nvidia.html), [github.com/haiku/haiku/…/graphics/nvidia/UPDATE.html](https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/graphics/nvidia/UPDATE.html), Berichterstattung: [osnews.com/story/144097](https://www.osnews.com/story/144097/haiku-gets-accelerated-nvidia-graphics-driver/)). --- ## (2) Wie lösen die Systeme das Grafikproblem konkret? ### Haiku — Firmware-Framebuffer + eigene Modesetting-Treiber Zweistufig: eigene Treiber `intel_extreme` ([Quelle](https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/graphics/intel_extreme/intel_extreme.cpp)) und `radeon_hd` ([Quelle](https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/graphics/radeon_hd/driver.cpp)), mit **Fallback auf VESA/Framebuffer**. Der `app_server` „uses accelerant loading logic to properly fall back to the VESA or framebuffer drivers if an accelerant fails to initialize" ([haiku-os.org Activity Report Juli 2022](https://www.haiku-os.org/blog/waddlesplash/2022-08-09_haiku_activity_contract_report_july_2022/)). **Entscheidend:** Die AMD- und Intel-Treiber sind **reines Modesetting, ohne 2D/3D-Beschleunigung**; Haiku rendert in Software in einen Framebuffer, der dann ins GPU-RAM geschrieben wird ([haiku-os.org GSoC 2017 3D Acceleration](https://www.haiku-os.org/blog/vivek/2017-05-05_gsoc_2017_3d_hardware_acceleration_in_haiku)). Treibermodell = „Accelerant" (Userspace-Add-on) + Kernel-Treiber ([haiku-os.org/legacy-docs/writing-video-card-drivers/04-accelerant](https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/04-accelerant/)). Intel-Modesetting ist pro Generation dokumentiert ([haiku-os.org/docs/develop/drivers/intel_extreme/generations.html](https://www.haiku-os.org/docs/develop/drivers/intel_extreme/generations.html)). VBE ist keine sichere Bank: „VBE 3.0 is badly broken on some modern GPUs" ([discuss.haiku-os.org/t/10583](https://discuss.haiku-os.org/t/improving-the-intel-extreme-driver-was-graphics-on-dell-laptop-in-vesa-mode-only/10583)). ### ReactOS — VBE-Miniport + Ziel Windows-Treiberkompatibilität Basis ist ein eigener VBE-Miniport-Treiber (`win32ss/drivers/miniport/vbe/vbemp.c`, [Quelle](https://github.com/reactos/reactos/blob/master/win32ss/drivers/miniport/vbe/vbemp.c)) plus `vga_new` mit eigener VBE-Modus-Tabelle ([vbemodes.c](https://github.com/reactos/reactos/blob/master/win32ss/drivers/miniport/vga_new/vbemodes.c)). Im Code steht ausdrücklich, dass die VBE-1.2-Unterstützung „far from complete" ist ([doxygen.reactos.org/…/vbemp_8c_source.html](https://doxygen.reactos.org/da/dd4/vbemp_8c_source.html)). **Klappt die Windows-Treiberkompatibilität wirklich? Teilweise — und erst seit kurzem.** Der ReactOS-Entwickler „The_DarkFire_" dokumentiert im offiziellen Blog ([reactos.org/blogs/investigating-wddm](https://reactos.org/blogs/investigating-wddm/)): - ✅ Microsofts `BasicDisplay.sys` (WDK-Sample) lädt und funktioniert - ✅ Ein **NVIDIA-Windows-7-Treiber** liefert Bildausgabe „at full resolution and refresh rates" - ❌ **Keine 3D-Beschleunigung**, kein DirectX — die D3DKMT-APIs wurden vertagt („we can ignore that for now") - ❌ Fundamentale Abhängigkeit: **„XDDM is REQUIRED for WDDM, we need to continue to improve in this area"** — weil `CDD.dll`, die Brücke zwischen Win32k und WDDM, selbst ein XDDM-Treiber ist. Einordnung als „initial engineering probe" auch bei [OSnews](https://www.osnews.com/story/143552/an-initial-investigation-into-wddm-on-reactos/) und [Tom's Hardware](https://www.tomshardware.com/software/windows/as-windows-10-signs-off-reactos-devs-are-exploring-a-long-awaited-feature-in-wddm-support-investigation-could-pave-the-way-for-newer-gpu-hardware-compatibility). Es gibt auch alte Community-Anleitungen zu NVIDIA-Treibern auf ReactOS ([lists.reactos.org nv4_howto](https://lists.reactos.org/hyperkitty/list/ros-general@reactos.org/message/A75XUG34MJ7ZEH334WOLQPTFM4NFGMA5/attachment/2/nv4_howto.html)). ⚠️ **Vorsicht:** Sekundärquellen ([Slashdot, 21.03.2026](https://tech.slashdot.org/story/26/03/21/1712201/intel-nvidia-amd-gpu-drivers-finally-play-nice-with-reactos), [itsfoss](https://itsfoss.gitlab.io/post/reactos-making-progress-on-windows-wddm-driver-support/), [killbait](https://killbait.com/en/reactos-achieves-major-compatibility-with-intel-nvidia-and-amd-gpu-drivers/)) behaupten „~90 % der XP/2003-GPU-Treiber laufen" und nennen konkret GMA 945, GeForce 8800 GTS, GTX 750 Ti, Radeon HD 7530G. **Diese 90-%-Zahl konnte ich nicht am ReactOS-Primärblog verifizieren** — siehe Abschnitt „Nicht belegbar". ### SerenityOS — eigenes Graphics-Subsystem, VM-Geräte zuerst PR #6277 „Kernel: Introduce a new graphics subsystem + add basic support for Intel native graphics" ([github.com/SerenityOS/serenity/pull/6277](https://github.com/SerenityOS/serenity/pull/6277)) — getestet zunächst gegen einen ICH7-Adapter (PCI-ID `8086:29c2`). Daneben VirtIO-Unterstützung. Bekannte Probleme mit VirtualBox' `VBoxVGA` (Artefakte/Purple Screen), `VMSVGA` funktioniert besser ([Issue #7558](https://github.com/SerenityOS/serenity/issues/7558)). Bare-Metal-Betrieb ist eine bekannte Hürde ([linus.dev/posts/running-serenityos-on-bare-metal](https://linus.dev/posts/running-serenityos-on-bare-metal/), [Hackaday](https://hackaday.com/2025/01/10/serenityos-on-real-hardware/)). ### Redox OS — ehrlichste Antwort: gar keine GPU-Treiber Aus der offiziellen Doku: *„Vesad is not really a driver; it writes to a framebuffer given by firmware (via UEFI or BIOS software interrupts)"* und **„Redox doesn't have GPU drivers yet"** — Ersatz ist LLVMpipe (CPU-OpenGL). Ein DRM-Treiber müsste in Redox ein **Userspace-Daemon** sein, der über Syscalls/Schemes mit der Hardware spricht ([doc.redox-os.org/book/graphics-windowing.html](https://doc.redox-os.org/book/graphics-windowing.html)). Vorhandene Grafik-Daemons laut Treiber-README ([github.com/redox-os/drivers](https://github.com/redox-os/drivers/blob/master/README.md)): **`vesad`** (VESA), **`bgad`** (Bochs Graphics Adapter), **`virtio-gpud`** (VirtIO GPU). Genau die drei „einfachen" Ziele aus Frage 3. ### FreeBSD — Linux-Code via Shim + NVIDIA-Blob Siehe (1): `drm-kmod` portiert i915/amdgpu/radeon per LinuxKPI ([Phoronix](https://www.phoronix.com/news/DRM-Next-KMOD-On-FreeBSD-11)), NVIDIA liefert selbst. Ein Fork adressiert zusätzlich VMware VGA, QXL und virtio-gpu (alle WIP): [github.com/ravynsoft/drm-kmod](https://github.com/ravynsoft/drm-kmod). --- ## (3) Realistisch selbst machbare Modesetting-Treiber ### A) Bochs/QEMU „Bochs VBE" (BGA) — **einfachster Einstieg** Vollständige Registerschnittstelle, belegt durch **drei unabhängige Quellen**: | | Wert | Quelle | |---|---|---| | Index-Port | `0x01CE` (`VBE_DISPI_IOPORT_INDEX`) | [OSDev](https://wiki.osdev.org/Bochs_VBE_Extensions), [QEMU](https://www.qemu.org/docs/master/specs/standard-vga.html) | | Daten-Port | `0x01CF` (`VBE_DISPI_IOPORT_DATA`), alternativ `0x01D0` | dito | | PCI-ID | `1234:1111` | [QEMU-Spec](https://www.qemu.org/docs/master/specs/standard-vga.html), [OSDev](https://wiki.osdev.org/Bochs_VBE_Extensions) | | Framebuffer | „must be read from the first PCI base address register (BAR 0)" | [OSDev](https://wiki.osdev.org/Bochs_VBE_Extensions) | | MMIO-Alternative | `0x0500–0x0515`, „mapped flat without index/data ports" (nötig für legacy-free/non-x86) | [QEMU-Spec](https://www.qemu.org/docs/master/specs/standard-vga.html) | **Register-Indizes:** 0 `ID`, 1 `XRES`, 2 `YRES`, 3 `BPP`, 4 `ENABLE`, 5 `BANK`, 6 `VIRT_WIDTH`, 7 `VIRT_HEIGHT`, 8 `X_OFFSET`, 9 `Y_OFFSET`. **ENABLE-Bits:** `DISABLED=0x00`, `ENABLED=0x01`, `LFB_ENABLED=0x40`, `NOCLEARMEM=0x80`. **Ablauf Modesetting:** ENABLE←0x00 → XRES/YRES/BPP schreiben → ENABLE←`0x01|0x40`. (Alles [OSDev Bochs VBE Extensions](https://wiki.osdev.org/Bochs_VBE_Extensions)) Weitere Primärspezifikationen: [VirtualBox `vbe_display_api.txt`](https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/Graphics/BIOS/vbe_display_api.txt) und die Xen/vgabios-Kopie ([github.com/mirage/xen/…/vbe_display_api.txt](https://github.com/mirage/xen/blob/master/tools/firmware/vgabios/vbe_display_api.txt)). Kraxels Blog beschreibt das Design als „paravirtual interface with just the bare essentials… no registers for clock rate and other timing stuff" ([kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display](https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display/)) — genau deshalb ist es so klein. **Umfang:** Linux' kompletter DRM-Treiber liegt als *eine* Datei vor: `drivers/gpu/drm/tiny/bochs.c` ([Bootlin](https://elixir.bootlin.com/linux/v6.12.6/source/drivers/gpu/drm/tiny/bochs.c), [Codebrowser](https://codebrowser.dev/linux/linux/drivers/gpu/drm/tiny/bochs.c.html)). Er wurde bewusst nach `tiny/` verschoben und konsolidiert ([Patchwork](https://patchwork.kernel.org/project/dri-devel/patch/20210630140659.17623-2-tzimmermann@suse.de/)); Historie: [LWN „drm/bochs: new driver"](https://lwn.net/Articles/577366/). Größenordnung **~600 Zeilen** — ⚠️ diese Zahl stammt aus einem Suchmaschinen-Snippet, nicht aus einer von mir gezählten Datei (siehe unten). ### B) VMware SVGA II Offizielles (aber **deprecated**) Developer Kit von VMware: [vmware-svga.sourceforge.net](https://vmware-svga.sourceforge.net/) — „provides the information and code necessary to write both 2D and 3D graphics drivers". Register-Header `svga_reg.h` (VMware-Copyright 1998–2009) liegt offen vor: [prepare/vmware-svga](https://github.com/prepare/vmware-svga/blob/master/lib/vmware/svga_reg.h), [mirror/VMsvga2](https://github.com/mirror/VMsvga2/blob/master/vminclude/svga_reg.h), [VirtualBox-Kopie](https://github.com/sailfishos/virtualbox/blob/master/virtualbox/src/VBox/Devices/Graphics/vmsvga/svga_reg.h). Praxisnahe Anleitung: [OSDev VMWare SVGA-II](https://wiki.osdev.org/VMWare_SVGA-II). Mesa-Seite zum 3D-Teil: [docs.mesa3d.org/drivers/svga3d.html](https://docs.mesa3d.org/drivers/svga3d.html). **Vorteil:** VMSVGA ist Default-Grafikcontroller für Linux-Gäste in VirtualBox ([Baeldung](https://www.baeldung.com/linux/vboxvga-vmsvga-vboxsvga-virtualbox)) — hohe Reichweite. ### C) virtio-gpu Spezifiziert und dokumentiert: [qemu.org/docs/master/system/devices/virtio/virtio-gpu.html](https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html). Redox hat es als `virtio-gpud` bereits umgesetzt ([Quelle](https://github.com/redox-os/drivers/blob/master/README.md)); ein KMS-Treiber für virtio-GPU existiert auch in anderen Stacks ([LKML](https://lkml.iu.edu/1503.3/00533.html)). **Realistisch, aber aufwendiger als BGA**, da Virtqueue-Infrastruktur nötig ist. ### D) Intel GMA / i915 Modesetting Machbar, aber deutlich größer: Haiku hat es als `intel_extreme` gemacht — mit generationsspezifischer Dokumentation, weil sich das Modesetting pro Chip-Generation ändert ([haiku-os.org intel_extreme/generations](https://www.haiku-os.org/docs/develop/drivers/intel_extreme/generations.html)). Der Community-Thread dazu läuft über **24+ Seiten** ([discuss.haiku-os.org/t/10583](https://discuss.haiku-os.org/t/improving-the-intel-extreme-driver-was-graphics-on-dell-laptop-in-vesa-mode-only/10583)) — ein guter Indikator für den Realaufwand. SerenityOS' Intel-Support startete bei einem einzigen alten Chip (ICH7, [PR #6277](https://github.com/SerenityOS/serenity/pull/6277)). **Praktische Reihenfolge:** Bochs/BGA → VMware SVGA II → virtio-gpu → Intel. Genau diese Reihenfolge spiegeln Redox und SerenityOS in ihrer realen Entwicklungshistorie wider. --- ## (4) Aufwand für echte NVIDIA-/AMD-Modesetting-Treiber ### Das Firmware-Signatur-Problem (NVIDIA) Dave Airlie (Red Hat, DRM-Maintainer), zitiert von LWN ([lwn.net/Articles/910343](https://lwn.net/Articles/910343/)): - **Ab Maxwell 2 (2014)** verlangt NVIDIA signierte Firmware: *„firmware needed to be signed by NVIDIA and loaded into the multiple processors on the device."* - Der Bootvorgang erfordert das Einspielen mehrerer Firmware-Images **in exakter Reihenfolge** — laut LWN-Bericht „very hard to get right". - **Kernproblem Reclocking:** Selbst wenn alles korrekt läuft, kommt die Karte in Basiskonfiguration hoch. Airlie wörtlich: **„you can't make it reclock, you can't make it go faster."** Ohne signierte Firmware kann Nouveau die Taktdomänen/Power-Management-Zustände nicht ansteuern → die Karte bleibt auf Boot-Takt. - Folge fürs Projekt: *„disheartening for the project; there was no way that the open-source driver was ever going to be able to compete with the proprietary one"*; Nouveau wurde faktisch *„just for hardware enablement"*. ### GSP als Wendepunkt (Turing+) - GSP = GPU System Processor, **RISC-V**, eingeführt mit Turing. NVIDIA hat „much of its proprietary kernel driver into the GSP" verlagert ([LWN](https://lwn.net/Articles/910343/)). - **Firmware-Größe: ~30–40 MB**, gegenüber ~256 KB bei den früheren Blobs ([LWN](https://lwn.net/Articles/910343/)). Das ist die zentrale Zahl: Man lädt de facto einen kompletten proprietären Treiber in die Karte. - NVIDIAs eigene offene Kernelmodule bestätigen die Abhängigkeit: *„cannot support GPUs before Turing, because the open kernel modules depend on the GPU System Processor (GSP) first introduced in Turing"* ([NVIDIA README kernel_open.html](https://us.download.nvidia.com/XFree86/Linux-x86_64/575.51.02/README/kernel_open.html), [Repo](https://github.com/NVIDIA/open-gpu-kernel-modules)). - Ab Turing nutzt Nouveau die GSP-Firmware und erhält dadurch **automatisches Power-Management** — für 16xx/20xx/30xx/40xx sind Reclocking-Hacks unnötig ([github.com/ventureoo/nouveau-reclocking](https://github.com/ventureoo/nouveau-reclocking)). Ältere Karten (Maxwell 2 / Pascal) bleiben das Problemfeld. - Aktueller Leistungsvergleich Nouveau/NVK vs. proprietär: [Phoronix, GTX 980 – RTX 5080](https://www.phoronix.com/review/nvidia-980-5080-linux). - Airlies eigene Präsentation (LPC): [„nouveau: in the times of firmware" (PDF)](https://lpc.events/event/16/contributions/1202/attachments/992/1919/nouveau%20in%20the%20times%20of%20firmware.pdf) — ⚠️ konnte ich technisch nicht auslesen (siehe unten). - Zum BIOS-Signaturschloss und dessen Folgen: [Phoronix-Forum-Diskussion](https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/1404919-nvidia-bios-signature-lock-broken-what-caused-open-source-pains-for-years), PMU-Firmware-Diskussion im NVIDIA-Repo: [Discussion #277](https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/277). ### Aufwandsschätzung — die praktische Konsequenz | Ziel | Aufwand | Beleg-Indikator | |---|---|---| | Bochs/BGA | 1 Datei, ~600 Zeilen | [bochs.c in `tiny/`](https://elixir.bootlin.com/linux/v6.12.6/source/drivers/gpu/drm/tiny/bochs.c) | | VMware SVGA II | überschaubar, Spec offen | [svga_reg.h](https://github.com/prepare/vmware-svga/blob/master/lib/vmware/svga_reg.h) | | virtio-gpu | mittel (Virtqueues) | [QEMU-Doku](https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html) | | Intel Modesetting | groß, pro Generation | [Haiku generations doc](https://www.haiku-os.org/docs/develop/drivers/intel_extreme/generations.html) | | AMD amdgpu | sehr groß — deshalb portiert FreeBSD den Linux-Code statt neu zu schreiben | [drm-kmod](https://github.com/freebsd/drm-kmod) | | NVIDIA modern | **nicht sinnvoll neu schreibbar** — ohne signierte Firmware kein Reclocking; mit GSP lädt man 30–40 MB Blob | [LWN](https://lwn.net/Articles/910343/) | **Kernaussage:** Für NVIDIA ab Maxwell 2 ist der Engpass **nicht** die Codemenge, sondern eine kryptografische Sperre. Man kann die Karte zum Bild bringen, aber ohne NVIDIA-signierte Firmware nicht auf Leistung takten. Für AMD gibt es keine Signaturhürde in diesem Sinne, aber schiere Codegröße — der Grund, warum FreeBSD portiert statt neuschreibt. --- ## ⚠️ Was ich NICHT belegen kann 1. **Exakte Zeilenzahl von `bochs.c`.** Die „~600 Zeilen" stammen aus einem Suchmaschinen-Snippet; mein Abruf von Bootlin/Codebrowser lieferte nur Navigation, keinen Quelltext. **Als Größenordnung behandeln, nicht als Messwert.** Verifizierbar mit `wc -l drivers/gpu/drm/tiny/bochs.c`. 2. **Die ReactOS-„90 %"-Zahl** (~90 % der XP/2003-GPU-Treiber laufen, Slashdot 03/2026). Nur in Sekundärquellen gefunden, **nicht im ReactOS-Primärblog verifiziert**. Der Primärblog ist deutlich zurückhaltender (nur BasicDisplay + ein NVIDIA-Win7-Treiber, kein 3D). Ebenso unverifiziert: die konkrete Hardwareliste (GMA 945, 8800 GTS, 750 Ti, HD 7530G) und die Behauptung einer KMDF/WDDM-Implementierung. 3. **Airlies LPC-PDF im Wortlaut.** Der Abruf scheiterte an der PDF-Komprimierung. Alle Airlie-Zitate oben stammen aus dem LWN-Bericht über den Vortrag, nicht aus den Folien selbst. 4. **Negativbeweise generell.** Dass NVIDIA/AMD *nie* einen Treiber für Haiku/ReactOS/SerenityOS/Redox veröffentlicht haben, ist logisch nicht beweisbar. Ich habe nach gezielter Suche **keinerlei Hinweis** darauf gefunden; alle auffindbaren Treiber für diese Systeme sind Community-Arbeit. Behandle es als „mit hoher Wahrscheinlichkeit zutreffend", nicht als Beweis. 5. **Aktueller Status der NVIDIA-Solaris-Linie.** Letzter belegter Release 545.23.06 (10/2023, Beta). Ob NVIDIA die Linie seither offiziell eingestellt hat, konnte ich **nicht klären** — ich fand weder eine EOL-Ankündigung noch neuere Releases. 6. **Genauer Umfang/Status von SerenityOS' VMware-SVGA-Treiber.** Ich habe die Existenz eines dedizierten VMSVGA-Treibers im SerenityOS-Kernel **nicht** direkt am Quellcode verifiziert; belegt sind nur das Graphics-Subsystem, Intel-Basissupport und VirtIO. 7. **AMD und Solaris/illumos.** Keine belastbaren Ergebnisse — weder für noch gegen die Existenz eines offiziellen Treibers. **Ungeklärt.** --- ## Kompaktfazit - **NVIDIA ist der einzige** GPU-Hersteller mit echten Erstanbieter-Treibern für Nischen-Unixe: **FreeBSD (aktiv, bis 570.x)** und **Solaris (bis mind. 545.23.06, 2023)**. Für Hobby-OS (Haiku/ReactOS/Serenity/Redox): **nichts, von niemandem.** - **AMD liefert für FreeBSD nichts Eigenes** — `amdgpu` dort ist ein LinuxKPI-Community-Port. - **Universelle Basis aller Nischen-OS ist der Firmware-Framebuffer** (VESA/GOP). Redox sagt es am offensten: „Redox doesn't have GPU drivers yet." - **ReactOS' Windows-Treiberkompatibilität funktioniert — für Display-Output.** Ein NVIDIA-Win7-Treiber liefert native Auflösung. Kein 3D, kein DirectX, und WDDM hängt an unfertigem XDDM. - **Realistischer Selbstbau-Pfad:** Bochs/BGA (`0x1CE`/`0x1CF`, PCI `1234:1111`, ~600 Zeilen) → VMware SVGA II → virtio-gpu → Intel. Alles dokumentiert und ohne NDA machbar. - **Echter NVIDIA-Treiber scheitert nicht an Code, sondern an Kryptografie:** Ab Maxwell 2 signierte Firmware, ohne die „you can't make it reclock, you can't make it go faster" (Airlie). Ab Turing löst NVIDIAs GSP-Blob (30–40 MB) das Problem — um den Preis, dass der proprietäre Treiber jetzt in der Karte läuft. ## Sources - [NVIDIA FreeBSD Display Driver 570.172.08](https://www.nvidia.com/en-us/drivers/details/249293/) - [NVIDIA FreeBSD Display Driver 565.57.01](https://www.nvidia.com/download/driverResults.aspx/234347/en-us/) - [NVIDIA FreeBSD Display Driver 535.171.04](https://www.nvidia.com/Download/driverResults.aspx/223760/en-us/) - [NVIDIA FreeBSD README – GSP Firmware](https://download.nvidia.com/XFree86/FreeBSD-x86_64/560.28.03/README/gsp.html) - [NVIDIA Solaris Display Driver 545.23.06](https://nvidia.com/en-us/drivers/details/212965) - [NVIDIA Solaris Display Driver 460.80](https://www.nvidia.com/en-us/drivers/details/175206/) - [NVIDIA Accelerated SunOS Graphics Driver README](https://us.download.nvidia.com/solaris/455.23.04/README/index.html) - [Oracle Solaris Graphics Driver Changes](https://docs.oracle.com/cd/E53394_01/html/E54838/gpokh.html) - [FreshPorts graphics/drm-kmod](https://www.freshports.org/graphics/drm-kmod/) - [github.com/freebsd/drm-kmod](https://github.com/freebsd/drm-kmod) - [github.com/freebsd/drm-kmod-firmware](https://github.com/freebsd/drm-kmod-firmware) - [github.com/ravynsoft/drm-kmod](https://github.com/ravynsoft/drm-kmod) - [LinuxKPI: Linux Drivers on FreeBSD (cdaemon)](https://cdaemon.com/posts/pwS7dVqV) - [FreeBSD Graphics Blog – drm-kmod Primer](https://freebsddesktop.github.io/2018/12/08/drm-kmod-primer.html) - [Phoronix – LinuxKPI DRM on FreeBSD 11](https://www.phoronix.com/news/DRM-Next-KMOD-On-FreeBSD-11) - [Haiku Activity Report July 2022](https://www.haiku-os.org/blog/waddlesplash/2022-08-09_haiku_activity_contract_report_july_2022/) - [Haiku GSoC 2017 – 3D Hardware Acceleration](https://www.haiku-os.org/blog/vivek/2017-05-05_gsoc_2017_3d_hardware_acceleration_in_haiku) - [Haiku – Writing Video Card Drivers: Accelerant](https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/04-accelerant/) - [Haiku – Intel video hardware generations](https://www.haiku-os.org/docs/develop/drivers/intel_extreme/generations.html) - [Haiku intel_extreme.cpp](https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/graphics/intel_extreme/intel_extreme.cpp) - [Haiku radeon_hd driver.cpp](https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/graphics/radeon_hd/driver.cpp) - [Haiku nvidia driver UPDATE.html](https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/drivers/graphics/nvidia/UPDATE.html) - [Rudolf's Place – BeOS/Haiku NVIDIA driver](http://rudolfs-place.nl/BeOS/NVdriver/nvidia.html) - [OSnews – Haiku gets accelerated NVIDIA graphics driver](https://www.osnews.com/story/144097/haiku-gets-accelerated-nvidia-graphics-driver/) - [Haiku forum – Improving the Intel Extreme Driver](https://discuss.haiku-os.org/t/improving-the-intel-extreme-driver-was-graphics-on-dell-laptop-in-vesa-mode-only/10583) - [ReactOS Blog – An initial investigation into WDDM](https://reactos.org/blogs/investigating-wddm/) - [ReactOS vbemp.c](https://github.com/reactos/reactos/blob/master/win32ss/drivers/miniport/vbe/vbemp.c) - [ReactOS vbemodes.c](https://github.com/reactos/reactos/blob/master/win32ss/drivers/miniport/vga_new/vbemodes.c) - [ReactOS Doxygen – vbemp.c source](https://doxygen.reactos.org/da/dd4/vbemp_8c_source.html) - [ReactOS mailing list – Using NVidia drivers on ReactOS How-to](https://lists.reactos.org/hyperkitty/list/ros-general@reactos.org/message/A75XUG34MJ7ZEH334WOLQPTFM4NFGMA5/attachment/2/nv4_howto.html) - [OSnews – An initial investigation into WDDM on ReactOS](https://www.osnews.com/story/143552/an-initial-investigation-into-wddm-on-reactos/) - [Tom's Hardware – ReactOS WDDM support](https://www.tomshardware.com/software/windows/as-windows-10-signs-off-reactos-devs-are-exploring-a-long-awaited-feature-in-wddm-support-investigation-could-pave-the-way-for-newer-gpu-hardware-compatibility) - [Slashdot – Intel, NVIDIA, AMD GPU Drivers Finally Play Nice With ReactOS](https://tech.slashdot.org/story/26/03/21/1712201/intel-nvidia-amd-gpu-drivers-finally-play-nice-with-reactos) - [It's FOSS – ReactOS WDDM progress](https://itsfoss.gitlab.io/post/reactos-making-progress-on-windows-wddm-driver-support/) - [KillBait – ReactOS GPU driver compatibility](https://killbait.com/en/reactos-achieves-major-compatibility-with-intel-nvidia-and-amd-gpu-drivers/) - [SerenityOS PR #6277 – graphics subsystem + Intel native graphics](https://github.com/SerenityOS/serenity/pull/6277) - [SerenityOS Issue #7558 – VBoxVGA artifacting](https://github.com/SerenityOS/serenity/issues/7558) - [Linus Groh – Running SerenityOS on Bare Metal](https://linus.dev/posts/running-serenityos-on-bare-metal/) - [Hackaday – SerenityOS On Real Hardware](https://hackaday.com/2025/01/10/serenityos-on-real-hardware/) - [Redox Book – Graphics and Windowing](https://doc.redox-os.org/book/graphics-windowing.html) - [redox-os/drivers README](https://github.com/redox-os/drivers/blob/master/README.md) - [OSDev Wiki – Bochs VBE Extensions](https://wiki.osdev.org/Bochs_VBE_Extensions) - [QEMU – Standard VGA specification](https://www.qemu.org/docs/master/specs/standard-vga.html) - [VirtualBox – vbe_display_api.txt](https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/Graphics/BIOS/vbe_display_api.txt) - [Xen/vgabios – vbe_display_api.txt](https://github.com/mirage/xen/blob/master/tools/firmware/vgabios/vbe_display_api.txt) - [Kraxel's blog – QEMU VGA emulation and bochs-display](https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display/) - [Bootlin – drivers/gpu/drm/tiny/bochs.c](https://elixir.bootlin.com/linux/v6.12.6/source/drivers/gpu/drm/tiny/bochs.c) - [Codebrowser – bochs.c](https://codebrowser.dev/linux/linux/drivers/gpu/drm/tiny/bochs.c.html) - [Patchwork – drm/bochs: Move to tiny/](https://patchwork.kernel.org/project/dri-devel/patch/20210630140659.17623-2-tzimmermann@suse.de/) - [LWN – drm/bochs: new driver](https://lwn.net/Articles/577366/) - [VMware SVGA Device Developer Kit](https://vmware-svga.sourceforge.net/) - [OSDev Wiki – VMWare SVGA-II](https://wiki.osdev.org/VMWare_SVGA-II) - [svga_reg.h (prepare/vmware-svga)](https://github.com/prepare/vmware-svga/blob/master/lib/vmware/svga_reg.h) - [svga_reg.h (mirror/VMsvga2)](https://github.com/mirror/VMsvga2/blob/master/vminclude/svga_reg.h) - [svga_reg.h (VirtualBox)](https://github.com/sailfishos/virtualbox/blob/master/virtualbox/src/VBox/Devices/Graphics/vmsvga/svga_reg.h) - [Mesa – VMware SVGA3D](https://docs.mesa3d.org/drivers/svga3d.html) - [Baeldung – VBoxVGA vs VMSVGA vs VBoxSVGA](https://www.baeldung.com/linux/vboxvga-vmsvga-vboxsvga-virtualbox) - [QEMU – VirtIO GPU](https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html) - [LWN – NVIDIA and nouveau (Dave Airlie)](https://lwn.net/Articles/910343/) - [Dave Airlie – "nouveau: in the times of firmware" (LPC PDF)](https://lpc.events/event/16/contributions/1202/attachments/992/1919/nouveau%20in%20the%20times%20of%20firmware.pdf) - [ventureoo/nouveau-reclocking](https://github.com/ventureoo/nouveau-reclocking) - [NVIDIA/open-gpu-kernel-modules](https://github.com/NVIDIA/open-gpu-kernel-modules) - [NVIDIA README – Open Linux Kernel Modules](https://us.download.nvidia.com/XFree86/Linux-x86_64/575.51.02/README/kernel_open.html) - [NVIDIA open-gpu-kernel-modules Discussion #277 – PMU Firmware](https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/277) - [Phoronix – GTX 980 through RTX 5080: Nouveau/Mesa vs NVIDIA 580](https://www.phoronix.com/review/nvidia-980-5080-linux) - [Phoronix Forums – NVIDIA BIOS Signature Lock Broken](https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/1404919-nvidia-bios-signature-lock-broken-what-caused-open-source-pains-for-years)