云固件混合模式下，云固件引导程序没有获得微软数字签名，因此无法开启“安全模式”，那有没有办法开启安全启动而且还能使用云固件呢？
安全启动是各个行业巨头为了保障计算机从硬件到软件各个层级都受控于安全监管而设计的。但是，实际使用过程中，很多层面是无法满足安全要求的。比如，云固件引导程序就没有获得微软的数字签名。
为什么没有获取数字签名，说到底，还是钱的问题。每次发布的版本都需要缴纳99美金才能获取数字签名，成本不低。
云固件的外置模式、移动模式和独占模式（标准模式），目前使用了第三方获得数字签名的引导程序绕过了安全启动。这三种模式，ESP引导分区都是云固件主程序独占，因此可以使用第三方的方式。但是，云固件混合模式通常和Windows共享引导分区，其中/EFI/BOOT/bootx64.efi存在冲突的情况，导致无法启用安全启动。
那有没有办法来启用“安全启动”呢？
咱们先来分析一下混合模式下ESP引导分区内的文件。
本例子采用常见的Windows混合模式，Linux的混合模式比较少，而且和Linux混合通常就不需要开启安全启动。
ESP分区下，EFI文件夹下包含了UEFI的引导程序。
先说Microsoft文件夹。
从名称上就知道这是微软的引导程序，也就是Windows引导程序。这个文件夹下就只有Boot文件夹。在Boot下，文件就很多，通常包含bootmgfw.efi、bootmgr.efi、BCD等。
其中bootmgfw.efij就是Windows的引导程序，BCD就是引导配置文件。
再说MW文件夹。
这个文件夹就是云固件的引导程序，通常包含MW.efi和BootUI.efi这两个引导程序。
最后来说/EFI/Boot。这个文件夹下通常就只有bootx64.efi这个文件。
这个文件就是UEFi规范定义的x64架构下默认引导程序文件。如果是x86架构，那么规范定义的文件名就是bootia32.efi，由于FAT16/32分区忽略文件名大小写，所以文件名大写也可以的。
规范只定义了文件名和文件路径，文件内容是不定义的。因此，这个文件在Windows引导时，其实就是bootmgfw.efi的复制。云固件主程序用的第三方引导程序就是shim.efi。
由于UEFI规范定义了默认的引导程序文件，因此只要默认文件存在，那么就不需要手动添加引导项。
混合模式下，由于Windows已经占用了/EFI/Boot/bootx64.efi，因此云固件的引导项是单独添加的。
通过上面的分析，我们知道Windows混合模式下/EFI/Boot/bootx64.efi就是Windows的bootmgfw.efi。
同时，很多主板都会默认添加/EFI/Microsoft/Boot/bootmgfw.efi作为Windows Boot Manager的启动项。
由此可见，/EFI/Boot/bootx64.efi其实可以不使用。
这就是混合模式下启用“安全启动”的突破口。
把这个文件夹下全部内容替换为云固件主程序提供的/EFI/Boot文件夹内容。由于这个文件夹下引导程序已经完成了数字签名，因此无须关闭“安全启动”。
说一下修改后的引导过程。
混合模式引导时需要切换引导项，Windows引导使用bootmgfw.efi对应的引导项；云固件使用默认引导项，通常会出现UEFI OS这样的名称。
这样就可以实现混合模式下开启安全启动。
但是，缺点也存在。我们知道Windows向来是霸主，不管用户死活，强制默认启动项就是Windows。上述设置后，Windows更新后，通常/EFI/Boot文件夹就会被覆盖，为什么，答案是没有为什么，三哥就想这么干。绝大多数情况下，用户不明所以就会认为云固件坏掉了，事实上是大佬抢了小弟的饭碗。
大家现在明白处理了吧，包括更新出现问题后如何恢复了吧。
最后说一下，云固件主程序下/EFI/Boot文件夹内容。这里面文件很多，核心通过UEFI规范的链式引导，bootx64.efi引导最终的grubx64_real.efi。这个文件其实就是MW.efi，大家理解了吧。