uefi和secure boot不是一回事：secure boot是uefi规范强制要求实现的安全子模块，自uefi 2.3.1起内置于固件中，依赖uefi的efi执行环境、nvram密钥存储和模块化驱动架构才能运行；uefi可关闭secure boot，但secure boot无法脱离uefi独立工作。
你想弄清楚UEFI和Secure Boot到底是不是一回事，为什么有的电脑开了Secure Boot就装不了旧系统，关了又怕被恶意启动程序 hijack——这背后不是开关问题，而是信任链的建立与执行逻辑。
Secure Boot是UEFI规范的一部分，不是可选插件
Secure Boot不是独立于UEFI运行的附加功能，它从UEFI 2.3.1 Errata C版本起就被写进规范正文，属于UEFI固件必须实现的安全子模块。没有Secure Boot支持的固件，严格意义上不能自称“符合UEFI标准”。
这意味着：只要主板标称支持UEFI，其固件中必然内置Secure Boot引擎，哪怕默认关闭，底层验证逻辑也始终存在。
这一步操作起来很简单，直接把文件拖进去就行。
Secure Boot依赖UEFI的执行环境才能工作
Secure Boot无法在传统BIOS环境下运行，因为它需要UEFI提供的三项基础能力：
① EFI执行环境：能加载并运行.efi格式的签名二进制文件（如shim.efi、bootmgfw.efi）；
② NVRAM密钥存储空间：用于持久化保存PK（平台密钥）、KEK（密钥交换密钥）、db（允许签名数据库）和dbx（吊销签名数据库）；
③ 模块化驱动架构：允许在启动早期就加载签名验证驱动，而非等到操作系统接管后才开始校验。
【没有UEFI执行环境，Secure Boot连第一步签名验证都无法触发】
UEFI可以不启用Secure Boot，但Secure Boot绝不能脱离UEFI
方法一：纯UEFI模式（Secure Boot关闭）
此时固件仍以64位保护模式运行，使用GPT分区表，从ESP分区加载/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi等引导文件，但不对该文件做签名检查——任何未签名或自签名的.efi程序都能执行。
方法二：UEFI+Secure Boot启用
固件会逐级验证：先用PK验证KEK有效性→再用KEK验证db/dbx更新→最后用db中记录的公钥哈希值校验bootmgfw.efi签名→签名无效或出现在dbx中则直接终止启动。
方法三：CSM启用+Secure Boot强制禁用
当开启CSM（兼容性支持模块）时，UEFI固件会切换至Legacy BIOS仿真模式，此时Secure Boot自动失效——因为CSM绕过了UEFI原生启动路径，转而执行MBR+16位实模式代码，而Secure Boot验证引擎根本无法解析这类无签名的传统引导扇区。
注意：某些OEM厂商会在CSM开启时隐藏Secure Boot选项，不是设置丢失，而是逻辑上不可见。
信任链从UEFI固件开始，不是从Windows或Linux开始
第一步：加电后，UEFI固件自身从SPI Flash读取PK（平台密钥），该密钥由主板厂商烧录，用户通常无法修改；
第二步：固件用PK验证KEK签名，KEK由微软、Canonical等OS厂商提交，用于后续更新db；
第三步：用KEK验证db更新包，db中存的是shim.efi、grubx64.efi、bootmgfw.efi等引导程序的公钥证书哈希；
第四步：加载bootmgfw.efi时，固件调用内建验证引擎比对签名，通过才移交控制权；
【若在第三步手动清空db，所有第三方引导器将立即无法启动，包括已安装的Linux发行版】
