Legacy option ROMs cannot be enabled on UEFI-only systems

Question

问题：在UEFI-only系统（如搭载Intel Tiger Lake或更新平台的设备）上，为何无法启用传统选项ROM（Legacy Option ROMs）？该限制如何影响PCIe设备（如独立网卡或RAID卡）的兼容性？尝试通过BIOS设置启用CSM（Compatibility Support Module）时提示“CSM不可用”或灰色不可选，其根本原因是什么？这是否意味着此类设备必须提供UEFI驱动才能实现预启动环境下的正常工作（如PXE启动或磁盘初始化）？请结合UEFI安全启动机制与固件执行模式分析此技术瓶颈。

Answer 1

UEFI-only系统中传统Option ROM与CSM不可用的技术解析

1. 背景与基础概念：什么是Option ROM与CSM？

在x86架构的PC启动过程中，固件（如BIOS或UEFI）负责初始化硬件并加载操作系统。传统BIOS系统使用Option ROM机制来支持PCI/PCIe设备在预启动阶段的功能扩展，例如网卡的PXE启动、RAID卡的磁盘管理等。这些Option ROM是固化在设备上的16位实模式代码，由系统BIOS在POST阶段加载执行。

Compatibility Support Module (CSM) 是UEFI固件中的一项兼容性组件，用于模拟传统BIOS环境，使UEFI平台能够运行Legacy BIOS操作系统和使用Legacy Option ROM的设备。

然而，在现代平台（如Intel Tiger Lake及更新的CPU平台）上，许多OEM厂商已移除CSM支持，导致系统进入“UEFI-only”模式。

2. 深层原因分析：为何UEFI-only系统无法启用传统Option ROM？

• 执行模式不兼容：传统Option ROM基于16位实模式x86代码，而UEFI运行在保护模式或长模式下，缺乏对实模式执行环境的支持。
• 固件架构演进：UEFI设计初衷即为取代BIOS，采用模块化驱动模型（EFI驱动），不再依赖ROM中的原始二进制代码。
• 安全启动（Secure Boot）要求：Secure Boot仅验证签名的UEFI驱动，传统Option ROM无数字签名机制，无法通过验证。
• CSM被硬件级禁用：Tiger Lake及以后平台的FSP（ Firmware Support Package）默认禁用CSM，且部分SKU物理上移除相关代码。

3. 技术瓶颈：CSM灰色不可选的根本原因

平台代际	CSM支持状态	UEFI强制级别	典型厂商策略
Sky Lake 及更早	可配置开启/关闭	可选	Dell, HP, Lenovo 支持 Legacy 启动
Comet Lake	部分机型保留	过渡期	OEM可选择是否提供CSM
Tiger Lake	多数型号移除	强制UEFI-only	Dell Latitude 5xxx系列禁用CSM
Alder Lake 及更新	完全移除	硬件级锁定	Microsoft Pluton安全芯片集成影响

根本原因在于：Intel在FSP-M（Management Engine Firmware）中硬编码禁用CSM入口点，即使主板厂商想提供选项，也无法绕过平台级限制。此外，UEFI Spec 2.7之后推荐将CSM标记为“可选”，推动行业向纯UEFI迁移。

4. 对PCIe设备兼容性的影响

独立设备如：

1. 传统千兆/万兆网卡（未提供UEFI PXE驱动）→ 无法进行网络启动
2. LSI/Broadcom RAID卡（仅含Legacy Option ROM）→ 预启动环境下无法识别阵列
3. GPU显卡（VGA BIOS）→ 在UEFI GOP缺失时可能导致显示初始化失败
4. 第三方HBA卡 → 磁盘不可见于UEFI Shell或OS安装器

此类设备若未发布UEFI驱动（EFI Driver）或UEFI Capsule更新固件，则在UEFI-only系统中功能受限甚至完全失效。

5. 解决方案路径与技术应对策略

graph TD
    A[设备无法正常工作] --> B{是否具备UEFI驱动?}
    B -- 是 --> C[安装UEFI DXE驱动至NVRAM或Option ROM]
    B -- 否 --> D[联系厂商获取UEFI固件更新]
    D --> E[通过UEFI Capsule更新设备固件]
    C --> F[在UEFI Shell中验证驱动加载]
    E --> F
    F --> G[启用Secure Boot兼容签名]
    G --> H[实现PXE/磁盘初始化等预启动功能]

实际部署建议：

• 优先选用支持UEFI UNDI（Universal Network Device Interface）的网卡
• 确保RAID控制器支持UEFI Driver Model (UDM)
• 利用UEFI HTTP Boot替代传统PXE，减少对Option ROM依赖
• 在企业环境中集中管理SBOM（Software Bill of Materials）以追踪固件兼容性

6. 安全启动机制与执行模式的协同约束

UEFI Secure Boot要求所有预启动代码必须经过PKI签名验证。传统Option ROM不具备PE/COFF格式结构，也无Authenticode签名，因此被固件直接拒绝加载。

// 示例：UEFI驱动签名验证流程（简化伪代码）
EFI_STATUS LoadAndVerifyDriver(IN EFI_DEVICE_PATH_PROTOCOL *FilePath) {
    ImageBuffer = ReadImageFromFile(FilePath);
    if (!IsPeCoffImage(ImageBuffer)) {
        return EFI_INVALID_IMAGE;
    }
    if (FeatureIsEnabled(SecureBoot)) {
        if (!VerifyImageSignature(ImageBuffer)) {
            Print(L"Driver signature invalid!\n");
            return EFI_SECURITY_VIOLATION;
        }
    }
    return LoadImageToMemory(ImageBuffer);
}

该机制虽提升安全性，但也构成对Legacy代码的硬性隔离。只有符合EFI_DRIVER_BINDING_PROTOCOL规范并由可信CA签发的驱动才能在Secure Boot开启时运行。