UEFI Runtime Driver là gì?

UEFI Runtime Driver là driver có code và data phải tồn tại sau ExitBootServices() để OS có thể gọi được. Nó khác DXE driver thông thường ở một điểm cốt lõi: toàn bộ code và data cần thiết sau EBS phải được đặt trong runtime memory - OS giữ lại vùng này sau khi firmware bàn giao.

Nếu viết runtime driver không đúng - dùng boot memory, quên convert pointer, hay gọi Boot Services sau EBS - lỗi thường không xuất hiện ngay. Nó xuất hiện khi OS gọi Runtime Service lần đầu sau SetVirtualAddressMap(), thường là crash im lặng hoặc wrong result.

DXE_RUNTIME_DRIVER vs DXE_DRIVER - khác nhau ở đâu

INF file - khai báo đúng module type

[Defines]
  MODULE_TYPE = DXE_RUNTIME_DRIVER
  BASE_NAME   = MyRuntimeDriver
  FILE_GUID   = ...
  ENTRY_POINT = MyRuntimeDriverEntryPoint

[Depex]
  gEfiVariableArchProtocolGuid AND
  gEfiVariableWriteArchProtocolGuid

MODULE_TYPE = DXE_RUNTIME_DRIVER cho firmware loader/build metadata biết đây là runtime-capable DXE driver. Khi image được load, code/data của image runtime driver sẽ được xử lý theo runtime memory type phù hợp để OS giữ lại sau ExitBootServices(). Tuy nhiên, các buffer private mà driver tự allocate vẫn phải dùng đúng memory type như EfiRuntimeServicesData - build system không tự biến mọi allocation thành runtime memory.

Register EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE

Đây là bước bắt buộc với mọi runtime driver có internal pointer:

EFI_STATUS EFIAPI
MyRuntimeDriverEntryPoint (
    IN EFI_HANDLE        ImageHandle,
    IN EFI_SYSTEM_TABLE  *SystemTable
    )
{
    EFI_STATUS Status;
    EFI_EVENT  VirtualAddressChangeEvent;

    // Khởi tạo runtime context, allocate runtime memory...
    Status = gBS->AllocatePool(
        EfiRuntimeServicesData,    // ← PHẢI dùng runtime type, không dùng EfiBootServicesData
        sizeof(MY_RUNTIME_CONTEXT),
        (VOID **)&mRuntimeContext
    );
    if (EFI_ERROR(Status)) return Status;

    // Register handler cho virtual address change
    Status = gBS->CreateEventEx(
        EVT_NOTIFY_SIGNAL,
        TPL_NOTIFY,
        MyVirtualAddressChangeHandler,
        NULL,
        &gEfiEventVirtualAddressChangeGuid,
        &VirtualAddressChangeEvent
    );
    if (EFI_ERROR(Status)) return Status;

    // Install protocol/arch protocol dùng trong boot phase, hoặc hook/register
    // runtime service entry point tùy driver/platform design.
    // Lưu ý: protocol handle database là Boot Services world - sau EBS, OS không
    // locate protocol. Runtime path phải đi qua gRT hoặc runtime entry point.
    return EFI_SUCCESS;
}

ConvertPointer - convert tất cả internal pointer

Khi OS gọi SetVirtualAddressMap(), firmware signal EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE. Handler phải convert mọi pointer trỏ vào runtime memory từ physical sang virtual:

VOID EFIAPI
MyVirtualAddressChangeHandler (
    IN EFI_EVENT  Event,
    IN VOID       *EventContext
    )
{
    // Pseudo-code - code thật phải cẩn thận thứ tự convert
    // Convert sub-pointer TRƯỚC qua local physical pointer, rồi convert context CUỐI
    MY_RUNTIME_CONTEXT *RuntimeContext = mRuntimeContext;  // giữ physical pointer để dereference

    gRT->ConvertPointer(0, (VOID **)&RuntimeContext->DataBuffer);   // sub-pointer trước
    gRT->ConvertPointer(0, (VOID **)&RuntimeContext->ServiceTable); // sub-pointer trước

    gRT->ConvertPointer(0, (VOID **)&mRuntimeContext);              // context pointer cuối

    // Sau khi mRuntimeContext đã được convert sang virtual address,
    // không tiếp tục dùng physical local pointer để dereference lung tung.
    // Code thật nên tách rõ phase convert và phase runtime access.
    // KHÔNG convert pointer trỏ vào boot memory
}

Những gì không được làm sau ExitBootServices

Runtime driver phải tự giới hạn sau khi EBS được gọi:

Pattern thực tế - runtime variable service

Một ví dụ phổ biến là UEFI Variable runtime driver. Nó phải hoạt động cả trước và sau EBS:

// Trước EBS: có thể dùng Boot Services bình thường
// Sau EBS: chỉ dùng runtime memory và runtime-safe backend theo platform

EFI_STATUS EFIAPI
RuntimeSetVariable (
    IN CHAR16                  *VariableName,
    IN EFI_GUID                *VendorGuid,
    IN UINT32                  Attributes,
    IN UINTN                   DataSize,
    IN VOID                    *Data
    )
{
    // Không gọi gBS->AllocatePool ở đây
    // Không gọi gBS->LocateProtocol ở đây
    // Dùng mRuntimeContext đã allocate với EfiRuntimeServicesData
    // Dùng runtime-safe backend tùy platform:
    // variable store, flash access, hoặc SMM communication tùy kiến trúc

    return VariableServiceInternal(mRuntimeContext, VariableName, ...);
}

