SMM Save State là gì?
Giải thích SMM Save State: snapshot CPU context khi vào SMM, cách dùng khi debug SW SMI và các giới hạn.
SMM Save State là vùng lưu context CPU khi CPU nhận SMI# và chuyển vào SMM. Nhờ save state, SMM handler có thể biết CPU đang ở đâu, register nào có giá trị gì, hoặc instruction nào liên quan tới SMI trong một số trường hợp.
Mental model: Save State là snapshot để CPU có thể rời OS/DXE, chạy SMM, rồi quay lại đúng chỗ cũ bằng RSM.
Save State xuất hiện khi nào?
OS/DXE đang chạy
CPU đang thực thi code bình thường.
CPU enters SMM
CPU lưu context hiện tại vào save state area.
Handler runs
SMM handler có thể đọc một số register/context cần thiết.
Restore context
CPU khôi phục state và quay lại nơi đang chạy trước đó.
Trong hệ thống nhiều core, mỗi CPU có save state riêng. Vì vậy khi debug SMI, câu hỏi không chỉ là “register có giá trị gì”, mà còn là CPU nào đang được đọc.
Save State giúp debug gì?
| Mục | Giá trị | Ghi chú |
|---|---|---|
| RIP/EIP | Instruction pointer | Biết CPU đang ở đâu khi SMI xảy ra. |
| RAX/AL | Command hoặc data | Với một số SW SMI path, command có thể nằm trong AL tùy convention platform. |
| I/O context | Port access info | Một số platform cho biết I/O instruction liên quan tới SMI. |
| CPU index | CPU nào vào SMM | Quan trọng với multi-core SMI handling và rendezvous. |
| Register snapshot | Debug context | Giúp trace caller nhưng không thay thế validation CommBuffer. |
Khi nào không nên tin Save State quá mức?
Save State rất hữu ích, nhưng không nên biến nó thành nguồn sự thật duy nhất.
| Mục | Giá trị | Ghi chú |
|---|---|---|
| Platform-specific | Layout khác nhau | Một số chi tiết save state phụ thuộc CPU/platform hoặc abstraction của firmware. |
| Wrong CPU | Đọc nhầm CPU index | Trong hệ thống multi-core, handler có thể đọc state của CPU không phải CPU trigger. |
| Calling convention | Command không luôn nằm ở AL | Không được giả định mọi SW SMI đều truyền command giống nhau. |
| Security | Register cũng là input | Attacker có thể kiểm soát register trước khi trigger SMI. |
| FPU/SIMD | Không phải state nào cũng tự động an toàn | Không nên dùng FPU/SIMD trong SMM nếu không hiểu save/restore requirement. |
Debug Diary: command đúng nhưng handler đọc sai
Một case rất khó chịu: caller gửi OUT 0xB2, 0x42, nhưng handler log ra command khác. Người debug thường nghi port 0xB2 hoặc SMI source sai, nhưng lỗi có thể nằm ở chỗ handler đọc command từ sai nguồn.
Có ba khả năng cần tách ra:
Trigger convention
Caller truyền command bằng AL, port data, context hay CommBuffer?
Read đúng CPU chưa?
Handler có đang đọc state của CPU trigger không?
Decode đúng format chưa?
Command width, offset và version có đúng với platform không?
Reject nếu không rõ
Nếu command không hợp lệ, trả EFI_INVALID_PARAMETER hoặc EFI_UNSUPPORTED.
Sai assumption ở đây làm debug rất mất thời gian. Cách tốt nhất là log cả trigger path, CPU index, command ID và source của command.
Checklist khi đọc Save State
Khi đọc SMM Save State
Câu hỏi tự kiểm tra
Tự kiểm tra sau khi đọc note này
Blog seeds
- SMM Save State Explained: CPU nhớ gì khi bước vào SMM?
- Debug SW SMI bằng Save State: command nằm ở đâu?
- Multi-core SMM Debug: đọc nhầm CPU Save State nguy hiểm thế nào?
Bài liên quan
- SMM Architecture Overview
- SW SMI là gì?
- SMM Handler là gì?
- SMRAM là gì?
- MMRAM là gì?
- SMM Vulnerability 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.