Closed BrandonNolet closed 2 years ago
I think you are might be misunderstanding the purpose of UEFI:NTFS in the context of Secure Boot.
As opposed to a SHIM, UEFI:NTFS will only ever chain-load bootloaders that are themselves Secure Boot signed. So, unlike SHIM, UEFI:NTFS does not have its own separate trust validation process, with a separate signing key, that we could use to sign third party bootloaders and vet them instead of Microsoft. Instead UEFI:NTFS relies fully on the trust/validation mechanism provided by Secure Boot. Which means that, in what I assume is be the Secure Boot context you have in mind, UEFI:NTFS can only ever chain-load a bootloader that has been signed by Microsoft.
Which means that, considering that Microsoft appears to have some additional requirements in order to sign iPXE binaries(Paragraph 13. of this), no, using UEFI:NTFS will not allow you to bypass the additional iPXE restrictions that Microsoft requires for Secure Boot signing, because, with Secure Boot enabled, UEFI:NTFS can only chain load a bootloader that has itself been Secure Boot signed by Microsoft.
In other words, there's absolutely no point in looking at using UEFI:NTFS for iPXE payloads, because if such a payload does work with UEFI:NTFS then it means that it doesn't need anything (be it UEFI:NTFS or SHIM) to work with plain Secure Boot.
Thanks for the clarification and explanation of the Secure Boot process for UEFI:NTFS. This is all such a complex realm of topics that one has to tie together, which is stimulating for discussion but frustrating when trying to fully process the concepts. You have been extremely helpful in getting a fuller understanding of the stack here (and on reddit, I'm also /u/LinuxLiaison there, in case you remember the conversation)
I've opened a discussion here if you're willing to chime in. TL;DR, I want to use shim->Grub as a replacement for iPXE.
Is better to use shim or UEFI:NTFS if we would like to use iPXE with secure boot enabled?