ExitBootServices event - chốt ranh giới boot/runtime

Ngoài EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE, runtime driver thường cần register thêm EVT_SIGNAL_EXIT_BOOT_SERVICES để biết khi nào ranh giới boot/runtime xảy ra:

EFI_EVENT ExitBootServicesEvent;

gBS->CreateEventEx(
    EVT_NOTIFY_SIGNAL,
    TPL_NOTIFY,
    MyExitBootServicesHandler,
    NULL,
    &gEfiEventExitBootServicesGuid,
    &ExitBootServicesEvent
);

VOID EFIAPI
MyExitBootServicesHandler (
    IN EFI_EVENT  Event,
    IN VOID       *Context
    )
{
    // Chốt flag để code path sau này biết EBS đã xảy ra
    mAtRuntime = TRUE;

    // Dừng timer/event boot-time
    // Đóng/migrate resource boot-time
    // Từ đây không được gọi Boot Services nữa
}

Hai event này phục vụ hai mục đích khác nhau:

• EVT_SIGNAL_EXIT_BOOT_SERVICES - báo ranh giới boot/runtime, driver chốt flag và dừng dùng Boot Services
• EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE - báo OS đã map virtual address, driver convert pointer

Runtime driver phải hoạt động đúng ở cả hai giai đoạn: trước SetVirtualAddressMap() ở physical addressing, và sau đó ở virtual addressing. Bug thường chỉ lộ sau khi OS đã gọi SetVirtualAddressMap().

Failure pattern - runtime driver không hoạt động đúng sau boot

SetVariable fail từ OS sau khi Linux/Windows boot:

• Runtime driver dùng boot memory cho buffer → OS reclaim, data corrupt
• ConvertPointer bị quên cho một pointer → driver dereference physical address trong virtual space
• Xem thêm: firmware-flow/runtime-phase.mdx cho trace cụ thể từ OS side

Runtime driver crash im lặng:

• Sau SetVirtualAddressMap(), driver gọi pointer chưa convert
• Không có exception trong firmware context - crash trong SMM hoặc runtime call context khó trace

Driver hoạt động trong UEFI Shell nhưng fail sau OS boot:

• UEFI Shell chạy trước EBS - Boot Services vẫn available
• Sau OS boot, EBS đã xảy ra - driver không còn dùng được Boot Services
• Thường do driver gọi gBS-> trong code path được kích hoạt sau EBS

Trace khi runtime driver fail

# Trên Linux - xem runtime service có available không
dmesg | grep -i "efi\|runtime"

# Kiểm tra runtime memory regions
cat /proc/iomem | grep "EFI Runtime"

# Variable service fail
efibootmgr -v 2>&1
# EFI_ACCESS_DENIED, EFI_WRITE_PROTECTED → security/lock policy
# Crash/hang → có thể pointer convert bug trong runtime driver

# EDK II - tìm runtime driver
grep -r "DXE_RUNTIME_DRIVER\|EFI_RUNTIME_SERVICES_DATA" \
    edk2/ --include="*.inf" | head -10

grep -r "gEfiEventVirtualAddressChangeGuid\|ConvertPointer" \
    edk2/ --include="*.c" -l | head -10

Checklist Runtime Driver

• MODULE_TYPE = DXE_RUNTIME_DRIVER trong INF không?
• Tất cả allocation dùng EfiRuntimeServicesData, không phải EfiBootServicesData không?
• Driver có internal pointer dùng sau SetVirtualAddressMap() thì đã register EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE chưa?
• Có EVT_SIGNAL_EXIT_BOOT_SERVICES hoặc cơ chế tương đương để set runtime flag/dừng boot-time resource không?
• Mọi data/context/table pointer trong handler có được ConvertPointer không?
• Sau EBS: không có call nào đến Boot Services (AllocatePool, LocateProtocol...) không?
• Code path sau EBS có dùng chỉ runtime memory và pointer đã convert không?

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

1. Tại sao DXE_RUNTIME_DRIVER cần EfiRuntimeServicesData thay vì EfiBootServicesData?
2. EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE được signal khi nào và bởi ai?
3. Nếu quên ConvertPointer cho một pointer, lỗi xuất hiện lúc nào?
4. Tại sao driver hoạt động đúng trong UEFI Shell nhưng fail sau OS boot?
5. Sau ExitBootServices(), runtime driver còn được gọi những Boot Service nào?

Bài liên quan

• Runtime phase là gì?
• ExitBootServices là gì?
• Runtime Services là gì?
• UEFI Variable là gì?
• UEFI Service Driver là gì?

Nguồn tham khảo public

• UEFI Specification 2.11 - Runtime Services
• EDK II - RuntimeDxe
• EDK II - Variable RuntimeDxe
• EDK II UEFI Driver Writer’s Guide

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.

Chia sẻ Copy link

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.

Ghi chú/Firmware Execution Flow

BDS → TSL Handoff là gì?

Giải thích cách BDS chọn boot option, load EFI image và bàn giao cho OS loader trước ExitBootServices.

10 tháng 6, 2026Đọc tiếp →

Ghi chú/Firmware Execution Flow

Runtime sau ExitBootServices là gì?

Giải thích firmware còn lại gì sau khi OS gọi ExitBootServices và vì sao Runtime Services vẫn quan trọng.

10 tháng 6, 2026Đọc tiếp →

Ghi chú/Firmware Flow

TSL là gì?

Giải thích Transient System Load phase trong UEFI boot flow và vai trò của OS loader trước ExitBootServices.

10 tháng 6, 2026Đọc tiếp →

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