GRUB多EFI可执行文件的启动行为是否符合UEFI规范？

你注意到的这个现象其实是Ubuntu为了适配Secure Boot、提供完整启动及辅助功能的合理设计，并没有违反UEFI 2.7规范的核心要求——咱们先拆解每个文件的作用，再结合规范来解释：

首先明确UEFI规范的核心约束：

UEFI规范2.7版本的「13.3.1.3 目录结构」章节明确规定：每个厂商子目录中，针对每种支持的处理器架构必须且只能存在一个可执行EFI镜像，以确保EFI启动管理器从厂商子目录中仅能加载一个镜像。

这里的关键是**“可执行EFI镜像”指的是供EFI启动管理器直接调用的启动入口镜像**，而非目录下所有的efi文件。Ubuntu目录下的这些文件各司其职，只有一个是真正的启动入口：

• SHIMX64.EFI：这是Ubuntu向UEFI启动管理器注册的唯一启动入口，是微软签名的shim加载器，作用是绕过Secure Boot的签名限制，加载后续的GRUB程序。它完全符合规范中“每个架构一个可执行启动镜像”的要求。
• GRUBX64.EFI：由shim加载的实际GRUB引导程序，负责解析启动菜单、加载Ubuntu内核和初始化系统，它是shim的依赖程序，不是EFI启动管理器直接加载的目标。
• MOKMANAG.EFI：Secure Boot环境下的Machine Owner Key（MOK）管理工具，用来添加、删除或验证自定义的签名密钥，属于启动辅助工具，并非启动入口。
• mmx64.efi：GRUB内置的内存测试工具，用于在系统启动前检测内存完整性，同样是辅助功能程序。
• fwupx64.efi：固件更新工具fwupd的EFI组件，用于在EFI环境下更新硬件固件，属于系统维护类的辅助程序。

简单来说，Ubuntu的做法是把唯一的启动入口SHIMX64.EFI作为规范要求的“可执行EFI镜像”，其他文件都是这个主流程的辅助工具或依赖组件，不会被EFI启动管理器当作独立启动项加载，完全符合UEFI规范的约束。

内容的提问来源于stack exchange，提问作者Intron BBS