SmmReadyToLock là gì?
Giải thích SmmReadyToLock: mốc khóa SMM infrastructure, handler timing, policy lock và lỗi register quá muộn.
SmmReadyToLock là mốc firmware báo rằng SMM infrastructure đã đủ sẵn sàng để khóa lại. Sau mốc này, platform không nên cho phép register handler tùy tiện hoặc thay đổi policy bảo mật quan trọng.
Nói thực tế hơn: đây là lúc firmware đóng cửa phòng SMM trước khi boot flow tiến xa hơn và trước khi OS có cơ hội tương tác nhiều hơn với platform.
Luồng trước và sau SmmReadyToLock
SMM drivers load
SMM Core dispatch SMM drivers, driver register handler/service.
Security policy prepared
Flash, variable, communication buffer và SMRAM policy được thiết lập.
SmmReadyToLock
Firmware signal protocol/event báo SMM chuẩn bị khóa.
Close and lock
SMRAM/MMRAM, handler registration và policy nhạy cảm bị hạn chế.
Reject late changes
Late handler, debug command hoặc policy update không nên được chấp nhận tùy tiện.
Trong EDK II/PI-style firmware, SmmReadyToLock thường được thể hiện bằng protocol hoặc notification để các module SMM biết đã tới thời điểm khóa. Tên và implementation cụ thể có thể khác theo vendor, nhưng ý tưởng chung là giống nhau: đừng để SMM còn mở quá lâu.
Tại sao mốc này quan trọng?
| Mục | Giá trị | Ghi chú |
|---|---|---|
| Lock quá sớm | Driver chưa register xong | Functionality fail, handler thiếu, service im lặng không chạy. |
| Lock quá muộn | Policy mở quá lâu | OS hoặc attacker có thêm cửa thay đổi policy hoặc dùng debug command. |
| Lock đúng lúc | Driver xong, policy xong | SMM sẵn sàng phục vụ runtime request nhưng không cho late mutation tùy tiện. |
| Debug khó | Lỗi timing | Một thay đổi DEPEX nhỏ cũng có thể làm driver dispatch sau lock. |
SmmReadyToLock và EndOfDxe
Hai mốc này dễ bị nhầm vì thường nằm gần nhau trong boot flow.
| Mục | Giá trị | Ghi chú |
|---|---|---|
| EndOfDxe | Mốc rộng của DXE | Nhiều policy chung bắt đầu được chốt trước BDS. |
| SmmReadyToLock | Mốc riêng cho SMM | Tập trung vào close/lock SMM infrastructure và late registration. |
| Quan hệ | Platform-dependent | Có thể gần nhau, nhưng không nên xem là cùng một event. |
Khi debug, hãy log cả hai mốc. Nếu chỉ log một mốc, bạn khó biết driver fail vì DXE policy chung hay vì SMM lock cụ thể.
Failure pattern hay gặp
| Mục | Giá trị | Ghi chú |
|---|---|---|
| Handler không chạy | Register quá muộn | SMM driver dispatch sau lock nên handler không được register đúng. |
| Register trả ACCESS_DENIED | Late registration bị block | Đây có thể là behavior đúng nếu policy đã khóa. |
| Service biến mất sau refactor | DEPEX thay đổi | Một dependency mới có thể làm dispatch order lùi sau SmmReadyToLock. |
| Security review fail | Lock quá muộn | Command debug hoặc policy update còn mở khi runtime đã gần OS. |
| Bug chỉ xuất hiện release build | Timing khác debug build | Log, assert hoặc build option có thể làm dispatch order khác. |
Debug Diary: handler register trả ACCESS_DENIED
Một SMM driver mới được thêm vào để xử lý một command OEM. Build pass, module có trong FV, entrypoint có log. Nhưng Register() trả EFI_ACCESS_DENIED, hoặc handler không bao giờ nhận command.
Cách debug đúng là dựng timeline:
Driver entrypoint
Driver có thật sự chạy không? Chạy lúc nào?
So với SmmReadyToLock
EntryPoint xảy ra trước hay sau mốc lock?
Dependency
Protocol dependency nào làm driver dispatch muộn?
Firmware volume
Module có nằm đúng FV mà SMM Core dispatch trước lock không?
Sửa timing
Sửa dependency, placement hoặc registration path thay vì bỏ policy lock.
Nếu register muộn, fix đúng thường là sửa DEPEX, firmware volume placement hoặc logic dispatch. Bỏ check lock chỉ để handler chạy là fix nguy hiểm.
Checklist SmmReadyToLock
SmmReadyToLock checklist
Câu hỏi tự kiểm tra
Tự kiểm tra sau khi đọc note này
Blog seeds
- SmmReadyToLock Explained: mốc khóa khó debug nhất trong SMM
- Late SMM Driver Dispatch: vì sao handler im lặng không chạy?
- EndOfDxe vs SmmReadyToLock: timeline security trong UEFI firmware
Bài liên quan
- SMM Architecture Overview
- EndOfDxe là gì?
- SMM Driver là gì?
- SMM Handler là gì?
- SMM Communication là gì?
- SMRAM là gì?
Nguồn tham khảo public
Thấy nội dung này hữu ích?
Lưu lại hoặc chia sẻ cho người cũng đang học firmware, BIOS/UEFI và embedded systems.
Nội dung liên quan
Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.
SMM Handler là gì?
Giải thích SMM handler: code xử lý SMI source, validate input, policy check và failure pattern khi debug.
SMM Communication là gì?
Giải thích SMM Communication: kênh request vào SMM, CommBuffer, validation, nested pointer và checklist security.
SMM Vulnerability là gì?
Giải thích SMM vulnerability: CommBuffer lỗi, nested pointer, SMRAM exposure, lock timing và checklist review.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.