Condividi tramite

Supporto dei client Kernel-Mode nei driver UMDF

  • Articolo

Questo argomento descrive come un driver di User-Mode Driver Framework (UMDF) supporta i client in modalità kernel, a partire da UMDF versione 2.

Un client in modalità kernel è un driver in modalità kernel che invia richieste di I/O al driver UMDF. Il driver in modalità kernel potrebbe essere superiore al driver UMDF, nello stesso stack di dispositivi o in uno stack di dispositivi diverso.

Il driver in modalità kernel può inoltrare le richieste di I/O ricevute da un'applicazione in modalità utente oppure creare nuove richieste di I/O e inviarle al driver in modalità utente.

Come supportare i client in modalità kernel in un driver UMDF

Per abilitare il supporto di un driver UMDF per i client in modalità kernel, il file INF del driver UMDF deve includere una direttiva UmdfKernelModeClientPolicy nella relativa DDInstall INF. Sezione WDF .

Il framework fornisce due metodi utili per i driver che supportano client in modalità kernel. Un driver può chiamare il metodo WdfRequestGetRequestorMode per determinare se una richiesta di I/O proviene dalla modalità kernel o dalla modalità utente. Se la richiesta di I/O proviene dalla modalità utente, il driver può chiamare WdfRequestIsFromUserModeDriver per determinare se la richiesta proviene da un'applicazione o da un altro driver in modalità utente.

Restrizioni sui driver in modalità kernel

Un driver UMDF può elaborare le richieste di I/O da un driver in modalità kernel solo se il driver in modalità kernel soddisfa i requisiti seguenti:

  • Il driver in modalità kernel deve essere in esecuzione in IRQL = PASSIVE_LEVEL quando invia la richiesta di I/O.

  • A meno che il driver non abbia impostato la direttiva INF UmdfFileObjectPolicy su AllowNullAndUnknownFileObjects, ogni richiesta di I/O inviata da un driver in modalità kernel a un driver in modalità utente deve avere un oggetto file associato. Il framework deve essere stato precedentemente informato che il gestore di I/O ha creato l'oggetto file. Tale notifica fa sì che il framework chiami la funzione di callback EvtDeviceFileCreate del driver in modalità utente, ma tale funzione di callback è facoltativa.

  • La richiesta di I/O non può contenere un codice di funzione IRP_MJ_INTERNAL_DEVICE_CONTROL .

  • I buffer della richiesta di I/O non devono contenere puntatori a informazioni aggiuntive, perché il driver in modalità utente non può dereferenziare i puntatori.

  • Se la richiesta di I/O contiene un codice di controllo di I/O che specifica il metodo di accesso al buffer "nessuno", il driver in modalità kernel deve inviare la richiesta di I/O nel contesto del processo dell'applicazione che ha creato la richiesta di I/O. Per altre informazioni su come supportare il metodo "nessuno" in un driver UMDF, vedere Gestione dei metodi di accesso al buffer nei driver UMDF.

  • Il driver UMDF potrebbe modificare i dati di output di una richiesta di I/O in modalità utente. Di conseguenza, il driver in modalità kernel deve convalidare tutti i dati di output ricevuti dal driver in modalità utente.

  • Il client in modalità kernel deve in genere convalidare il valore Information che un driver UMDF passa a WdfRequestCompleteWithInformation. Se il client è un driver KMDF, può chiamare WdfRequestGetCompletionParams per ottenere queste informazioni in una struttura di IO_STATUS_BLOCK.

    In genere, il framework non convalida il valore delle informazioni che un driver UMDF passa a WdfRequestCompleteWithInformation. Questo parametro specifica in genere il numero di byte trasferiti. Il framework convalida il valore delle informazioni solo per i buffer di output e solo per il metodo di accesso ai dati I/O memorizzato nel buffer . Ad esempio, il framework verifica che il numero di byte trasferiti non superi le dimensioni del buffer di output di un'operazione di lettura, se il metodo di accesso viene memorizzato nel buffer di I/O.