SEC là gì trong UEFI?

SEC (Security) là phase đầu tiên của PI firmware, chạy ngay sau khi CPU thoát khỏi reset vector. Ở thời điểm này, DRAM chưa sẵn sàng, stack thông thường chưa có, và gần như không có service nào để dùng. SEC phải tự tạo ra điều kiện tối thiểu để PEI Core có thể bắt đầu chạy.

Bài này lấy góc nhìn phổ biến trên x86/EDK II, nơi SEC thường liên quan đến reset vector, microcode update và Cache-As-RAM. Trên architecture khác, chi tiết implementation có thể khác, nhưng vai trò tổng quát của SEC vẫn là tạo môi trường tối thiểu để vào PEI.

Nếu PEI là giai đoạn làm cho platform đủ sống, thì SEC là giai đoạn làm cho CPU đủ tỉnh để PEI có thể bắt đầu.

01 Reset Vector

CPU bắt đầu

CPU nhảy tới địa chỉ reset vector trong flash, thường là 0xFFFFFFF0 trên x86.

02 Early CPU Init

Microcode + cache

Load microcode update, tắt cache cũ, chuẩn bị điều kiện để dựng CAR.

03 CAR Setup

Cache-As-RAM

Dùng CPU cache như RAM tạm. Từ đây mới có stack và global data cơ bản.

04 PEI Handoff

Gọi PEI Core

Truyền thông tin tối thiểu (top of CAR, firmware volume) sang PEI Core entry point.

SEC làm những việc gì?

SEC có nhiệm vụ rất giới hạn - chỉ những gì cần thiết để PEI Core có thể chạy được.

Cache-As-RAM là gì và tại sao cần?

Đây là điểm người mới hay bỏ qua nhất khi đọc về SEC.

Ngay sau reset, DRAM chưa được khởi tạo - không có RAM nào để dùng. Nhưng để chạy code C cơ bản, CPU cần ít nhất một stack. Giải pháp là dùng CPU cache như RAM tạm: cấu hình một vùng cache theo địa chỉ cụ thể để nó không evict ra DRAM - vì DRAM chưa tồn tại.

Kỹ thuật này gọi là Cache-As-RAM (CAR), hay còn gọi là No-Eviction Mode trên một số kiến trúc Intel.

Sau khi CAR được thiết lập:
  ┌──────────────────────────────┐
  │   CPU Cache (vd: 256KB)      │
  │   → hoạt động như RAM tạm    │
  │   → có stack, có local vars  │
  │   → KHÔNG có global heap     │
  │   → KHÔNG thể allocate tùy ý │
  └──────────────────────────────┘
  DRAM: chưa khởi tạo, không dùng được

SEC và đầu PEI đều chạy trong môi trường này. Khi PEI khởi tạo xong DRAM, firmware thực hiện memory migration - copy stack và data từ CAR sang DRAM thật, rồi tắt CAR.

Tại sao SEC viết bằng assembly hoặc C rất hạn chế?

Trước khi CAR được thiết lập, không có stack. Không có stack nghĩa là:

• Không thể call function thông thường (return address lưu ở đâu?)
• Không có local variable
• Không có global data khởi tạo

Vì vậy phần code đầu tiên của SEC - trước khi CAR sẵn sàng - thường viết bằng assembly. Sau khi CAR thiết lập xong, mới có thể gọi C function, nhưng vẫn phải rất cẩn thận về kích thước stack và global data.

Đây là lý do khi đọc EDK II source, bạn sẽ thấy các file .nasm hoặc .asm trong SEC module trước khi vào C entry point.

Một hệ quả thực tế: giai đoạn này gần như không có cách debug thông thường. Không có serial output, không có JTAG debugger hỗ trợ đầy đủ ở thời điểm này, không có log. Nếu code bị sai, thường chỉ có thể quan sát qua POST code hoặc oscilloscope. Khi làm việc trong .nasm SEC, cách duy nhất để biết trạng thái là đọc trực tiếp các thanh ghi như al, bh, eax, ebx - không có variable watch, không có call stack, không có breakpoint có ý nghĩa.

SEC handoff sang PEI như thế nào?

Khi SEC hoàn tất, nó gọi PEI Core entry point và truyền vào một struct SecCoreData chứa:

