Loạt bài “Đáy I/O Windows”, kỳ cuối.
Từ khi vẽ hộp “file system filter (chống virus, mã hóa, Procmon, v.v.)” trên sơ đồ device stack kỳ 1, loạt bài này những kẻ chen giữa đã nhiều lần lộ mặt. Lý do Procmon ghi được mọi I/O (kỳ 1). “Chỉ môi trường đó truy cập tệp chậm” (kỳ 2). Reparse point khiến OneDrive bắt đầu tải ngay lúc mở (kỳ 5). Lần này cuối cùng xử thẳng cơ chế chen đó ── file system filter driver và minifilter ── và thu hết phục tuyến của loạt.
1. Kết luận trước
- “Cắt vào I/O” là điểm mở rộng OS công nhận. File system filter xem, sửa, từ chối, xử lý thay hệ thống tệp yêu cầu tới hệ thống tệp (Chương 2).1
- Chuẩn hiện nay là minifilter. Để giải vấn đề cách kế thừa cắt trực tiếp vào device stack (thứ tự không định, không gỡ được), đã đổi thế hệ sang đăng ký callback với Filter Manager (FltMgr) kèm Windows (Chương 2).23
- Chuyển động là callback pre/post. Trước và sau từng thao tác, được gọi theo thứ tự đăng ký = thứ tự altitude. Cho qua, hoàn tất, từ chối, sửa ── “lựa chọn của driver” kỳ 1 thấy dùng nguyên (Chương 3).2
- Altitude (độ cao) quyết thứ tự. Từng nhóm theo mục đích được gán dải số (Activity Monitor 360000〜389999, Anti-Virus 320000〜329999, v.v.), mỗi instance gắn volume có số duy nhất (Chương 4).45
- Cư dân PC bạn xem được bằng
fltmc. Procmon (chỉ lúc đang chạy), chống virus, cloud filter của OneDrive ── tất cả xếp ở đây (Chương 5). - Cài đặt loại trừ chống virus là “bỏ quét của chính sản phẩm đó”, không ảnh hưởng minifilter khác. Loại trừ là đánh đổi làm yếu bảo vệ; volume phát triển có lựa chọn an toàn hơn là Dev Drive (quét bất đồng bộ) (Chương 6).67
- Điều tra “chỉ môi trường đó chậm” bắt từ cột Duration của Procmon và so sánh cấu hình
fltmc(Chương 7).
Bản đồ tri thức của bài viết này
Chuẩn hiện nay của file system filter là minifilter; khác filter kế thừa chồng trực tiếp đối tượng thiết bị lên device stack, cách này đăng ký callback pre/post với Filter Manager (FltMgr) kèm Windows. Thứ tự được gọi quyết định tính bằng altitude do Microsoft phân bổ và quản lý, cấu hình thực xem được bằng lệnh fltmc. Chống virus, Procmon, đồng bộ đám mây OneDrive đều là cư dân cùng cơ chế; cài đặt loại trừ chỉ bỏ quét của chính sản phẩm đó và kèm đánh đổi làm yếu bảo vệ; volume phát triển có lựa chọn an toàn hơn là Dev Drive.
flowchart LR
accTitle: Bản đồ tri thức filter driver và minifilter
accDescr: Sơ đồ cho thấy quan hệ file system filter driver, đổi thế hệ từ filter kế thừa sang minifilter, Filter Manager (FltMgr), callback pre/post, altitude và nhóm thứ tự tải, quan sát bằng fltmc, minifilter chống virus cùng cài đặt loại trừ và Dev Drive, cơ chế Procmon ghi mọi I/O với tư cách minifilter
minifilter["Minifilter"]
filter_manager["Filter Manager (FltMgr)"]
legacy_filter_driver["Filter kế thừa (legacy)"]
filesystem_filter_driver["File system filter driver"]
device_stack["Device stack"]
load_order_instability["Thứ tự tải không ổn định"]
minifilter_callback["Callback pre/post"]
altitude["Altitude"]
load_order_group["Nhóm thứ tự tải"]
fltmc["fltmc"]
altitude_request["Xin cấp altitude"]
procmon["Process Monitor (procmon.exe)"]
antivirus_minifilter["Minifilter chống virus"]
cloud_filter["Cloud file filter (cldflt)"]
onedrive_files_on_demand["Files On-Demand của OneDrive"]
fast_io["Fast I/O"]
scan_performance_cost["Chi phí hiệu năng do quét"]
exclusion_setting["Cài đặt loại trừ (loại trừ thư mục)"]
reduced_protection["Giảm mức bảo vệ"]
dev_drive["Dev Drive"]
frame["Frame FltMgr"]
driver_object["Đối tượng driver"]
legacy_filter_driver -->|"triển khai"| filesystem_filter_driver
minifilter -->|"triển khai"| filesystem_filter_driver
minifilter -->|"kế nhiệm"| legacy_filter_driver
legacy_filter_driver -->|"yêu cầu"| device_stack
legacy_filter_driver -->|"có thể gây"| load_order_instability
minifilter -.->|"ngăn chặn"| load_order_instability
minifilter -->|"yêu cầu"| filter_manager
filter_manager -->|"sử dụng"| minifilter_callback
minifilter -->|"sử dụng"| minifilter_callback
minifilter -->|"cấu hình bằng"| altitude
altitude -->|"cấu hình bằng"| load_order_group
altitude -->|"xác minh bằng"| fltmc
altitude -.->|"yêu cầu"| altitude_request
altitude_request -->|"nên làm trước"| minifilter
minifilter -->|"xác minh bằng"| fltmc
legacy_filter_driver -->|"xác minh bằng"| fltmc
procmon -->|"sử dụng"| minifilter
procmon -->|"sử dụng"| minifilter_callback
antivirus_minifilter -->|"sử dụng"| minifilter_callback
antivirus_minifilter -->|"cấu hình bằng"| altitude
cloud_filter -->|"tự động hóa"| onedrive_files_on_demand
minifilter -.->|"sử dụng"| fast_io
antivirus_minifilter -.->|"có thể gây"| scan_performance_cost
exclusion_setting -->|"giảm thiểu"| scan_performance_cost
exclusion_setting -->|"có thể gây"| reduced_protection
antivirus_minifilter -->|"cấu hình bằng"| exclusion_setting
dev_drive -->|"giảm thiểu"| scan_performance_cost
dev_drive -->|"giảm thiểu"| reduced_protection
antivirus_minifilter -->|"khuyến nghị cho"| dev_drive
filter_manager -->|"sử dụng"| frame
frame -->|"xác minh bằng"| fltmc
legacy_filter_driver -->|"sử dụng"| driver_object
minifilter -->|"sử dụng"| driver_object
filter_manager -->|"yêu cầu"| device_stack
filter_manager -->|"sử dụng"| driver_object
Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 35, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle
2. Lịch sử những kẻ chen giữa ── từ filter kế thừa đến FltMgr
File system filter driver là driver cắt được yêu cầu hướng tới hệ thống tệp (hoặc volume phía dưới). Ghi nhận, giám sát, đổi nội dung, thậm chí từ chối hay xử lý thay ── nền của phần mềm chống virus, mã hóa, sao lưu, lưu trữ phân tầng.1
Cách triển khai cũ (filter kế thừa / legacy filter) là chồng trực tiếp đối tượng thiết bị của mình lên device stack đã xem kỳ 1. Về cơ chế thì thẳng, nhưng thực tế đầy vấn đề ── thứ tự chồng phụ thuộc thứ tự tải nên khó bảo đảm, chồng rồi thì không rút an toàn (không unload được), thành ổ bug tương thích giữa các filter.
Vì vậy Windows đưa vào Filter Manager (FltMgr). Chính FltMgr đứng trên stack như filter kèm OS; từng chức năng filter đăng ký callback với FltMgr với tư cách minifilter.2
flowchart TB
subgraph OLD["Cách kế thừa"]
L1["Filter kế thừa A"]
L2["Filter kế thừa B"]
LFS1["Hệ thống tệp"]
L1 --> L2
L2 --> LFS1
NOTE1["Thứ tự phó mặc thứ tự tải<br/>không unload an toàn được"]
end
subgraph NEW["Cách minifilter (chuẩn hiện nay)"]
FM["Filter Manager (FltMgr)<br/>kèm OS. Đứng trên stack chỉ có cái này"]
M1["Minifilter A (altitude cao)"]
M2["Minifilter B (altitude thấp)"]
LFS2["Hệ thống tệp"]
FM -. "đăng ký callback" .- M1
FM -. "đăng ký callback" .- M2
FM --> LFS2
NOTE2["Thứ tự quyết định tính bằng altitude<br/>tải được lúc bất kỳ<br/>(filter hỗ trợ thì unload cũng được)"]
end
Hình 1: Đổi thế hệ. Không “chồng” lên stack mà “đăng ký” với FltMgr
Lợi của cách minifilter được liệt kê chính thức ── tải được lúc nào cũng được, điều khiển thứ tự được, filter đã triển khai callback unload thì gỡ khi đang chạy cũng được (filter không triển khai hay từ chối thì không gỡ được).3 Để sống cùng filter kế thừa, FltMgr đứng nhiều chỗ trên stack như nhiều “frame”; minifilter unload rồi tải lại vẫn được bảo đảm về cùng vị trí (cùng altitude).2 Phần mềm chống virus, giám sát, đồng bộ hiện đại gần như tất cả là minifilter này.
3. Chuyển động của minifilter ── callback pre/post
Minifilter khai với FltMgr “thao tác nào mình quan tâm”. Ví dụ chỉ quan tâm IRP_MJ_CREATE (mở) và IRP_MJ_WRITE (ghi). Khi thao tác đó chảy, trước thao tác (callback pre) và sau thao tác (callback post) được gọi.
sequenceDiagram
participant IOM as I/O Manager
participant FM as FltMgr
participant A as Minifilter A<br/>(altitude cao)
participant B as Minifilter B<br/>(altitude thấp)
participant FS as NTFS
IOM->>FM: Yêu cầu (IRP_MJ_CREATE, v.v. Thế giới kỳ 1)
FM->>A: callback pre
FM->>B: callback pre
FM->>FS: tới hệ thống tệp
FS-->>FM: kết quả xử lý
FM-->>B: callback post
FM-->>A: callback post
FM-->>IOM: hoàn tất (sang luồng hoàn tất kỳ 1)
Hình 2: Callback pre/post. Đi thì gọi theo altitude cao trước, về thì ngược
Mỗi callback làm được gì. Cùng khung “ba lựa chọn của driver” mục 4.3 kỳ 1, được cung cấp bằng API an toàn hơn.
flowchart TB
PRE["callback pre được gọi"]
Q{"Thao tác này xử thế nào"}
PASS["Cho qua<br/>(không cần post thì cũng khai vậy)"]
DENY["Từ chối<br/>trả ngay từ chối truy cập, v.v.<br/>vd: phát hiện virus, cấm ghi"]
DONE["Tự hoàn tất<br/>vd: cloud filter lấy<br/>thực thể rồi đưa ra"]
MOD["Sửa tham số hay nội dung rồi cho chảy<br/>vd: filter mã hóa"]
PRE --> Q
Q --> PASS
Q --> DENY
Q --> DONE
Q --> MOD
Hình 3: Lựa chọn của callback pre. “Xem, dừng, làm thay, sửa” đều làm được chính thức
Và bài tập kỳ 4 được thu ở đây ── minifilter đứng được cả Fast I/O (đường tắt không tạo IRP). Vì FltMgr luồn cơ chế callback cả đường Fast I/O, không còn chuyện thời kế thừa “đi đường tắt thì không thấy”. Log Procmon xếp cả dòng FASTIO_, nhờ vị trí đứng này.
4. Altitude ── “độ cao” quyết thứ tự
Nhiều filter cùng quan tâm một thao tác thì ai xem trước là vấn đề lớn. Chống virus không xem trước mã hóa thì phải quét bản mã; công cụ giám sát không đứng trên mọi người thì không quan sát được toàn bộ.
Thứ quyết thứ tự này là altitude (độ cao). Từng loại filter được định nghĩa nhóm thứ tự tải và dải số. Nói chính xác, đơn vị gắn altitude không phải cả driver mà ** “instance” minifilter gắn volume**. Số duy nhất; số lớn hơn thì vị trí trên stack (phía ứng dụng).4 Một driver có thể có nhiều định nghĩa instance, hiện ở độ cao khác nhau; danh sách fltmc instances theo instance vì vậy.
flowchart TB
APP["Phía ứng dụng (số lớn)"]
G1["FSFilter Activity Monitor: 360000〜389999<br/>quan sát, ghi I/O (Procmon ở đây)"]
G2["FSFilter Undelete: 340000〜349999<br/>khôi phục tệp đã xóa"]
G3["FSFilter Anti-Virus: 320000〜329999<br/>phát hiện, diệt virus"]
G4["FSFilter Replication: 300000〜309999<br/>nhân bản ra xa"]
G5["FSFilter Continuous Backup: 280000〜289999<br/>sao lưu liên tục"]
G6["Xuống nữa: Content Screener /<br/>Quota Management / System Recovery /<br/>các dải mã hóa, nén, v.v. tiếp"]
FS["Phía hệ thống tệp (số nhỏ)"]
APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS
Hình 4: Dải altitude (trích). Từng mục đích đã định “độ cao phải đứng”
Điểm quan trọng: số này Microsoft phân bổ và quản lý.5 Nhà cung cấp không tự xưng mà xin rồi nhận ── nên mọi PC giữ trật tự “giám sát trên chống virus, chống virus trên mã hóa”. Đó là câu trả lời cho “xổ số thứ tự tải” thời kế thừa.
Chỗ xin nếu tự làm minifilter. Chỉ viết một bước cho nhà phát triển. Altitude xin theo quy trình Request a Filter Altitude Identifier: tiêu đề “Filter altitude request”, gửi email tiếng Anh tới fsfcomm@microsoft.com. Cần điền hết tên công ty, liên hệ (alias công ty dùng lâu, không phải cá nhân), tên sản phẩm, URL sản phẩm, mô tả filter, tên tệp driver, loại filter, loại start, nhóm thứ tự tải mong muốn và altitude mong muốn. Cũng ghi rõ dự kiến xử lý 30 ngày làm việc, không có cửa khẩn, số được gán có thể khác mong muốn.8 Nếu công ty đã có altitude số nguyên trong cùng nhóm thứ tự tải, được tự quyết giá trị gắn số thập phân vào số đó (vd: 325000.3), lúc đó báo sau bằng email là đủ.8
5. Giới thiệu cư dân ── xem PC bạn bằng fltmc
Lý thuyết đến đây, xem vật thật. Command prompt quyền quản trị viên:
:: List of registered minifilters, with altitudes
fltmc
:: Which filters are attached to which volumes
fltmc instances
:: View it from the volume side
fltmc volumes
fltmc không đối số ra cùng danh sách fltmc filters. Đầu ra 4 cột; tài liệu Microsoft cũng có ví dụ cùng dạng.9
C:\Windows\system32>fltmc
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
bindflt 1 409800 0
cldflt 1 409500 0
WdFilter 4 328010 0
luafv 1 135000 0
FileInfo 4 45000 0
Trên là trích để giải thích. Gương mặt xếp và số instance khác môi trường, nhưng số altitude là giá trị cố định Microsoft gán, nên đối chiếu được với danh sách công khai đã nói Chương 4.
Ý nghĩa cột như sau.
| Cột | Ý nghĩa |
|---|---|
| Filter Name | Tên filter (driver) |
| Num Instances | Gắn bao nhiêu volume (số instance Chương 4) |
| Altitude | Altitude. Lớn hơn thì phía ứng dụng |
| Frame | Số frame của FltMgr. Chỗ này là <Legacy> thì đó là dấu filter kế thừa không dùng FltMgr đang sống.9 |
Chỉ 5 dòng này cũng đọc được bindflt và cldflt ở dải FSFilter Top trên cùng (400000〜409999), WdFilter ở dải Anti-Virus (320000〜329999), FileInfo ở dải FSFilter Bottom dưới cùng (40000〜49999). Khung “từng mục đích đã định độ cao phải đứng” Chương 4 xác nhận được bằng số. Và khởi động Procmon rồi chạy fltmc lần nữa thì dải Activity Monitor (360000〜389999) tăng một dòng bắt đầu PROCMON.
Gương mặt khác môi trường, nhưng cư dân điển hình toàn là quen thuộc của loạt này.
WdFilter── minifilter Microsoft Defender. Ở dải Anti-Virus. Trên nhiều PC, mọi I/O tệp chắc chắn qua cửa này.cldflt── filter tệp đám mây. Đơn vị thực thi Files On-Demand của OneDrive; lúc reparse point (placeholder) kỳ 5 đã xem được mở, nó chuẩn bị thực thể.10PROCMON24(v.v.) ── minifilter tạm dải Activity Monitor, chỉ hiện khi Process Monitor đang chạy. Bí mật Procmon thấy mọi I/O là đây.11 Hãy chạyfltmctrước và sau khi khởi động để so.- Ngoài ra, phần mềm sao lưu, sản phẩm mã hóa (chống rò thông tin), EDR, lưu trữ ảo hóa ── PC nghiệp vụ càng nhiều cư dân càng đông.
Nhìn lại công cụ Procmon dùng từ kỳ 1, từ ngoài hộp công cụ ở kỳ cuối, thành vòng đẹp: “người quan sát cũng là cư dân cùng cơ chế với đối tượng quan sát”.
6. Chống virus tốn thời gian ở đâu
Ảnh hưởng thực tế lớn nhất của filter là chi phí quét chống virus. Vẽ chỗ phát sinh thời gian (chi tiết khác sản phẩm; dưới đây là dạng điển hình).
sequenceDiagram
participant App as Ứng dụng
participant AV as Minifilter AV
participant FS as NTFS
App->>AV: Mở tệp
Note over AV: pre-create: phán đoán trước đường và chính sách
AV->>FS: Cho qua (thực thi mở)
FS-->>AV: Mở thành công (post-create)
Note over AV: Tệp chưa quét thì<br/>quét nội dung ở đây<br/>có vấn đề thì hủy mở<br/>── nguyên nhân chính mở chậm
AV-->>App: Không vấn đề thì trả handle
App->>AV: Ghi, đóng
Note over AV: Tệp đã đổi trở thành<br/>đối tượng quét lại lúc đóng, v.v.
Note over App,FS: Hàng loạt tệp nhỏ (sản phẩm trung gian build, v.v.) thì<br/>vòng này chồng theo số tệp
Hình 5: Điểm phát sinh chi phí quét. Mỗi tệp thì ít, hàng vạn tệp thì thành chi phí thống trị
Từ đây, hai chủ đề thực tế hiểu đúng được.
Nghĩa kỹ thuật của cài đặt loại trừ. I/O đường khớp danh sách loại trừ thì xử lý quét của filter bị bỏ. Filter không biến khỏi stack; thực tế là phán đoán “không kiểm” được làm sớm. Và còn một giới hạn quan trọng ── loại trừ chỉ có hiệu với filter của chính sản phẩm giữ cài đặt đó. Cài đặt loại trừ Microsoft Defender đổi quét của WdFilter, không ảnh hưởng gì hành vi minifilter khác sống cùng (chống virus hãng khác, EDR, sao lưu, mã hóa). “Đã loại trừ mà vẫn chậm” thì hãy nghi cư dân khác đang tốn thời gian (so sánh fltmc Chương 7). Hiệu quả lớn, đồng thời loại trừ chắc chắn làm yếu bảo vệ chỗ đó. Tài liệu Microsoft cũng nhắc đi nhắc lại: loại trừ giảm phòng thủ nên tối thiểu sau đánh giá rủi ro.6 Thực tế xử dương tính giả và ảnh hưởng hiệu năng đã xử trong “Ứng dụng Windows tự phát bị coi là virus thì làm gì”.
Câu trả lời mới: Dev Drive. Volume chuyên thiết kế cho khối lượng công việc phát triển (hàng loạt tệp nhỏ); Microsoft Defender chạy chế độ hiệu năng (quét bất đồng bộ). Được đặt là lựa chọn an toàn hơn loại trừ thư mục; mặc định không gắn thêm filter, đồng thời cũng ghi cảnh báo mạnh về vận hành gỡ hết filter.7 Đó là lời giải khuyến nghị hiện nay của Microsoft cho “muốn build nhanh nhưng sợ loại trừ”.
7. Quy trình điều tra “chỉ môi trường đó chậm”
Công cụ loạt bài đã chồng, cuối cùng gom thành một quy trình.
flowchart TB
S["Triệu chứng: cùng ứng dụng mà chỉ môi trường cụ thể<br/>truy cập tệp chậm"]
P1["Xem cột Duration trên Procmon<br/>thời gian mất vào thao tác nào<br/>(IRP_MJ_CREATE? WRITE?)"]
Q1{"Một thao tác cụ thể chậm đều?"}
F1["So sánh fltmc instances với môi trường nhanh<br/>xem chênh cấu hình filter"]
Q2{"Filter chênh là nguyên nhân?"}
A1["Xem loại trừ (kèm đánh giá rủi ro) hay<br/>Dev Drive, hỏi nhà cung cấp"]
A2["Nghi ngoài filter:<br/>cache (kỳ 4), phân mảnh hay MFT (kỳ 5),<br/>đích mạng (UNC), bản thân thiết bị"]
S --> P1 --> Q1
Q1 -->|"có"| F1 --> Q2
Q2 -->|"có"| A1
Q2 -->|"không"| A2
Q1 -->|"không (rải rác)"| A2
Hình 6: Tách chậm do filter. Then chốt là “thời gian theo thao tác” và “chênh cấu hình filter giữa môi trường”
Hai điểm. Thứ nhất, Procmon có thời gian từng thao tác (Duration). Phân “chậm” thành “thao tác nào chậm” thì tìm thủ phạm xong nửa. Thứ hai, chênh môi trường thường là chênh cấu hình filter. Máy phát triển và máy sản xuất, PC công ty và PC khách ── chỉ xếp đầu ra fltmc là thấy ứng viên đáng nghi.
Ba bước đầu nếu chưa đụng Procmon. Cột Duration mặc định không hiện, nên viết thao tác để không kẹt đây.
- Khởi động
Procmon.exevới quyền quản trị viên. - Mở Options > Select Columns…, tick Duration trong danh sách cột.
- Filter > Filter… (Ctrl+L), nhập
Process Name/is/ tên exe đích /Include, bấm Add rồi OK (không bấm Add thì điều kiện không vào).
Rồi bấm cột Duration để sắp, thao tác tốn thời gian tụ trên. Tổng hợp theo tiến trình, theo tệp thì dùng Tools > File Summary. Thao tác ProcMon nói chung gom trong “Hướng dẫn thực tế Process Monitor (ProcMon)”.
8. Tổng kết loạt ── bản đồ 6 kỳ
Đến đây đã mở hết hộp bản đồ vẽ kỳ 1. Gom cả thành một tờ.
flowchart TB
APP["Ứng dụng<br/>ReadFile / WriteFile / async-await"]
API["Kỳ 2: I/O đồng bộ, bất đồng bộ<br/>chế độ handle và OVERLAPPED"]
IOCP["Kỳ 3: IOCP và thread pool .NET<br/>nhận hoàn tất và chạy continuation"]
IOM["Kỳ 1: I/O Manager và IRP<br/>phân giải tên, 3 đối tượng, device stack"]
FLT["Kỳ 6: filter và minifilter<br/>FltMgr, altitude, pre/post"]
CACHE["Kỳ 4: Cache Manager<br/>view 256KB, lazy writer, Fast I/O<br/>(phối hợp với NTFS)"]
NTFS["Kỳ 5: NTFS<br/>MFT, stream, liên kết, 2 journal"]
HW["Storage stack và thiết bị"]
APP --> API
API --> IOM
IOCP -. "hoàn tất trở về đây" .-> APP
IOM --> FLT
FLT --> NTFS
NTFS -. "I/O bật cache thì phối hợp<br/>(hệ thống tệp gọi chức năng cache)" .- CACHE
NTFS --> HW
HW -. "ngắt → hoàn tất (kỳ 1)" .-> IOCP
Hình 7: Bản đồ cả loạt. Cache Manager không phải “tầng đi qua” mà là bạn phối hợp với hệ thống tệp; miss cache thì NTFS phát yêu cầu xuống storage
- Kỳ 1: toàn cảnh ── mọi đọc ghi thành IRP
- Kỳ 2: đồng bộ / bất đồng bộ ── nghĩa thật của OVERLAPPED
- Kỳ 3: IOCP ── tầng hầm của async/await
- Kỳ 4: cache ── WriteFile của bạn đến đĩa khi nào
- Kỳ 5: NTFS ── hiểu hệ thống tệp từ MFT
- Kỳ 6: filter và minifilter (bài này) ── vì sao Procmon và quét virus cắt được vào I/O
9. Tóm tắt ── kết loạt
Tóm tắt kỳ cuối.
- Cắt vào I/O là điểm mở rộng OS công nhận, chuẩn hiện nay là đăng ký callback với FltMgr (minifilter). Thứ tự quyết định tính bằng altitude, Microsoft phân bổ và quản lý số.245
- Chuyển động là callback pre/post. Cho qua, từ chối, làm thay, sửa được, đứng cả Fast I/O. Procmon, Defender, OneDrive đều là cư dân cùng cơ chế này.11110
- Loại trừ = bỏ quét, đánh đổi với bảo vệ. Volume phát triển có lựa chọn an toàn hơn là Dev Drive (quét bất đồng bộ).67
- “Chỉ môi trường đó chậm” tách bằng Duration của Procmon và chênh cấu hình
fltmc── công cụ loạt bài thành nguyên quy trình điều tra.
Và kết luận cả loạt nói một dòng thì thế này ── I/O Windows là thiết kế nhất quán: quyết đích trong không gian tên, biến yêu cầu thành gói (IRP) chảy giữa các tầng, từng tầng chọn “xem, giữ, làm thay”. Dưới một dòng File.ReadAllText, cấu trúc 6 kỳ này chạy mỗi lần. Thay vì nhớ hành vi API, dẫn được “phải ra vậy” từ bản đồ này ── đó là sức loạt bài muốn bạn cầm. Cảm ơn đã đi cùng chuyến dài.
Bài viết liên quan
- Đáy I/O Windows (kỳ 1) ── mọi đọc ghi thành IRP: toàn cảnh hệ thống I/O
- Đáy I/O Windows (kỳ 4) ── Cache Manager: WriteFile của bạn đến đĩa khi nào
- Đáy I/O Windows (kỳ 5) ── cấu trúc trong của NTFS: hiểu hệ thống tệp từ MFT
- Hướng dẫn thực tế Process Monitor (ProcMon) ── xác định “cài đặt không được đọc”, “ACCESS DENIED” trong 10 phút
- Ứng dụng Windows tự phát bị coi là virus thì làm gì ── xử dương tính giả Microsoft Defender và sống với ảnh hưởng hiệu năng
- Thực tế Process Explorer / Handle / VMMap ── truy treo, rò, “tệp đang dùng” từ trạng thái ngay lúc này
- Danh sách kiểm bảo mật tối thiểu của ứng dụng Windows
Lĩnh vực tư vấn liên quan
KomuraSoft LLC nhận điều tra sự cố hiệu năng và lỗi ứng dụng nghiệp vụ Windows dính filter driver, kiểu “chỉ môi trường cụ thể chậm”, “phần mềm bảo mật can thiệp ứng dụng mình”.
- Phát triển ứng dụng Windows
- Điều tra lỗi và nguyên nhân
- Tư vấn kỹ thuật và đánh giá thiết kế
- Liên hệ với chúng tôi
Liên kết tham khảo
-
Microsoft Learn, About file system filter drivers. Về file system filter driver là driver tùy chọn cắt (intercept) được yêu cầu hướng tới hệ thống tệp hoặc filter driver khác; cắt yêu cầu thì mở rộng hay thay chức năng trước khi tới đích gốc, ghi nhận, giám sát, đổi dữ liệu, ngăn hành vi được; tiện ích chống virus, chương trình mã hóa, hệ thống quản lý lưu trữ phân tầng là ví dụ filter driver. ↩ ↩2 ↩3
-
Microsoft Learn, Filter Manager Concepts. Về Filter Manager (FltMgr) là driver chế độ kernel kèm Windows, công khai chức năng đơn giản hóa phát triển minifilter driver; minifilter đăng ký xử lý trước và sau thao tác I/O (callback pre/post); để sống cùng filter kế thừa, FltMgr gắn nhiều chỗ trên I/O stack như frame; minifilter unload rồi tải lại vẫn về cùng altitude cùng frame. ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, Advantages of the Filter Manager Model. Về lợi mô hình minifilter so với mô hình filter kế thừa: điều khiển thứ tự tải filter tốt hơn; khác filter kế thừa, minifilter tải được lúc bất kỳ; unload được; gắn volume DAX, v.v. ↩ ↩2
-
Microsoft Learn, Load order groups and altitudes for minifilter drivers. Về nhóm thứ tự tải theo mục đích được định cho file system filter, từng nhóm được gán dải altitude; mọi filter driver có định danh altitude duy nhất, quyết vị trí tương đối với filter khác trong I/O stack; ví dụ nhóm gồm FSFilter Activity Monitor (360000〜389999, quan sát và báo I/O), FSFilter Undelete (340000〜349999), FSFilter Anti-Virus (320000〜329999, phát hiện và diệt virus giữa I/O tệp), FSFilter Replication (300000〜309999), FSFilter Continuous Backup (280000〜289999). ↩ ↩2 ↩3
-
Microsoft Learn, Allocated altitudes. Về altitude minifilter do Microsoft phân bổ và quản lý, danh sách altitude đã gán được duy trì công khai; danh sách đó ghi WdFilter.sys là 328010 nhóm FSFilter Anti-Virus, cldflt.sys là 409500 nhóm FSFilter Top. ↩ ↩2 ↩3
-
Microsoft Learn, Configure and validate exclusions for Microsoft Defender Antivirus. Về cài đặt loại trừ Microsoft Defender đưa tệp, thư mục, tiến trình loại trừ ra khỏi đối tượng quét; loại trừ hạ mức bảo vệ nên phải định nghĩa thận trọng sau đánh giá sự cần thiết, được nhắc đi nhắc lại. ↩ ↩2 ↩3
-
Microsoft Learn, Set up a Dev Drive on Windows 11. Về Dev Drive là volume thiết kế cho khối lượng công việc phát triển, Microsoft Defender chạy chế độ hiệu năng (quét bất đồng bộ); được đặt là lựa chọn an toàn thay loại trừ thư mục (secure alternative to folder exclusions) trong khi cân tốc độ và hiệu năng; mặc định filter thêm không gắn Dev Drive; vận hành gỡ filter chống virus được cảnh báo là rủi ro bảo mật nghiêm trọng. ↩ ↩2 ↩3
-
Microsoft Learn, Request a Filter Altitude Identifier. Về xin altitude filter mới bằng email văn bản ASCII tiêu đề “Filter altitude request” gửi fsfcomm@microsoft.com; cần điền hết tên công ty, email liên hệ (alias công ty lâu dài, không phải cá nhân), tên sản phẩm, URL sản phẩm, mô tả filter, tên tệp filter, loại filter, loại start, nhóm thứ tự tải mong muốn, altitude mong muốn; nên dự kiến xử lý 30 ngày làm việc, không có cửa xin ngoài quy trình này; Microsoft có thể gán altitude khác mong muốn; đã có altitude số nguyên thì tự tạo altitude thập phân trong cùng nhóm thứ tự tải rồi báo sau được. ↩ ↩2
-
Microsoft Learn, Blocking legacy file system filter drivers. Về chạy
fltmc filterstừ command prompt quyền quản trị viên thì liệt kê filter 4 cột “Filter Name / Num Instances / Altitude / Frame”; mục cột Frame là<Legacy>là file system filter driver kế thừa không qua FltMgr; minifilter thì Frame chứa số (0, v.v.). ↩ ↩2 -
Microsoft Learn, Cloud Files API. Về Cloud Files API (cloud filter) là nền của engine đồng bộ hiện tệp trên đám mây như placeholder cục bộ, lúc truy cập thì lấy thực thể (Files On-Demand của OneDrive, v.v.). ↩ ↩2
-
Microsoft Learn, Process Monitor - Sysinternals. Về Process Monitor là công cụ giám sát nâng cao hiện thời gian thực hoạt động hệ thống tệp, registry, tiến trình/luồng (như bài viết, lúc chạy quan sát được nó hiện như minifilter trong danh sách fltmc). ↩ ↩2
Bài viết liên quan
Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.
Đáy I/O Windows (kỳ 5) ── cấu trúc trong của NTFS: hiểu hệ thống tệp từ MFT
Kỳ 5 loạt bài hình giải cấu trúc trong của NTFS. Sắp xếp MFT và bản ghi tệp, nhiều luồng dữ liệu (Zone.Identifier), hard link và tên 8.3,...
Đáy I/O Windows (kỳ 4) ── Cache Manager: WriteFile của bạn đến đĩa khi nào
Kỳ 4 loạt bài hình giải Cache Manager của Windows. Sắp xếp cache triển khai như file mapping, đọc trước và ghi trễ, cách dùng FlushFileBu...
Bên trong ảo hóa Windows (Phần 2) — Bộ nhớ ngay cả kernel cũng không thấy: VBS, HVCI và Credential Guard
Khi cài sạch trên phần cứng tương thích, VBS được bật mặc định và dùng hypervisor cùng SLAT để tạo cô lập mạnh hơn kernel. Bài viết này g...
Named pipe trong thực tiễn — IPC chuẩn của Windows, từ thiết kế đến bảo mật
Hướng dẫn thực tiễn về named pipe, cơ chế giao tiếp giữa các tiến trình chuẩn của Windows. Bài viết sắp xếp, từ nguồn gốc, việc chọn giữa...
Chọn tài khoản dịch vụ Windows — LocalSystem, tài khoản ảo và gMSA
Bạn vẫn chạy dịch vụ Windows dưới LocalSystem? Bài viết so sánh đặc quyền và danh tính mạng của LocalService, NetworkService, tài khoản ả...
Chủ đề liên quan
Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.
Chủ đề kỹ thuật Windows
Cổng vào phát triển Windows, điều tra lỗi và khai thác tài sản hiện có.
Dịch vụ liên quan đến chủ đề này
Bài viết liên quan trực tiếp đến các dịch vụ sau.
Phát triển ứng dụng Windows
Ứng dụng nghiệp vụ, tích hợp thiết bị và công cụ liên lạc, từ yêu cầu đến phát triển.
Câu hỏi thường gặp
Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.
- File system filter driver và minifilter khác nhau thế nào?
- Cả hai đều là "driver cắt vào yêu cầu I/O tới hệ thống tệp", nhưng thế hệ cách cắt khác nhau. Filter kế thừa (legacy) cũ chồng trực tiếp đối tượng thiết bị của mình lên device stack của hệ thống tệp; vị trí quyết theo thứ tự tải nên khó bảo đảm thứ tự, tải rồi thì không gỡ an toàn được, v.v. Chuẩn hiện nay là minifilter: đăng ký callback với Filter Manager (FltMgr) kèm Windows, kiểu "trước và sau thao tác này hãy gọi tôi". Vị trí quyết định tính bằng số gọi là altitude; tải được lúc bất kỳ, filter đã triển khai callback gỡ thì còn tháo được khi đang chạy. Filter hiện đại ── chống virus, mã hóa, công cụ giám sát, đồng bộ đám mây ── gần như tất cả triển khai thành minifilter.
- Vì sao phần mềm chống virus kiểm được mọi truy cập tệp?
- Vì OS chính thức chuẩn bị điểm mở rộng cho việc đó. Minifilter đăng ký với Filter Manager đoạn mã được gọi trước thao tác (callback pre) và sau thao tác (callback post) như mở, đọc, ghi tệp. Filter chống virus nằm dải altitude dành antivirus (320000〜329999); ví dụ ngay sau mở thành công (post-create) nó quét nội dung, có vấn đề thì hủy mở đó làm truy cập thất bại. Như kỳ 1, mọi I/O tệp chảy trên device stack, nên đứng đúng chỗ trên đường đi là kiểm được mọi truy cập. Không phải hack, mà cơ chế gắn trong thiết kế OS.
- Cài đặt loại trừ (loại trừ thư mục) của phần mềm chống virus về kỹ thuật đang làm gì?
- Với I/O tới đường khớp danh sách loại trừ, nó bỏ qua xử lý quét của filter sản phẩm đó. Bản thân filter không biến khỏi stack; hiểu gần thực tế hơn là phán đoán "đường này không kiểm" được làm sớm. Giới hạn quan trọng: loại trừ chỉ có hiệu với chính sản phẩm giữ cài đặt đó. Ví dụ cài đặt loại trừ Microsoft Defender chỉ đổi quét của filter Defender (WdFilter), không ảnh hưởng minifilter khác sống cùng ── chống virus hãng khác, EDR, sao lưu. Từng sản phẩm cần loại trừ riêng; "đã loại trừ mà vẫn chậm" thì có khi filter khác là nguyên nhân. Và như tài liệu Microsoft nhắc đi nhắc lại, loại trừ làm yếu bảo vệ chỗ đó, nên phải tối thiểu cùng đánh giá rủi ro. Cho phát triển, Dev Drive (chế độ hiệu năng = quét bất đồng bộ) được thiết kế như lựa chọn an toàn hơn loại trừ thư mục cũng đáng xem.
- Process Monitor ghi được toàn bộ I/O bằng cách nào?
- Vì chính Procmon, lúc khởi động, đăng ký mình với Filter Manager như minifilter thuộc dải altitude Activity Monitor (giám sát hoạt động). Mở Procmon rồi từ command prompt quyền quản trị viên chạy fltmc, sẽ thấy filter tên bắt đầu PROCMON xuất hiện trong danh sách. Đứng pre/post mọi thao tác I/O trên mọi volume với tư cách minifilter, nên ghi không sót tiến trình nào làm thao tác gì trên tệp nào. Thuật ngữ IRP và Fast I/O loạt bài đã xem hiện nguyên trong hiển thị Procmon, chính vì nó đứng quan sát ngay trên đường đi I/O.
- Build trên máy phát triển chậm, có nên nghi filter driver không?
- Rất đáng nghi. Build là khối tạo, đọc ghi, xóa hàng loạt tệp nhỏ; từng cái thành đối tượng kiểm của nhóm filter (đặc biệt quét chống virus), nên chi phí filter dễ lộ nhất ở khối lượng công việc này. Điều tra cơ bản: xem cột Duration trên Procmon để biết thời gian mất vào thao tác nào, rồi so sánh khác biệt cấu hình filter từng môi trường bằng fltmc instances. Đối phó gồm loại trừ sau khi đánh giá rủi ro, và dùng Dev Drive thiết kế riêng cho volume phát triển. Trên Dev Drive, chống virus chạy chế độ hiệu năng (quét bất đồng bộ); Microsoft đặt đó là lựa chọn an toàn hơn cài đặt loại trừ.