企业官网建设流程全解析

安全启动深度指南：Universal Blue main 的 Secure Boot 与内核签名机制全解析

【免费下载链接】mainOCI base images of Fedora with batteries included项目地址: https://gitcode.com/gh_mirrors/main9/main

安全启动（Secure Boot）是 UEFI 固件提供的启动防护机制，而内核签名正是让 Linux 系统在开启 Secure Boot 后依然能正常启动的关键。本文将深入解读Universal Blue main（OCI base images of Fedora with batteries included）这套基础镜像，如何通过一整套内核签名与验证机制，让基于 Fedora 的定制系统在安全启动环境下既安全又顺畅地运行。无论你是刚接触不可变系统的初学者，还是想弄清签名原理的进阶用户，这篇指南都能帮你把 Secure Boot 与内核签名机制的来龙去脉一次讲透。

一、先认识 Universal Blue main：一切 uBlue 镜像的“地基” 🔑

Universal Blue main 是所有 uBlue 生态镜像（如 Aurora、Bazzite、Bluefin）共用的基础镜像。它基于 Fedora 的 ostree 桌面系统（Silverblue、Kinoite、Base），在其之上做“最小但重要”的调整，打包出开箱即用（batteries included）的镜像。

从 2025 年 9 月起，仓库只构建三种镜像：

这套系统的特别之处在于：它不是普通容器，而是可启动的操作系统镜像，最终通过 bootc 以容器方式交付，用户可以直接bootc switch切换到它。

二、为什么普通 Linux 用户要关心 Secure Boot？🛡️

很多新手第一次听到“Secure Boot”是在装双系统时被提示“请关闭 Secure Boot”。确实，未签名的系统在开启 Secure Boot 后可能无法启动。但安全启动的意义在于：

• 防止恶意引导程序在操作系统加载前劫持启动流程（即 bootkit 攻击）；
• 验证启动链的每一环：固件 → shim → 引导加载器 → 内核 → initramfs，环环相扣；
• 与现代 Windows 设备共存：预装 Windows 的电脑默认开启 Secure Boot，你的 Linux 必须能配合它工作。

也就是说，一个“开箱即用”的现代 Linux 镜像，必须内置完整的内核签名机制，否则用户要么关掉安全保护，要么面对无法启动的尴尬。

三、内核签名机制的核心：替换为“已签名内核” ✍️

Fedora 官方仓库的内核默认只由 Fedora 官方密钥签名，而 Universal Blue 的镜像需要加载第三方内核模块（akmods，如 NVIDIA 驱动）。要让这些模块在 Secure Boot 下可用，main 项目采取的策略是：

直接用 ublue-os 自己签名的内核替换官方内核。

在 build_files/install.sh 中可以看到完整流程：

1. 卸载官方内核：先擦除kernel、kernel-core、kernel-modules等软件包；
2. 安装签名内核：从 ublue-os 的 akmods 镜像中取回kernel-rpms，这些 RPM 已用 ublue-os 的密钥签名；
3. 锁定内核版本：用dnf5 versionlock固定内核版本，避免意外升级破坏签名与模块的匹配；
4. 绕过构建期钩子：临时替换kernel-install的钩子脚本，避免构建时重复触发 dracut，构建完成后再恢复。

这样，内核本身、以及配套的 akmods 内核模块，都由同一个可信密钥体系背书。

四、initramfs 的重新生成：签名链条的最后一环 🧩

替换内核之后，还需要配套的 initramfs（初始内存文件系统）。在 build_files/initramfs.sh 中，项目用 dracut 重新生成 initramfs：

• 使用--no-hostonly参数生成通用（非单机绑定）initramfs，保证镜像可移植；
• 显式加入ostree模块，适配 ostree 启动流程；
• 通过--reproducible保证可复现构建，相同输入产出相同镜像。

生成的 initramfs 与签名内核打包进同一镜像，确保 Secure Boot 验证链完整贯通。

五、如何验证内核签名真的有效？🔍

光签名还不够，还得有验证机制确保签名有效。Justfile 中专门提供了secureboot配方（见 Justfile），它的工作原理非常直观：

1. 从构建好的镜像中取出vmlinuz内核文件；
2. 下载 ublue-os 的公开证书（public_key.der、public_key_2.der）；
3. 调用sbverify工具，分别用两把公钥验证内核签名；
4. 任一验证失败，构建立即失败并提示 "Secureboot Signature Failed"。

这相当于在 CI 阶段就为每一版内核的签名质量把了关——签名没通过，镜像根本不会发布。此外，Justfile 中的verify-container配方还会用 cosign 验证基础镜像本身的签名，形成“双层校验”。

六、容器镜像层级的签名：cosign 与 cosign.pub 🔏

内核签名解决的是“启动时”的可信问题，而镜像签名解决的是“分发时”的可信问题。main 项目引入了cosign对最终镜像进行签名：

• 构建完成后，cosign-sign配方（Justfile）用私钥对镜像摘要签名，并在发布前立即用公钥验证；
• 仓库根目录的 cosign.pub 就是公开验证公钥，任何用户都能用它核对镜像是否被篡改；
• 采用 legacy simple-signing 格式，兼容 bootc、rpm-ostree 等工具的策略校验。

两层签名叠加的效果是：发布前有 cosign 保证镜像未被篡改，开机时有 Secure Boot 保证内核与模块可信，这正是“batteries included”在安全维度的体现。

七、给新手的实操建议与常见误区 ✅

误区一：装了 uBlue 镜像就必须关闭 Secure Boot。恰恰相反，这套内核签名机制正是为了让你保持 Secure Boot 开启。

误区二：签名与官方内核冲突。不需要担心——main 已经卸载官方内核并 versionlock，签名内核与模块版本严格绑定，不会有“半官方半定制”的混乱状态。

给新手的建议：

1. 保持 UEFI 设置中 Secure Boot 为开启状态（多数主板默认开启）；
2. 使用bootc status查看当前部署的镜像与内核版本；
3. 升级时遵循镜像发布节奏，避免手动替换内核破坏签名匹配；
4. 如需验证镜像签名，可用 cosign.pub 配合 cosign 工具自行校验。

八、总结：一套完整的“安全启动 + 签名”闭环 🎯

回顾整个机制，Universal Blue main 通过三步闭环解决了 Secure Boot 下的可启动性问题：

1. 签名内核替换：构建时用 ublue-os 密钥签名的内核替换官方内核（install.sh）；
2. 签名验证兜底：CI 中用 sbverify 双重验证内核签名（Justfile）；
3. 镜像分发签名：cosign 签名 + 公开公钥，保证下载的镜像可信。

对于所有基于它的下游镜像（Aurora、Bazzite、Bluefin）来说，这套地基决定了最终用户能否在保持安全启动开启的状态下，直接获得 NVIDIA 驱动等第三方模块支持。理解了这个机制，你就读懂了 uBlue 生态在安全与易用之间做出的精巧平衡。

【免费下载链接】mainOCI base images of Fedora with batteries included项目地址: https://gitcode.com/gh_mirrors/main9/main