// EFI_SEC_PEI_HAND_OFF - định nghĩa trong MdePkg/Include/Pi/PiPei.h
typedef struct _EFI_SEC_PEI_HAND_OFF {
  UINT16    DataSize;                   // size của struct này
  VOID      *BootFirmwareVolumeBase;    // base của firmware volume chứa PEI Core
  UINTN     BootFirmwareVolumeSize;
  VOID      *TemporaryRamBase;          // base của toàn bộ vùng CAR
  UINTN     TemporaryRamSize;
  VOID      *PeiTemporaryRamBase;       // phần CAR dành riêng cho PEI heap
  UINTN     PeiTemporaryRamSize;
  VOID      *StackBase;                 // stack trong CAR
  UINTN     StackSize;
} EFI_SEC_PEI_HAND_OFF;

PEI Core dùng thông tin này để biết mình đang có bao nhiêu RAM tạm, stack ở đâu, và firmware volume nằm ở đâu để tìm PEIM tiếp theo.

Khi nào cần quan tâm đến SEC?

Nếu bạn viết DXE driver hay PEIM thông thường, bạn hầu như không cần đụng tới SEC. SEC là lớp rất thấp, thường do silicon vendor hoặc platform owner viết và ít khi thay đổi.

Bạn cần quan tâm đến SEC khi:

• Debug board chết rất sớm, chưa có POST code hay serial log
• Thay đổi CPU hoặc platform yêu cầu update microcode path
• Gặp lỗi liên quan CAR setup - reset loop không rõ nguyên nhân ở giai đoạn cực sớm
• Port firmware sang platform mới và cần hiểu early boot sequence

Dấu hiệu lỗi có thể nằm ở SEC

• Board không có POST code nào - chưa vào được PEI.
• Serial log không xuất hiện dù UART đã cấu hình.
• Reset loop xảy ra trước khi memory init log xuất hiện.
• Lỗi sau khi update microcode hoặc thay CPU.
• CAR region bị overlap hoặc size không đủ cho SEC + PEI stack.
• Flash image bị corrupt ở vùng SEC/PEI firmware volume.

Lỗi hiểu nhầm hay gặp

SEC không khởi tạo DRAM. SEC chỉ dựng CAR - RAM tạm từ CPU cache. DRAM thật được khởi tạo bởi memory init PEIM trong PEI phase.

SEC không chạy C runtime thông thường. Trước khi CAR sẵn sàng, không có stack, không có local variable, không có global data. Code SEC đầu tiên thường là assembly.

Reset vector không phải là BIOS entry point theo nghĩa thông thường. 0xFFFFFFF0 chỉ là 16 byte trước top of 4GB address space - thường chỉ đủ cho một jump instruction. Code thật của SEC nằm ở nơi khác trong flash.

Tên “Security” không có nghĩa SEC xử lý security policy. Trong PI spec, “Security” ở đây là về việc đảm bảo firmware chạy trong môi trường đáng tin cậy trước khi thực thi bất kỳ code nào khác - không phải cryptographic security hay access control.

Bài liên quan

• PEI là gì?
• HOB là gì?
• Firmware Execution Flow Overview

Nguồn tham khảo public

• UEFI PI Specification 1.9 - Volume 1: PEI Core Interface
• EDK II - SecMain.c (x86 SEC reference)
• EDK II - ResetVector (x86 assembly)

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

Firmware Execution Flow Overview

Knowledge map về luồng thực thi firmware từ SEC, PEI, DXE, BDS tới TSL và Runtime.

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

Blog/BIOS / UEFI

UEFI Boot Flow: từ Reset Vector đến ExitBootServices

Không phải học để thuộc tên phase. Học boot flow để biết máy đang chết ở đâu, và debug theo hướng nào: từ SEC đến Runtime.

2 tháng 5, 2026Đọc tiếp →

Ghi chú/STM32 / Firmware

Reset Vector và Bootloader trên Cortex-M: VTOR, MSP và jump sequence

Reset vector là gì, VTOR hoạt động ra sao, và chuỗi bước cần thiết để bootloader jump đúng cách vào application - tránh crash sau khi có interrupt đầu tiên.

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