UEFI Secure Boot

本文参考：https://www.suse.com/media/presentation/uefi_secure_boot_webinar.pdf

Secure Boot

UEFI

UEFI: Unified Extensible Firmware Interface
–基于旧的已存在的标准EFI。
–用于替代传统的BIOS。

Secure Boot

–用于防止执行一个已被感染的OS。
–它只是UEFI的一种特性表现。
–Specified in version 2.3.1c of the standard

Trust Model: 信任模型

Secure Boot 通过在firmware中嵌入几个公钥数据库：
1,UEFI firmware 加载的任何东西都必须由其中一个密钥签名signed.
2,签名signature能表达"trust"信任关系。
3,包括OS loader, UEFI modules, firmware updates
4,任何没有可用签名signature的东西都是不可信任的，并阻止加载loaded.

5,还有一个数据库，其中包含了一些已知恶意软件的哈希码。这不是一个病毒扫描程序。

Physical Presence:
标准允许firmware disable所有的这些检查。
–这意味着，它允许提供一个setup 选项来完全 disable Secure Boot.
–这也意味着Secure Boot 不再保护你免于 攻击者物理访问的攻击。

选择退出？
•x86上的大多数UEFI实现提供了在启动时disable“Secure Boot”的选项:
-UEFI定义了一种称为“Setup Mode”的东西，允许您设置PK和KEK
– 这基本上是它离开工厂之前的状态
– 对于最终用户来说，可以定制他们信任的密钥
– 但我们没有看到很多固件支持Setup Mode

总结：
•Secure Boot可有效防止在加载操作系统之前执行恶意软件

• 具有root权限的攻击者仍然可以安装一个trojned libc，bash等
• 显然，不是灵丹妙药
  •从开源角度看当然很痛苦.

Secure Boot对Linux的意义：

•Windows 8硬件认证要求支持Secure Boot

• 所有桌面硬件现在默认启用UEFI安全启动
  •在服务器市场，我们看到采用率较慢
• 在数据中心知道如何处理Secure Boot部署的操作系统并不多。
• 一些新的服务器硬件已经附带UEFI，但默认情况下Secure Boot已关闭disable.

开启 Secure boot 的机器不能启动linux kernel,除非kernel有一个"trusted key" 的 singed(可信密钥的签名).

kernel Community: 内核社区
如果你是一个内核开发者，你需要build and run 你自己的kernel:
Secure Boot 会阻止
可以 disable secure boot

GPLv3和Secure boot
•我们的首选引导加载程序（grub2）由GPLv3提供。 grub1和elilo是“GPLv2或更高版本”
•Preloads+ GPLv3：我们必须允许客户安装备用引导加载程序

• 关于GPLv3中“Tivo Clause”的法律问题
  •UEFI引导加载程序签名的Windows徽标计划修正案表示您无法签署GPL代码

安全启动Secure boot：SUSE®解决方案
MOK：Machine Owner Key
•将密钥管理返回给用户和sysadmin

• 无条件地，无论UEFI固件中缺少哪些选项
• 统一的，在所有系统上具有相同的接口和相同的密钥格式
• 信任证明由physical presence
• 由Matthew Garrett，Peter Jones（RH，shim）和
  Gary Lin（SUSE，MOK）实施.

•哪些需要Signed签名？
UEFI仅要求EFI二进制文件需要签名
- 仅防止引导加载程序bootloader被攻击
- 很多麻烦没什么价值
•值在可以信任的内核中是完整的

• 因此内核需要签名
• 模块也需要签名
• 并禁用某些功能：直接/dev/mem写入，iopl（）
  

MOK and Modules:
MOK 允许第三方模块很容易安装。
安装模块包时，需要请求添加一个MOKList.
然后，用户在重新启动时批准添加。

Secure Boot 的限制：
不能直接访问 IO port, 必需使用kernel 接口。
–GPU 需要KMS drivers.
不能直接访问内存。
– no /dev/mem, no /dev/rmem
不能加载没有签名的第三方模块。