New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uefi:ntfs and shim #15
Comments
No. Shim is just an extension of Secure Boot (controlled by Red Hat instead of Microsoft), and, because UEFI:NTFS is GPLv3, it is not compatible with either Secure Boot or any extension of it. |
Is shim not just a bootloader with a signed key? |
It's a bootloader. But, since it is signed by Microsoft for Secure Boot, it will not boot anything that is not signed (else it would completely defeat Secure Boot), and Red Hat and Canonical (who have control over validating what the shim boots next) are only interested in signing Linux kernels. Besides, if I were to use a shim for Secure Boot compatibility, I would rather use my own shim, since I don't care about booting EFI executables that aren't Secure Boot compliant (as opposed to the Linux shim), and it should be very easy to write one that meets all of Microsoft's Secure Boot requirements. But if I were to do that, I might as well turn UEFI:NTFS itself into a shim (since it pretty much already is and, even if the license is currently GPLv3, I made sure I gave myself the capability to relicense the boot code under GPLv2 if needed, which would then allow it to be signed for Secure Boot) instead of using somebody else's, as we really don't care about the "validating and/or revoking non Secure Boot bootloaders that are signed with some other key" part, which is the main concern of the Linux shim. |
That is not true. Grub2 is also GPLv3 but it's compatible with Secure Boot and shim. If you would be able to debug the reason why it fails to load driver with shim, you can use signed shim from Fedora with Fedora's built-in certificate. It won't launch automatically and would require enrolling certificate using MokManager interface, but it's free. |
You'll need to compile shim with OVERRIDE_SECURITY_POLICY define, or to write code to load driver efi file in memory and jumping to its entry point, without using LoadImage/StartImage. The former is easier, but I'm not sure why isn't it enabled by default, maybe there are drawbacks. |
GRUB 2 being compatible with Secure Boot is in direct contradiction with point 4 of the Microsoft Secure Boot guidelines (that explicitly mentions that GRUB 2 can't be Secure Boot signed):
So, while GRUB 2 is indeed compatible with shim, unless "compatible" means something other for you than "can be signed to work with" or Microsoft have changed their rule (in which case, can you point to the updated guidelines?), it is certainly not compatible with Secure Boot.
I did consider that. But that would mean add a lot of unwanted baggage, as I'd need to include a shim for x86_64, x86_32, ARM and ARM64, and, because UEFI:NTFS is designed to be used with Rufus, I am very size conscious. Rufus is currently a 1MB executable (and that payload size does include UEFI:NTFS for all the archs I mentioned above). So I really don't want to have to double that size, or worse, just to work around an issue that would not exist in the first place if Microsoft weren't abusing their position.
Thanks, that is helpful information. But I'm not sure it is that applicable.
I would venture to guess that All in all, I'm seeing a lot of extra work (adding custom signature validation, since I can't rely on Secure Boot ones) and other hurdles, that will require a lot of time, which I'd rather use on something else. I'm pretty much seeing the amount of work required to write a shim that works with the current UEFI:NTFS about the same as the amount of work required to port the GPLv2 NTFS-3g driver to UEFI, and (with a GPLv2 relicensed bootloader) get that signed for Secure Boot. Even if I currently don't have the time for any of those, between these 2 options, I must say that I do have a strong preference for the one that doesn't require a shim. |
There's the following a bit below:
This means that grub2 by itself can't be signed but shim can, and it should be used for grub 2 with secure boot patches (these patches prevent loading other modules and restrict other things).
No, actually it overrides security policy with it's own policy, not just remove it. I've booted UEFI:NTFS with PreLoader (which overrides security policy, the code in shim is the code from preloader) just fine. No UEFI:NTFS modification needed with OVERRIDE_SECURITY_POLICY, and this option does not allow to boot any arbitrary efi files, only the ones which are allowed by shim/preloader.
shim provides validation mechanism, it's easy to use. Also see comments, for example:
|
Yes, I'm well aware of it. That paragraph is hard to miss when you are pointing to the guidelines for Secure Boot signing on regular basis...
Yes. The problem I have is how you seemed to express the idea that GRUB2, on its own, was compatible with Secure Boot, which is what I wanted to make clear, to avoid people coming to this thread and thinking that what I've been telling them about UEFI:NTFS not being able to be signed for Secure Boot (because it contains GRUB2 GPLv3 code) was incorrect. So, just to clarify once more, GRUB2 (or anything GPLv3 for that matter) can not be signed for Secure Boot, so it's not compatible with Secure Boot per se. Thus, if you want to somehow use it in a Secure Boot process, then you must jump through the hoop that is the shim.
Okay. I hadn't looked (and still haven't - will try to find some time later on) at how exactly Of course, if there is existing code, that has been validated, and that can be reused so that you don't have to rewrite this from scratch, and if the resulting shim binaries are small enough, then it is something worth looking at.
That's indeed very nice. If you did that, then I'm very interested in any code you have to share But what I'm even more interested in is how large the resulting shim was, since, again, my main concern (besides time required to craft a working shim), is how much larger adding the x86_32, x86_64, ARM and ARM64 shim binaries would make Rufus. From what I have seen from "The Red Hat shim" source, and what I remember from distros such as Fedora, it seemed to be rather quite large, which I suspect is partly due to coming with a bit of additional stuff (e.g. httpboot) that I'm not sure would be really required for my usage in Rufus (straight USB boot). Then again, if the size addon is minimal, I don't have much of an issue with keeping this extra stuff... as long as the resulting binaries don't require me to multiply the size of Rufus by a factor 2 or 3.
Okay, at the risk of sounding pedantic once again, I think we need to clarify one last thing. There's "a shim" (which is something anybody can write, from scratch, and then ask Microsoft to sign, in order to provide their own shim mechanism) and then there's what you write as "shim", which appears to be the version of "a shim" that has been developed by Red Hat and other folks (i.e this thing) and which would probably be better qualified as "The Red Hat shim" to avoid confusion. In the above, since you appear to be talking about existing code, I think it's worth pointing out that you mean "The Red Hat shim" rather than "a shim". At any rate, I think your comments have provided me enough ammunition to want to look at the Red Hat Shim again, to see if, as you assert, using it for UEFI:NTFS might not be as painful as I anticipate it to be. And once again, any data you want to provide on the work you have already carried out on testing that will help! |
I did not, take a look at this archive. It contains Linux Foundation PreLoader and UEFI:NTFS x86_64. I had to copy NTFS driver twice since, for some reason, PreLoader hangs when entering Rufus folder (at least in QEMU), so NTFS driver is also in /EFI/BOOT. Use the following command to run this image in QEMU:
Red Hat Shim size is large. For example, Shim v15 x86_64 in Fedora is 1.2 MiB, and MokManager (HashTool alternative) is also 1.1 MiB. This is mostly because of the build process which does not involve unused functions stripping, that's why it contains unstripped OpenSSL with all the functions and is very big.
May I wonder why? Does it matter that much if the partition is 1 MiB or 4 MiB? |
Thanks for your update, as well as the attachments. Let me see what I can make of them.
Yeah, that's in line with what I had seen before and what I was expecting. Even if space can probably be gained with LZMA compression (which I use to compress Rufus assets), this is very very large as far as I am concerned.
Rufus is 1 MB. And again that includes all the UEFI:NTFS bootloaders and drivers for all archs. Even with compression, I expect that adding shims will at least double Rufus size. Now, a lot of people might say "What does it matter if Rufus is 1 MB or 3 MB?", but, as far as I am concerned (and as opposed to the approach Etcher has taken - while I do like Etcher and think its developers have done a great job with it, I don't see having to download ~40 MB for what could be simplistcly qualified as a "glorified dd" as that great) I don't think that an application that mostly exists to create bootable USB drivers should take that much space. Especially when they are in the process of setting up something from scratch, some people may not have that great a bandwidth connection, and, if I can, I owe it to them to make the application as small as I possibly can. For instance, that's part of the reason why I am limiting the number of localizations that are included in Rufus, and why I tend to carefully consider features that require large assets in terms of "how many people will this benefit vs how much bigger will the application get". Also, up until very recently, and possibly yet again in the future, I was paying for bandwidth.... and with circa 3 millions of downloads of Rufus a month, even doubling the size can be troublesome (but I will not hold this as a major problem, since I'm using github releases at the moment). Finally, considering that ALL x86 platforms I know of do have the ability to temporarily disable Secure Boot, and that turning it off is only required for the initial installation, and that I do assert that if one created their bootable media after having validated the SHA of their image (which Rufus, which is also digitally signed, can compute for them), then temporaily disabling Secure Boot for the initial install is not as big a deal as the people who zoom on the "Secure" terminology of "Secure Boot" as meaning it should not be disabled ever think it is. So, between at least doubling the size of Rufus or telling people that they can temporarily disable Secure Boot (as long as they're not trying to install on the few ARM machines that Microsoft tried to lock into Secure Boot always a few years ago), I do see it as preferable to go with the latter for now. But of course, that doesn't mean I'm not gonna check the possibility of using the Red Hat shim and see what comes out. |
Managed to chain shim and preloader to circumvent uefi security policy, so you can load unsigned drivers. |
Thanks a lot for notifying on this as well as the updated link. Much appreciated! |
Hello, does shim work with uefi:ntfs?
The text was updated successfully, but these errors were encountered: