Submission has been tested accordindly: We added our own DB cert (on a NUC 10i7FNK for x64 as well as on a Raspberry Pi 4 for AARCH64) before submitting for signing and have validated that, when Secure Boot is enabled:
The UEFI:NTFS bootloader will not load an NTFS driver that isn't Secure Boot signed. This relies on the fact that if Secure Boot is enabled and per UEFI specs (Version 2.9, Section 7.4), LoadImage() will return EFI_SECURITY_VIOLATION for binaries that do not pass Secure Boot validation. This validates that it is not possible for a malicious actor to load an arbitrary driver, instead of the one we submit for signing.
The target bootloader we attempt to chain load from the NTFS partition will not load if it isn't Secure Boot signed (for the same reasons as above, since we also use LoadImage()). This validates that it is not possible to use this solution to bypass Secure Boot altogether as the only binaries that it can ever load, in a Secure Boot enabled environment, are ones that already have been Secure Boot signed.
3. Product is not specific to a particular OEM or organization but, instead, is designed for general public use.
4. No parts of the code being submitted for UEFI signing is subject to GPLv3. The UEFI NTFS driver is GPLv2, since it derives from the GPLv2 ntfs-3g project, and the UEFI:NTFS bootloader is also GPLv2. We made explicitly sure that all of the code we use could be licensed under GPLv2.
Note that you may see that some of the code was derived from the pre-GPLv3 relicensing of GRUB 1.x (and is therefore a GPLv2 derivative) and that we may also use GRUB derived drivers for QEMU testing, but none of the parts we are submitting for UEFI signing are even remotely subject to GPLv3 licensing.
5/6. We are not aware of any malware vectors related to our code.
Considering the relative simplicity of the bootloader, and therefore the unlikeliness of finding an explotable flaw in it, the most likely point of attack for this solution would be with the NTFS driver. However, on that account, we have to stress out that the ntfs-3g project, which the driver is derived from, is very proactive when it comes to vulnerability identified in its code, as evidenced by the recent Security Advisory (issued for vulnerabilities that were detected by researchers but had not been found exploited in the wild). Obviously the driver binaries we are submitting are based on the latest ntfs-3g code, whcih includes fixes for these vulnerabilities, and we must stress out that we are committed to immediately alert Microsoft, should exploitable vulnerabilities be identified with the drivers.
Also, as the build process should make clean, we are running extensive static analysis against our code (Coverity, CodeQL and we also make use of VS2019 Code Analysis internally) to ensure that the binaries we produce are as safe as we can possibily make them. At the moment, we are not aware of any attack vectors, including potential ones, that could be exploited with our code.
7. Product has been tested in a Secure Boot enabled environment per the above.
8/9. We validated that the driver binaries we submit are using EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER and not EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER. The bootloader itself is using EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION. Also, none of the binaries we submit are EBC.
10. Our submission is not a Disk/File/Volume encryption.
11. Our submission is comprised of many different EFI modules: A boot application and a DXE driver for each architecture supported. Because the goal is for the final bootloader we chain load to have UEFI file system access to an NTFS volume, on systems where an NTFS driver is not available, it is not possible to consolidate these 2 modules into a single bootloader, as, while we would be able to execute the target bootloader, that bootloader would then be unable to access any of the support files it might need. As such, our submission, which consists of 2 modules for each platform, is the smallest breakdown we can accomplish.
12. Our submission is not technically a SHIM. In a Secure Boot enabled environment, it does hand of to another bootloader, but only if that bootloader is Secure Boot signed. So there is no need for extra code signing keys safety or certificate revocation, as the only signature validation mechanism being used is the native Secure Boot one from the system.
13. Our submission does not contains iPXE functionality.