Perubahan MUP di Microsoft Windows Vista
Windows Vista menerapkan sejumlah perubahan pada beberapa penyedia UNC (MUP) yang dapat memengaruhi pengalihan jaringan.
MUP dan klien Sistem File Terdistribusi (DFS) berada dalam file biner terpisah. Komponen MUP berada dalam mup.sys dan klien DFS berada dalam dfsc.sys. Pada Windows Server 2003, Windows XP, dan Windows 2000, komponen kernel MUP, mup.sys, juga berisi klien DFS.
Model pengalih baru didefinisikan pada Windows Vista:
MUP mendaftar sebagai sistem file dengan manajer I/O dengan memanggil IoRegisterFileSystem.
Pengalih jaringan mendaftar dengan MUP menggunakan FsRtlRegisterUncProviderEx , rutinitas baru yang diperkenalkan di Windows Vista.
Pengalih jaringan meneruskan objek perangkat yang tidak disebutkan namanya ke FsRtlRegisterUncProviderEx.
Pengalih jaringan meneruskan nama perangkat ke FsRtlRegisterUncProviderEx.
Pengalih jaringan tidak mendaftar sebagai sistem file dengan manajer I/O (tidak memanggil IoRegisterFileSystem).
Semua panggilan dari MUP ke pengalih jaringan, termasuk resolusi awalan, IOCTL, dan FSCTL, dibuat dengan APC diaktifkan. Semua panggilan dari komponen lain ke MUP diharapkan dilakukan dengan APC diaktifkan. Ketika panggilan digunakan dengan FsRtlCancellableWaitForSingleObject atau FsRtlCancellableWaitForMultipleObjects, rutinitas baru yang diperkenalkan di Windows Vista, ini akan memastikan bahwa penantian panjang dapat dibatalkan jika utas yang mengeluarkan permintaan I/O dihentikan.
Resolusi awalan dilakukan menggunakan IOCTL_REDIR_QUERY_PATH_EX, IOCTL baru yang diperkenalkan di Windows Vista.
Nama perangkat pengalih jaringan yang terdaftar di MUP menjadi tautan simbolis ke objek perangkat MUP.
Untuk pengalih jaringan yang sesuai dengan model pengalihan Windows Vista, MUP membuat tautan simbolis di namespace pengelola objek dengan nama perangkat yang ditentukan oleh pengalih jaringan dalam panggilan ke FsRtlRegisterUncProviderEx. Target dari tautan simbolis ini adalah objek perangkat MUP (\Device\Mup).
Keuntungan mendaftarkan MUP sebagai sistem file dan nama perangkat pengalihan jaringan menjadi tautan simbolis ke objek perangkat MUP adalah bahwa semua operasi I/O sistem file jarak jauh, dan bukan hanya operasi berbasis nama, melalui MUP. Jadi driver filter sistem file yang perlu berada di tumpukan sistem file jarak jauh cukup melampirkan ke objek perangkat MUP. Tidak perlu driver filter sistem file ke nama objek perangkat penyedia hardcode (\Device\LanmanRedirector, misalnya) ke driver mereka lagi. Dengan cara ini, driver filter sistem file dapat memantau semua operasi I/O yang dikeluarkan untuk semua pengalihan jaringan oleh satu lampiran. Ini juga menghilangkan operasi I/O duplikat yang dilihat oleh driver filter sistem file sebelum Windows Vista, yang dilampirkan secara terpisah ke DFS (mup.sys) dan pengalih jaringan individual (\Device\LanmanRedirector, misalnya) untuk memantau operasi I/O ke keduanya.
Driver filter sistem file yang dilampirkan ke objek perangkat MUP dapat secara selektif memfilter lalu lintas yang dikirim ke pengalih jaringan tertentu. Dalam situasi ini, driver filter memetakan nama perangkat pengalih jaringan yang menarik bagi pengidentifikasi penyedia dengan memanggil rutinitas FsRtlMupGetProviderIdFromName . Driver filter kemudian dapat menentukan apakah itu harus memfilter lalu lintas untuk objek file tertentu dengan membandingkan pengidentifikasi penyedia yang diperoleh dengan memanggil rutinitas FsRtlMupGetProviderInfoFromFileObject dengan pengidentifikasi penyedia direktur jaringan yang diminati.
Untuk pengalih jaringan yang sesuai dengan model pengalihan Windows Vista:
Semua objek file pada tumpukan sistem file jarak jauh diselesaikan ke MUP. Oleh karena itu, IoGetDeviceAttachmentBaseRef mengembalikan objek perangkat untuk MUP, bukan pengalih jaringan yang memiliki objek file. Namun, konten objek file masih dimiliki oleh pengalih jaringan.
IRP_MJ_CREATE yang dikeluarkan untuk nama perangkat pengalih jaringan (\Device\LanmanRedirector\server\share, misalnya) akan ditargetkan ke pengalih jaringan tersebut tanpa melalui resolusi awalan MUP, persis seperti pada Windows Server 2003, Windows XP, dan Windows 2000.
Pengalih jaringan yang tidak didasarkan pada Windows Vista RDBSS (menautkan secara dinamis atau statis) disebut "pengalihan warisan". Pengalihan jaringan warisan ini meliputi:
Pengalihan jaringan yang ditulis untuk Windows Server 2003, Windows XP, dan Windows 2000 yang mendaftar langsung dengan MUP menggunakan FsRtlRegisterUncProvider.
Pengalihan mini jaringan yang ditulis untuk Windows Server 2003, Windows XP, dan Windows 2000 yang secara statis ditautkan dengan pustaka rdbsslib.lib untuk Windows Server 2003, Windows XP, atau Windows 2000.
Pengalihan jaringan yang ditulis untuk Windows Vista yang mendaftar langsung dengan MUP menggunakan FsRtlRegisterUncProviderEx.
Pengalihan mini jaringan yang secara dinamis terhubung dengan Windows Vista RDBSS (rdbss.sys) secara otomatis sesuai dengan model pengalih Windows Vista karena RDBSS mendaftar dengan MUP menggunakan FsRtlRegisterUncProviderEx. Pengalih mini jaringan yang secara statis menautkan terhadap Windows Vista RDBSS (rdbsslib.lib) juga secara otomatis sesuai dengan model pengalihan Windows Vista karena RDBSS mendaftar dengan MUP menggunakan FsRtlRegisterUncProviderEx.
Pengalih jaringan warisan yang ditulis untuk Windows Vista yang mendaftar langsung dengan MUP harus mematuhi model pengalihan Windows Vista.
Pengalihan jaringan yang ditulis untuk Windows Server 2003, Windows XP, dan Windows 2000 yang mendaftar dengan MUP secara langsung menggunakan FsRtlRegisterUncProvider terus bekerja dengan cara yang sama persis seperti yang mereka lakukan pada Windows Server 2003, Windows XP, dan Windows 2000. Pengalihan mini jaringan yang ditulis untuk Windows Server 2003, Windows XP, dan Windows 2000 yang secara statis menautkan dengan pustaka rdbsslib.lib untuk Windows Server 2003, Windows XP, dan Windows 2000 terus bekerja dengan cara yang sama seperti yang mereka lakukan pada Windows Server 2003, Windows XP, dan Windows 2000. Pengalih jaringan warisan dan pengalih mini ini menunjukkan perilaku berikut:
Mereka akan terlihat oleh driver filter sistem file yang memantau pendaftaran sistem file.
Objek perangkat mereka diberi nama. Nama perangkat bukan tautan simbolis dan tidak menunjuk ke \Device\MUP.
Objek file diselesaikan ke objek perangkat bernama pengalih jaringan.
MUP hanya terlibat dalam operasi resolusi awalan. Setelah penyedia jaringan diidentifikasi, MUP "keluar dari jalan" dengan mengembalikan STATUS_REPARSE. Semua operasi berikutnya tidak akan melewati MUP.
Perilaku ini telah dipertahankan untuk mencegah pemfilteran ganda yang akan terjadi jika nama perangkat penyedia adalah tautan simbolis ke \Device\MUP. Pemfilteran ganda ini akan terjadi karena alasan berikut:
Driver filter sistem file sudah dilampirkan ke \Device\MUP.
Driver filter sistem file melekat pada sistem file pendaftaran apa pun. Karena pengalih jaringan yang menggunakan objek perangkat bernama mendaftarkan diri mereka sebagai sistem file, driver filter sistem file akan akhirnya memfilter I/O yang sama dua kali.
Panggilan ke dan dari MUP di Windows Vista dilakukan dengan APC diaktifkan, yang memiliki dampak berikut:
Penting untuk melindungi, jika diperlukan, jalur kode yang dipanggil dari MUP terhadap penangguhan utas dengan cara yang sesuai, terutama penangan IOCTL_REDIR_QUERY_PATH. Perhatikan bahwa penangguhan utas adalah operasi "tunggu tidak terbatas" yang berpotensi berlangsung lama.
Penting untuk memastikan bahwa setiap operasi "tunggu I/O" yang melibatkan utas mode pengguna (dibandingkan dengan utas sistem) selalu menggunakan "tunggu yang dapat dibatalkan". Lihat rutinitas FsRtlCancellableWaitForSingleObject dan FsRtlCancellableWaitForMultipleObjects untuk detailnya.
Kebuntuan mungkin terjadi ketika utas ditangguhkan dengan menahan beberapa kunci penting. Penting untuk menjalankan pengujian di hadapan utas mode pengguna yang ditangguhkan secara segan-segan untuk memeriksa kondisi kebuntuan.
Penting untuk menjalankan pengujian untuk memverifikasi apakah "tunggu operasi I/O" benar-benar dapat dibatalkan dan bahwa aplikasi mode pengguna dapat mengakhiri utas dengan cukup cepat sehingga aplikasi tampaknya tidak berada dalam status "tidak merespons" saat mencoba mengakhiri utas tersebut.
Ukuran cache awalan dan batas waktu yang digunakan oleh MUP pada Windows Vista sekarang dikontrol oleh nilai registri berikut:
PrefixCacheSizeInKB
PrefixCacheTimeoutInSeconds.
Nilai registri ini dapat diubah secara dinamis tanpa boot ulang. Nilai registri ini berada di bawah kunci registri berikut:
HKLM\System\CurrentControlSet\Services\Mup\Parameters.
Nilai registri ProviderOrder yang menentukan urutan di mana MUP mengeluarkan permintaan resolusi awalan ke pengalihan individu dapat diubah secara dinamis tanpa me-reboot sistem. Nilai registri ini terletak di bawah kunci registri berikut:
HKLM\CurrentControlSet\Control\NetworkProvider\Order
Pada Windows Vista, MUP melakukan resolusi awalan secara berbeda tergantung pada apakah pengalih jaringan yang terdaftar di MUP dengan memanggil FsRtlRegisterUncProvider atau FsRtlRegisterUncProviderEx. Pengalihan jaringan lama yang mendaftar ke MUP dengan memanggil FsRtlRegisterUncProvider akan menerima permintaan IOCTL_REDIR_QUERY_PATH untuk resolusi awalan. Ini adalah metode yang sama yang digunakan pada Windows Server 2003, Windows XP, dan Windows 2000.
Pengalih jaringan yang sesuai dengan model pengalihan Windows Vista dan mendaftar dengan MUP dengan memanggil FsRtlRegisterUncProviderEx akan menerima permintaan IOCTL_REDIR_QUERY_PATH_EX untuk resolusi awalan. Perhatikan bahwa pada Windows Vista, pengalih mini jaringan secara statis ditautkan dengan rdbsslib.lib atau ditautkan secara dinamis dengan rdbss.sys akan memanggil FsRtlRegisterUncProviderEx secara tidak langsung melalui RDBSS.
Buffer input dan output untuk IOCTL_REDIR_QUERY_PATH_EX adalah sebagai berikut:
| Parameter tersedia di | Format struktur data | |
Buffer input |
IrpSp-> Parameters.DeviceIoControl.Type3InputBuffer |
QUERY_PATH_REQUEST_EX |
Buffer output |
IRP-UserBuffer> |
QUERY_PATH_RESPONSE |
IOCTL dan struktur data didefinisikan dalam ntifs.h. Buffer dialokasikan dari kumpulan non-halaman.
Pengalih jaringan hanya boleh menghormati pengirim mode kernel IOCTL ini, dengan memverifikasi bahwa Irp-RequestorMode> adalah KernelMode.
MUP menggunakan struktur data QUERY_PATH_REQUEST_EX untuk informasi permintaan.
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;
| Anggota struktur | Deskripsi |
|---|---|
pSecurityContext |
Penunjuk ke konteks keamanan. |
EaLength |
Panjang, dalam byte, dari buffer atribut yang diperluas. |
pEaBuffer |
Penunjuk ke buffer atribut yang diperluas. |
PathName |
Untai (karakter) Unicode non-NULL yang dihentikan dari jalur> berbagi><server><formulir<. |
Penyedia UNC harus menggunakan struktur data QUERY_PATH_RESPONSE untuk informasi respons.
typedef struct _QUERY_PATH_RESPONSE {
ULONG LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;
| Anggota struktur | Deskripsi |
|---|---|
LengthAccepted |
Panjang, dalam byte, dari awalan yang diklaim oleh penyedia dari jalur string Unicode yang ditentukan dalam anggota PathName dari struktur QUERY_PATH_REQUEST_EX. |
Perhatikan bahwa IOCTL_REDIR_QUERY_PATH_EX adalah IOCTL METHOD_NEITHER. Ini berarti bahwa buffer input dan output mungkin tidak berada di alamat yang sama. Kesalahan umum oleh penyedia UNC adalah mengasumsikan bahwa buffer input dan buffer output sama dan menggunakan penunjuk buffer input untuk memberikan respons.
Ketika penyedia UNC menerima permintaan IOCTL_REDIR_QUERY_PATH_EX, penyedia UNC harus menentukan apakah ia dapat menangani jalur UNC yang ditentukan dalam anggota PathName dari struktur QUERY_PATH_REQUEST_EX. Jika demikian, penyedia UNC harus memperbarui anggota LengthAccepted dari struktur QUERY_PATH_RESPONSE dengan panjang, dalam byte, dari awalan yang telah diklaim dan menyelesaikan IRP dengan STATUS_SUCCESS. Jika penyedia tidak dapat menangani jalur UNC yang ditentukan, itu harus gagal permintaan IOCTL_REDIR_QUERY_PATH_EX dengan kode kesalahan NTSTATUS yang sesuai dan tidak boleh memperbarui anggota LengthAccepted dari struktur QUERY_PATH_RESPONSE. Penyedia tidak boleh mengubah anggota lain atau string PathName dalam kondisi apa pun.
Pada Windows Vista, pengalih mini jaringan berdasarkan penggunaan RDBSS yang menunjukkan dukungan sebagai penyedia UNC akan menerima klaim awalan ini seolah-olah itu adalah pembuatan koneksi pohon biasa, mirip dengan panggilan Createfile mode pengguna dengan set bendera FILE_CREATE_TREE_CONNECTION. RDBSS akan mengirim permintaan MRxCreateSrvCall ke pengalihan mini jaringan diikuti dengan panggilan ke MRxSrvCallWinnerNotify dan MRxCreateVNetRoot. Klaim awalan ini tidak akan diterima sebagai panggilan ke MRxLowIOSubmit[LOWIO_OP_IOCTL]. Ketika pengalih mini jaringan mendaftar dengan RDBSS, tabel pengiriman driver untuk pengalih mini jaringan akan disalin oleh RDBSS untuk menunjuk ke titik masuk RDBSS internal. RDBSS kemudian menerima IOCTL_REDIR_QUERY_PATH_EX ini secara internal untuk pengalih mini jaringan dan memanggil MRxCreateSrvCall, MRxSrvCallWinnerNotify, dan MRxCreateVNetRoot. IRP IOCTL_REDIR_QUERY_PATH_EX asli akan terkandung dalam RX_CONTEXT diteruskan ke rutinitas MRxCreateSrvCall . Selain itu, anggota berikut dalam RX_CONTEXT yang diteruskan ke MRxCreateSrvCall akan dimodifikasi:
Anggota MajorFunction diatur ke IRP_MJ_CREATE meskipun IRP asli IRP_MJ_DEVICE_CONTROL.
Anggota PrefixClaim.SuppliedPathName.Buffer diatur ke anggota PathName.Buffer dari struktur QUERY_PATH_REQUEST_EX.
Anggota PrefixClaim.SuppliedPathName.Length diatur ke anggota PathName.Length dari struktur QUERY_PATH_REQUEST_EX.
Anggota Create.ThisIsATreeConnectOpen diatur ke TRUE.
Anggota Create.ThisIsAPrefixClaim diatur ke TRUE.
Anggota Create.NtCreateParameters.SecurityContext diatur ke anggota SecurityContext dari struktur QUERY_PATH_REQUEST_EX.
Anggota Create.EaBuffer diatur ke anggota pEaBuffer dari struktur QUERY_PATH_REQUEST_EX.
Anggota Create.EaLength diatur ke anggota EaLength dari struktur QUERY_PATH_REQUEST_EX.
Anggota Create.Flags akan memiliki set bit RX_CONTEXT_CREATE_FLAG_UNC_NAME.
Jika pengalih mini jaringan ingin melihat detail klaim awalan, itu dapat membaca anggota ini dalam struktur RX_CONTEXT yang diteruskan ke MRxCreateSrvCall. Jika tidak, ia hanya dapat mencoba menyambungkan ke berbagi server dan mengembalikan STATUS_SUCCESS jika panggilan MRxCreateSrvCall berhasil. RDBSS akan membuat klaim awalan atas nama pengalih mini jaringan.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk