Security / SMM / Firmware Stable

SW SMI là gì?

Giải thích SW SMI: OUT 0xB2, command ID, SMM dispatch, handler registration, failure pattern và checklist debug bảo mật.

14 tháng 10, 2024 Cập nhật 12 tháng 6, 2026 6 phút đọc

Đọc bằng Tiếng Việt English 日本語

SW SMI, Software System Management Interrupt, là cách software chủ động yêu cầu CPU đi vào SMM. Trên nhiều PC platform, ví dụ kinh điển là ghi command vào APM control port:

mov al, 42h
out 0B2h, al

Sau lệnh này, chipset tạo SMI#, CPU vào SMM, rồi SMM dispatcher tìm handler tương ứng với command 0x42.

01 Caller

OUT 0xB2, 0x42

Software gửi command ID tới port hoặc cơ chế platform định nghĩa.

02 Chipset

Generate SMI#

Chipset báo CPU chuyển vào System Management Mode.

03 SMM

Read command

SMM Core/handler đọc command hoặc Save State để biết request.

04 Handler

Execute service

Handler xử lý command, validate input và trả về.

05 Return

RSM

CPU quay lại context cũ sau khi handler kết thúc.

Một luồng SW SMI điển hình.

SW SMI không phải API bình thường

Điểm dễ hiểu sai nhất: OUT 0xB2 nhìn giống một function call cực đơn giản, nhưng thực chất đây là đường vào privilege rất cao. Khi handler chạy trong SMM, nó có thể chạm tới resource mà OS bình thường không nên chạm vào, ví dụ variable store, SPI flash policy hoặc chipset register nhạy cảm.

Vì vậy SW SMI không nên được thiết kế như một API công khai tùy tiện. Mọi input đi vào handler phải được xem là không đáng tin.

Command value có ý nghĩa gì?

Command 0x42 không có nghĩa universal cho mọi máy. Nó phụ thuộc platform/OEM. Trong một project, 0x42 có thể là “update setup option”; trong project khác có thể không dùng gì cả.

Mục	Giá trị	Ghi chú
0xB2	APM control port phổ biến	Thường dùng làm SW SMI trigger trên legacy PC-compatible platform, nhưng vẫn là platform-specific.
AL / Data	Command ID	SMM handler dùng giá trị này để dispatch service phù hợp.
0xB3	Data port trong một số thiết kế	Có platform dùng thêm để truyền tham số nhỏ, không nên assume universal.
CommBuffer	Buffer cho request phức tạp	Với request lớn, SMM Communication thường rõ ràng và dễ validate hơn.
Save State	Nguồn đọc context	Handler có thể đọc I/O state hoặc register context từ Save State tùy implementation.

Handler được register như thế nào?

Trong EDK II style code, SW SMI handler thường được register qua SMM SW Dispatch protocol. Ví dụ public-safe, chỉ để minh họa ý tưởng:

Context.SwSmiInputValue = 0x42;

Status = SmmSwDispatch2->Register (
  SmmSwDispatch2,
  MySwSmiHandler,
  &Context,
  &DispatchHandle
);

Nếu command bạn trigger là 0x42 nhưng handler register với value khác, handler sẽ không chạy. Nếu driver register quá muộn, ví dụ sau khi platform đã lock policy liên quan, service cũng có thể im lặng không hoạt động.

Debug Diary: OUT 0xB2 nhưng không thấy log

Nếu bạn trigger SW SMI mà serial log trong handler không xuất hiện, đừng kết luận ngay là handler sai. Hãy kiểm tra theo thứ tự:

SW SMI không chạy

SMI global enable đã bật chưa?
APM/SW SMI source có bị disable hoặc lock bởi chipset policy không?
Bạn đang dùng đúng port/cơ chế của platform đó chưa?
Handler đã register đúng command ID chưa?
Handler register trước thời điểm policy bị lock chưa?
DEBUG level trong SMM image có bật không? DebugLib có output ra serial không?

Một trick thực tế là log cả phía caller lẫn phía handler. Nếu caller log “before OUT 0xB2” và “after OUT 0xB2” đều xuất hiện, nhưng handler không log gì, khả năng cao SMI không vào đúng handler hoặc log SMM bị tắt. Nếu caller log trước trigger rồi máy reset, nghi exception trong SMM hoặc chipset response bất thường.

Failure pattern hay gặp

Mục	Giá trị	Ghi chú
OUT 0xB2 không có log	SMI không vào handler	Kiểm tra SMI enable, SW SMI source, port, command ID, handler registration và DebugLib.
Handler chạy sai service	Command mapping sai	Command value là platform-specific, không được assume 0x42 luôn có cùng ý nghĩa.
Máy reset sau SW SMI	Exception trong SMM	Nghi pointer sai, CommBuffer chưa validate, gọi service không hợp lệ hoặc access register sai.
Lỗi chỉ xảy ra sau update BIOS	Dispatch order hoặc lock timing đổi	Driver có thể register muộn hơn hoặc command table thay đổi.
Security finding	Handler trust input	Thiếu validate size, address, nested pointer hoặc quyền truy cập.

Validate input đi vào SMM

Sai lầm thường gặp là xem SW SMI như một API bình thường. Thực tế, nó là đường vào đặc quyền cao. Nếu handler nhận command từ OS mà không validate buffer, size, address hoặc quyền truy cập, OS-level attacker có thể biến service firmware thành primitive để đọc/ghi vùng nhạy cảm.

if (!IsBufferOutsideMmram (CommBuffer, CommSize)) {
  return EFI_SECURITY_VIOLATION;
}

Đoạn trên chỉ là pseudo code public-safe. Tư duy quan trọng là: dữ liệu đi vào SMM luôn phải được xem là không đáng tin. Không chỉ buffer ngoài cùng, nested pointer bên trong buffer cũng cần validate.

Khi nào nên dùng SMM Communication thay vì SW SMI thô?

Nếu request chỉ là command nhỏ, SW SMI command ID có thể đủ. Nhưng nếu cần truyền struct, buffer lớn hoặc kết quả phức tạp, SMM Communication rõ ràng hơn vì có cơ chế CommBuffer và GUID/message format dễ kiểm soát hơn.

Mục	Giá trị	Ghi chú
SW SMI command	Request rất nhỏ	Phù hợp command ID đơn giản, platform-specific, ít dữ liệu.
SMM Communication	Request có payload	Phù hợp buffer/struct phức tạp, cần validate size, GUID và message type rõ ràng.
Runtime Service path	OS-facing standard API	Ví dụ SetVariable từ OS đi qua Runtime Services, bên dưới platform có thể route vào SMM.

Câu hỏi tự kiểm tra

Tự kiểm tra sau khi đọc note này

Vì sao 0x42 không có ý nghĩa universal trên mọi platform?
Nếu OUT 0xB2 không thấy log handler, bạn kiểm tra những điểm nào trước?
SW SMI khác gì so với SMM Communication?
Tại sao handler phải validate CommBuffer và nested pointer?
Một SW SMI gây reset ngay sau trigger thường gợi ý những lỗi nào?

Bài liên quan

Nguồn tham khảo public

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.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác