Modifiche MUP in Microsoft Windows Vista
Windows Vista implementa una serie di modifiche apportate al provider UNC (MUP) che può influire sui reindirizzamenti di rete.
MUP e il client DFS (Distributed File System) si trovano in file binari separati. Il componente MUP si trova in mup.sys e il client DFS si trova in dfsc.sys. In Windows Server 2003, Windows XP e Windows 2000, il componente kernel MUP, mup.sys, conteneva anche il client DFS.
In Windows Vista è definito un nuovo modello di reindirizzamento:
MUP esegue la registrazione come file system con il gestore di I/O chiamando IoRegisterFileSystem.
Un redirector di rete esegue la registrazione con MUP usando FsRtlRegisterUncProviderEx , una nuova routine introdotta in Windows Vista.
Un redirector di rete passa un oggetto dispositivo senza nome a FsRtlRegisterUncProviderEx.
Un redirector di rete passa un nome di dispositivo a FsRtlRegisterUncProviderEx.
Un redirector di rete non viene registrato come file system con il gestore di I/O (non chiama IoRegisterFileSystem).
Tutte le chiamate da MUP a un redirector di rete, inclusa la risoluzione dei prefissi, IOCTLs e LETL, vengono effettuate con le SCHEDE APN abilitate. Tutte le chiamate da altri componenti a MUP devono essere effettuate con le SCHEDE APN abilitate. Quando le chiamate vengono usate con FsRtl DisabilitableWaitForSingleObject o FsRtl DisabilitableWaitForMultipleObjects, le nuove routine introdotte in Windows Vista garantiscono che le attese lunghe possano essere interrotte se viene interrotta un thread che ha emesso una richiesta di I/O.
La risoluzione del prefisso viene eseguita usando IOCTL_REDIR_QUERY_PATH_EX, un nuovo IOCTL introdotto in Windows Vista.
Un nome del dispositivo di reindirizzamento di rete registrato con MUP diventa un collegamento simbolico all'oggetto dispositivo MUP.
Per un redirector di rete conforme al modello di reindirizzamento di Windows Vista, MUP crea un collegamento simbolico nello spazio dei nomi di Gestione oggetti con il nome del dispositivo specificato dal redirector di rete nella chiamata a FsRtlRegisterUncProviderEx. La destinazione di questo collegamento simbolico è l'oggetto dispositivo MUP (\Device\Mup).
Il vantaggio della registrazione di MUP come file system e del nome del dispositivo del redirector di rete è un collegamento simbolico all'oggetto dispositivo MUP è che tutte le operazioni di I/O del file system remoto e non solo le operazioni basate sui nomi passano attraverso MUP. Pertanto i driver di filtro del file system che devono trovarsi nello stack del file system remoto possono semplicemente collegarsi all'oggetto dispositivo MUP. Non è necessario che i driver di filtro del file system esemplificano più i nomi degli oggetti dispositivo del provider (\Device\LanmanRedirector, ad esempio) nel driver. In questo modo, i driver di filtro del file system possono monitorare tutte le operazioni di I/O rilasciate a tutti i reindirizzamenti di rete da un singolo allegato. In questo modo vengono eliminate anche le operazioni di I/O duplicate rilevate dai driver di filtro del file system prima di Windows Vista, collegati separatamente a DFS (mup.sys) e singoli reindirizzamenti di rete (\Device\LanmanRedirector, ad esempio) per monitorare le operazioni di I/O a entrambi.
Un driver di filtro del file system collegato all'oggetto dispositivo MUP può filtrare in modo selettivo il traffico inviato a specifici reindirizzamenti di rete. In questo caso, il driver di filtro esegue il mapping dei nomi dei dispositivi dei reindirizzamenti di rete di interesse agli identificatori del provider chiamando la routine FsRtlMupGetProviderIdFromName . Il driver di filtro può quindi determinare se deve filtrare il traffico per un determinato oggetto file confrontando l'identificatore del provider ottenuto chiamando la routine FsRtlMupGetProviderInfoFromFileObject con gli identificatori del provider dei director di rete di interesse.
Per un redirector di rete conforme al modello di reindirizzamento di Windows Vista:
Tutti gli oggetti file nello stack del file system remoto vengono risolti in MUP. Di conseguenza, IoGetDeviceAttachmentBaseRef restituisce l'oggetto dispositivo per MUP, non il redirector di rete proprietario dell'oggetto file. Tuttavia, il contenuto dell'oggetto file è ancora di proprietà del redirector di rete.
Un IRP_MJ_CREATE rilasciato al nome del dispositivo di un redirector di rete (\Device\LanmanRedirector\server\share, ad esempio) verrà destinato a tale redirector di rete senza passare attraverso la risoluzione del prefisso MUP, esattamente come in Windows Server 2003, Windows XP e Windows 2000.
I reindirizzamenti di rete che non sono basati su RDBSS di Windows Vista (collegamento in modo dinamico o statico) sono indicati come "redirector legacy". Questi reindirizzamenti di rete legacy includono:
Redirector di rete scritti per Windows Server 2003, Windows XP e Windows 2000 che si registrano direttamente con MUP usando FsRtlRegisterUncProvider.
Mini-reindirizzamenti di rete scritti per Windows Server 2003, Windows XP e Windows 2000 che collegano staticamente con la libreria rdbsslib.lib per Windows Server 2003, Windows XP o Windows 2000.
Reindirizzamenti di rete scritti per Windows Vista che si registrano direttamente con MUP usando FsRtlRegisterUncProviderEx.
I mini-reindirizzamenti di rete che si collegano dinamicamente a Windows Vista RDBSS (rdbss.sys) sono conformi automaticamente al modello di reindirizzamento di Windows Vista perché RDBSS esegue la registrazione con MUP usando FsRtlRegisterUncProviderEx. I mini-reindirizzamenti di rete che si collegano in modo statico a Windows Vista RDBSS (rdbsslib.lib) sono conformi automaticamente al modello di reindirizzamento di Windows Vista perché RDBSS esegue la registrazione con MUP usando FsRtlRegisterUncProviderEx.
Un redirector di rete legacy scritto per Windows Vista che esegue la registrazione diretta con MUP deve essere conforme al modello di reindirizzamento di Windows Vista.
I reindirizzamenti di rete scritti per Windows Server 2003, Windows XP e Windows 2000 che si registrano direttamente con MUP usando FsRtlRegisterUncProvider continuano a funzionare esattamente come in Windows Server 2003, Windows XP e Windows 2000. Mini-reindirizzamenti di rete scritti per Windows Server 2003, Windows XP e Windows 2000 che collegano in modo statico con la libreria rdbsslib.lib per Windows Server 2003, Windows XP e Windows 2000 continuano a funzionare esattamente come in Windows Server 2003, Windows XP e Windows 2000. Questi reindirizzamenti di rete legacy e mini-redirector presentano il comportamento seguente:
Saranno visibili ai driver di filtro del file system che monitorano la registrazione del file system.
I relativi oggetti dispositivo sono denominati. I nomi dei dispositivi non sono collegamenti simbolici e non puntano a \Device\MUP.
Gli oggetti file vengono risolti nell'oggetto dispositivo denominato del redirector di rete.
MUP è coinvolto solo nell'operazione di risoluzione del prefisso. Dopo aver identificato il provider di rete, MUP "esce dalla strada" restituendo STATUS_REPARSE. Tutte le operazioni successive non passeranno attraverso MUP.
Questo comportamento è stato mantenuto per impedire il doppio filtro che altrimenti si verifica se il nome del dispositivo del provider fosse un collegamento simbolico a \Device\MUP. Questo filtro doppio si verifica per i motivi seguenti:
Il driver di filtro del file system è già collegato a \Device\MUP.
Il driver di filtro del file system si collega a qualsiasi file system di registrazione. Poiché i reindirizzamenti di rete che usano oggetti dispositivo denominati si registrano come file system, un driver di filtro del file system finirà per filtrare lo stesso I/O due volte.
Le chiamate da e verso MUP in Windows Vista vengono effettuate con le SCHEDE APN abilitate, con gli effetti seguenti:
È importante proteggere, se necessario, i percorsi di codice che vengono chiamati da MUP in caso di sospensione del thread, in particolare IOCTL_REDIR_QUERY_PATH gestori. Si noti che una sospensione del thread è un'operazione di attesa potenzialmente non associato che può durare molto tempo.
È importante assicurarsi che qualsiasi operazione di "attesa di I/O" che coinvolge thread in modalità utente (anziché thread di sistema) usi sempre "attese annullabili". Per informazioni dettagliate, vedere le routine FsRtl DisabilitableWaitForSingleObject e FsRtl DisabilitableWaitForMultipleObjects .
I deadlock possono verificarsi quando un thread viene sospeso mantenendo un blocco importante. È importante eseguire test in presenza di thread in modalità utente sospesi in modo arbitrario per verificare la presenza di condizioni di deadlock.
È importante eseguire test per verificare se "attendere le operazioni di I/O" sono davvero annullabili e che un'applicazione in modalità utente può terminare un thread in modo che sia abbastanza veloce in modo che l'applicazione non sembri in uno stato "non risponde" quando si tenta di terminare tale thread.
Le dimensioni e il timeout della cache dei prefissi usati da MUP in Windows Vista sono ora controllati dai valori del Registro di sistema seguenti:
PrefixCacheSizeInKB
PrefixCacheTimeoutInSeconds.
Questi valori del Registro di sistema possono essere modificati dinamicamente senza un riavvio. Questi valori del Registro di sistema si trovano nella seguente chiave del Registro di sistema:
HKLM\System\CurrentControlSet\Services\Mup\Parameters.
Il valore del Registro di sistema ProviderOrder che determina l'ordine in cui MUP emette richieste di risoluzione dei prefissi ai singoli redirector può essere modificato in modo dinamico senza riavviare il sistema. Questo valore del Registro di sistema si trova nella seguente chiave del Registro di sistema:
HKLM\CurrentControlSet\Control\NetworkProvider\Order
In Windows Vista MUP esegue la risoluzione dei prefissi in modo diverso a seconda che il redirector di rete registrato con MUP chiami FsRtlRegisterUncProvider o FsRtlRegisterUncProviderEx. I reindirizzamenti di rete legacy che si registrano con MUP chiamando FsRtlRegisterUncProvider riceveranno una richiesta di IOCTL_REDIR_QUERY_PATH per la risoluzione del prefisso. Si tratta dello stesso metodo usato in Windows Server 2003, Windows XP e Windows 2000.
I reindirizzamenti di rete conformi al modello di reindirizzamento di Windows Vista e registrati con MUP chiamando FsRtlRegisterUncProviderEx riceveranno una richiesta di IOCTL_REDIR_QUERY_PATH_EX per la risoluzione del prefisso. Si noti che in Windows Vista i mini-reindirizzamenti di rete collegati in modo statico con rdbsslib.lib o collegati dinamicamente con rdbss.sys chiameranno FsRtlRegisterUncProviderEx indirettamente tramite RDBSS.
I buffer di input e output per IOCTL_REDIR_QUERY_PATH_EX sono i seguenti:
| Parametro disponibile all'indirizzo | Formato struttura dei dati | |
Buffer di input |
IrpSp-> Parameters.DeviceIoControl.Type3InputBuffer |
QUERY_PATH_REQUEST_EX |
Buffer di output |
IRP-UserBuffer> |
QUERY_PATH_RESPONSE |
IOCTL e le strutture di dati sono definiti in ntifs.h. I buffer vengono allocati dal pool non di paging.
I redirector di rete devono rispettare solo i mittenti in modalità kernel di questo IOCTL, verificando che Irp-RequestorMode> sia KernelMode.
MUP usa la struttura dei dati QUERY_PATH_REQUEST_EX per le informazioni sulla richiesta.
typedef struct _QUERY_PATH_REQUEST_EX {
PIO_SECURITY_CONTEXT pSecurityContext;
ULONG EaLength;
PVOID pEaBuffer;
UNICODE_STRING PathName;
} QUERY_PATH_REQUEST_EX, *PQUERY_PATH_REQUEST_EX;
| Membro struttura | Descrizione |
|---|---|
pSecurityContext |
Puntatore al contesto di sicurezza. |
EaLength |
Lunghezza, in byte, del buffer degli attributi estesi. |
pEaBuffer |
Puntatore al buffer degli attributi estesi. |
PathName |
Stringa Unicode con terminazione non NULL del percorso> di condivisione><del server><del modulo<. |
I provider UNC devono usare la struttura dei dati QUERY_PATH_RESPONSE per le informazioni di risposta.
typedef struct _QUERY_PATH_RESPONSE {
ULONG LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;
| Membro struttura | Descrizione |
|---|---|
LengthAccepted |
Lunghezza, in byte, del prefisso richiesto dal provider dal percorso stringa Unicode specificato nel membro PathName della struttura QUERY_PATH_REQUEST_EX. |
Si noti che IOCTL_REDIR_QUERY_PATH_EX è un METHOD_NEITHER IOCTL. Ciò significa che i buffer di input e output potrebbero non trovarsi nello stesso indirizzo. Un errore comune da parte dei provider UNC consiste nel presupporre che il buffer di input e il buffer di output siano uguali e usino il puntatore del buffer di input per fornire la risposta.
Quando un provider UNC riceve una richiesta di IOCTL_REDIR_QUERY_PATH_EX, deve determinare se può gestire il percorso UNC specificato nel membro PathName della struttura QUERY_PATH_REQUEST_EX. In tal caso, il provider UNC deve aggiornare il membro LengthAccepted della struttura QUERY_PATH_RESPONSE con la lunghezza, in byte, del prefisso richiesto e completare l'IRP con STATUS_SUCCESS. Se il provider non è in grado di gestire il percorso UNC specificato, deve non riuscire la richiesta di IOCTL_REDIR_QUERY_PATH_EX con un codice di errore NTSTATUS appropriato e non deve aggiornare il membro LengthAccepted della struttura QUERY_PATH_RESPONSE. I provider non devono modificare alcun membro o la stringa PathName in alcuna condizione.
In Windows Vista, un mini-reindirizzamento di rete basato sull'uso di RDBSS che indica il supporto come provider UNC riceverà questa attestazione di prefisso come se fosse una normale connessione ad albero, simile a una chiamata Createfile in modalità utente con FILE_CREATE_TREE_CONNECTION flag impostato. RDBSS invierà una richiesta MRxCreateSrvCall al mini-redirector di rete seguito da una chiamata a MRxSrvCallWinnerNotify e MRxCreateVNetRoot. Questa attestazione di prefisso non verrà ricevuta come chiamata a MRxLowIOSubmit[LOWIO_OP_IOCTL]. Quando un mini-redirector di rete esegue la registrazione con RDBSS, la tabella di invio dei driver per il mini-redirector di rete verrà copiata da RDBSS per puntare ai punti di ingresso interni di RDBSS. RDBSS riceve quindi questa IOCTL_REDIR_QUERY_PATH_EX internamente per il mini-redirector di rete e chiama MRxCreateSrvCall, MRxSrvCallWinnerNotify e MRxCreateVNetRoot. Il IOCTL_REDIR_QUERY_PATH_EX IRP originale sarà contenuto nella RX_CONTEXT passata alla routine MRxCreateSrvCall . Inoltre, i membri seguenti nel RX_CONTEXT passati a MRxCreateSrvCall verranno modificati:
Il membro MajorFunction è impostato su IRP_MJ_CREATE anche se l'IRP originale è stato IRP_MJ_DEVICE_CONTROL.
Il membro PrefixClaim.SuppliedPathName.Buffer è impostato sul membro PathName.Buffer della struttura QUERY_PATH_REQUEST_EX.
Il membro PrefixClaim.SuppliedPathName.Length è impostato sul membro PathName.Length della struttura QUERY_PATH_REQUEST_EX.
Il membro Create.ThisIsATreeConnectOpen è impostato su TRUE.
Il membro Create.ThisIsAPrefixClaim è impostato su TRUE.
Il membro Create.NtCreateParameters.SecurityContext è impostato sul membro SecurityContext della struttura QUERY_PATH_REQUEST_EX.
Il membro Create.EaBuffer è impostato sul membro pEaBuffer della struttura QUERY_PATH_REQUEST_EX.
Il membro Create.EaLength è impostato sul membro EaLength della struttura QUERY_PATH_REQUEST_EX.
Il membro Create.Flags avrà il RX_CONTEXT_CREATE_FLAG_UNC_NAME bit impostato.
Se il mini-redirector di rete vuole visualizzare i dettagli dell'attestazione di prefisso, può leggere questi membri nella struttura RX_CONTEXT passata a MRxCreateSrvCall. In caso contrario, può solo tentare di connettersi alla condivisione server e restituire STATUS_SUCCESS se la chiamata MRxCreateSrvCall ha avuto esito positivo. RDBSS effettuerà l'attestazione del prefisso per conto del mini-redirector di rete.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per