Ventoy should only allow the execution of Secure Boot signed executables when Secure Boot is enabled #135
Comments
|
I believe GRUB (at least v2.04 and previous versions if patched with Fedora patches) already work exactly as you've described. @ventoy used Super UEFIinSecureBoot Disk files to disable UEFI file policy, that's the easiest way, but not a 'proper' one. In a real use case, when you have several Linux distros (not all of which have Secure Boot support), several unsigned UEFI utilities, it's just easier to temporary disable Secure Boot with SUISBD method. I'll think about it and try to add it to ventoy. |
|
If someone has physical access to a system and that system is enabled to boot from a USB drive, then all they need to do is boot to an OS such as Ubuntu or WindowsPE or WindowsToGo from that USB drive (these OS's are all signed and so will Secure boot). From the booted OS, they are then free to do whatever they want to the system. |
|
If someone has physical access to a system then Secure Boot is useless period. In that case there's no difference in booting from USB or plugging in a SATA or NVMe drive with the same content as you'd put on USB (and we can debate about intrusion detection if you want). The point of this issue is that people are under the impression that because Ventoy supports Secure Boot, they will get the same level of "security" booting Secure Boot compliant media through Ventoy as if they had booted that same media directly, which is indeed a fair expectation to have, since the whole point of boot media creation software is to have the converted media behave as close as possible as the original would. Thus, on a system where Secure Boot is enabled, users should rightfully expect to be alerted if the EFI bootloader of an ISO booted through Ventoy is not Secure Boot signed or if its signature doesn't validate. However what currently happens is that people who do have Secure Boot enabled will currently not be alerted to these at all. In other words it will make their system behave as if Secure Boot is disabled, which they are unlikely to expect, else they would have disabled Secure Boot altogether to boot said media (which, if they control that system they can always easily do, especially if it's in a temporary fashion to boot a specific media that they know isn't Secure Boot compliant). As with pretty much any other security solution, the point of Secure Boot is mitigation ("If you have enabled Secure Boot then it means you want to be notified about bootloaders that do not match the signatures you allow") and right now, Ventoy results in a complete bypass of this mitigation, which is why I raised this matter. Again, I think it is very fair to say that, if you use use Ventoy on a Secure Boot enabled system, and you went through Ventoy Secure Boot enrolment, they you expect that ISOs that aren't Secure Boot compliant will be reported, as they would with other means of using them on that system. But, currently, that is not the case at all, which means that, independently of the merits of Secure Boot for this or that type of media (which is a completely different debate altogether), there is a breach of the security contract that the user expects to see enforced and therefore something that needs to be addressed. |
|
@pbatard, if that's what what your concern, that could be easily fixed by deleting |
|
But it shouldn't be to the user to do that. It should be the default of Ventoy, which is the point of this issue. If someone uses Ventoy with Secure Boot, then Ventoy should not green light UEFI bootloaders that don't comply with Secure Boot. If I am using Ventoy and I went the trouble of enrolling it for Secure Boot, I don't expect it to suddenly flag any unsigned or UEFI bootloader or bootloader with a broken signature, as bootable in a Secure Boot enabled environment. Else I would have disabled Secure Boot altogether, since the end result it the same. |
|
That's actually very hard to do, and IMO is pointless in Ventoy case. Linux distributives use Shim loader, each distro with it's own embedded certificate unique for each distro. Shim itself is signed with Microsoft key. Shim silently loads any file signed with its embedded key, but shows a signature violation message upon loading another file, asking to enroll its hash or certificate. So, Fedora has shim that loads only Fedoras files. Ubuntu has shim which load only Ubuntu, etc. As Ventoy itself is not signed with Microsoft key, it uses Shim from Fedora (or, more precisely, from Super UEFIinSecureBoot Disk). Say, we disabled validation policy circumvention and Secure Boot works as it should. The user has Ubuntu, Fedora and OpenSUSE ISOs which they want to load. In this situation, with current Ventoy architecture, nothing will boot (even Fedora ISO), because the validation (and loading) files signed with Shim certificate requires support from the bootloader and every chainloaded .efi file (it uses custom protocol, regular EFI functions can't be used. This seem to be disabled in Ventoy's custom GRUB). Of course, there are ways to enable proper validation. For example, Ventoy can be modified to somehow chainload full chain of Can't say for others, but I made Super UEFIinSecureBoot Disk with that exact purpose: to bypass Secure Boot validation policy.
I remember that @adrian15 tried to create a sets of fully trusted chainload chains to be used in Super GRUB2 Disk. @adrian15, could you tell us your progress on this? |
It's a pain in the ass to do yes, but I wouldn't qualify it as very hard. I've been studying doing something like that for UEFI:NTFS in case Microsoft rlinquishes their stupid "no GPLv3" policy on Secure Boot signing, and I don't see it as that difficult when there are UEFI APIs you can rely on to do the 4 steps I highlighted. And that is the right thing to do.
Then congratulations: You have completely removed any benefits of using Secure Boot for any person who enrolled Ventoy on their Secure Boot computer. Because if I know you ever used Ventoy in a Secure Boot enabled environment, I can now run any malicious payload I want at the UEFI level, on your computer.
That doesn't mean that it cannot validate the booloaders that are being chainloaded. It's the job of Ventoy's custom GRUB to ensure that what is being chainloaded is Secure Boot compliant because that's what users will expect from a trustworthy boot application in a Secure Boot environment. If it fails to do that, then you have created a major security problem, no matter how you look at it.
Yes, anybody can make a UEFI bootloader that chain loads unsigned bootloaders with the express purpose of defeating Secure Boot. But unless it exploits a Secure Boot vulnerability or limitation (or you get cozy with the folks controlling shim keys), that bootloader should require to be enrolled to pass Secure Boot validation, in the same manner as Ventoy does it. And of course, people expect that if they run UEFIinSecureBoot or similar software, whose goal is explicitly stated as such, it will effectively remove Secure Boot. When enrolling Ventoy, they do not. Or to put it more succinctly, when you give a copy of your house keys to someone, you don't expect them to leave the door open for everybody else to walk in... I really fail to fathom how people here are disputing that if someone agrees to enroll Ventoy in a Secure Boot environment, it only means that they agree to trust the Ventoy application, and not that they grant it the right to just run whatever bootloader anybody will now be able to throw at their computer through Ventoy (which may very well be a malicious bootloader ran by someone who is not the owner of that computer but who knows or hopes that the user enrolled Ventoy). In other words, that there might exist other software that might be used to force the door open is irrelevant. Else you might just as well make the argument that locking your house or car is pointless, and that nobody should ever bother about doing so, because a professional will have little trouble getting in anyway... Therefore, unless Ventoy makes it very explicit that "By enrolling Ventoy for Secure Boot, you understand that you are also granting anyone with the capability of running non Secure Boot enabled boot loaders on your computer, including potential malicious ones that would otherwise have been detected by Secure Boot", I will maintain that there is a rather important security issue that needs to be addressed. Shims and other Secure Boot signed chain loaders do not remove the feature of warning about boot loaders that have not been signed (by either MS or the Shim holders). But Ventoy currently does. |
|
Don't get me wrong, I understand your concerns and support your position. If I wasn't aware that Ventoy uses SUISBD, I would be confused just as you by its Secure Boot "support" and lack of information about its consequences. I should also note that the key used in Ventoy is the same used in Super UEFIinSecureBoot Disk, my key. |
|
Agreed. Secure Boot is tricky to deal with and can (rightfully) be seen as a major inconvenience instead of yet another usually desireable line of defence against malware (but by all means not a panacea). And I also totally get where LogPanda/Ventoy is coming from when they decided to use your solution, because, from releasing boot media creation software, I can vouch to getting a lot of flak from users if your software happens to ask them to disable Secure Boot, even it's temporarily and after having validated that the content from the UEFI media came from trusted sources... So any method that allows users to boot their media without having to explicitly disable Secure Boot can be seen as a nice thing to have... even if it comes at the price of reducing the overall security of one's computer. Personally, I don't have much of an issue with Ventoy using the current approach as a stopgap solution, as long as it is agreed that this is only a stopgap, since it comes with a huge drawback, and that a better solution (validation of that the UEFI bootloaders chain loaded from GRUB pass Secure Boot validation when Secure Boot has been enabled by the user) needs to be implemented in the long run. Oh and obviously, once that is done, Ventoy will need to make sure that it's not possible to run an older versions of it, in a Secure Boot environment where a newer version has been enrolled, as it would still defeat the whole thing. So that means that Ventoy will need to use a different key indeed. |
Not exactly. So as @pbatard said, the secure boot solution is a stopgap and that's why Ventoy is still at 1.0.XX. Just some of my thoughts: When install Ventoy, maybe an option for user to choose. Option2: Use Ventoy's grub which is signed with MS key. Then user will be clearly told that, in this case only distros whose bootloader signed with valid key can be loaded. Just some preliminary ideas. A lot of work to do. For example, how to get Ventoy's grub signed with MS key. |
Yes, I already understood my mistake. I've made some tests this evening, it should be possible to make more-or-less proper Secure Boot support in Ventoy, but that would require modification of grub code to use shim protocol, and digital signatures for all Ventoy efi files, modules, etc. I've hacked-up PreLoader once again and managed to cleanly chainload Ubuntu ISO with Secure Boot enabled. Will polish and publish the code later. |
|
Yes. for grub modules, maybe I can pack all the modules into one grub.efi and for other efi files(e.g. ventoy_x64.efi/ventoy_util_x64.efi ...) , they do need digital signatures. |
|
Is it valid for Ventoy to be able to run user scripts, inject user files into Linux/Windows ram disks, change .cfg files in 'secure' ISOs, etc. when the user Secure Boots via MokManager - even when booting signed efi files of Ubuntu or Windows? |
|
@steve6375 There are many kinds of WinPE. These WinPE have different user scripts inside the ISO files. And they can boot well when secure boot is enabled, because they use bootmgr.efi directly from Windows iso. So all Ventoy's behavior doesn't change the secure boot policy. |
|
Exactly. The point is that if a user whitelists Ventoy using MokManager, they are responsible for anything that they then subsequently run using Ventoy. They can choose to run a signed Ubuntu EFI file and Ventoy can change it's default function using scripts and file injection. Ventoy can boot any wim file and inject any user code into it. The user could choose to run a Microsoft Windows Install ISO downloaded from the MS servers and Ventoy could inject a malicious file into it as it boots. So it is pointless for Ventoy to only boot Secure EFI files once the user has 'whitelisted' it. |
Some commands in Ventoy grub can modify the contents of the ISO and must be disabled for users to use on their own under secure boot. |
We talk about secure boot, not secure system. When user whitelist Venoy that means they trust Ventoy (e.g. they reviewed all the source code). |
I think it's ok as long as they don't break the secure boot policy. |
You can't. Point 4 from Microsoft's official Secure Boot signing requirements states:
They explicitly mention GRUB. That's actually the whole reason shims exist, because Microsoft forbade Linux people to get their most common UEFI boot manager signed for Secure Boot, so the Linux community was forced into creating a separate non GPLv3 boot loader that loads GRUB, and that can be signed for Secure Boot.
That's not at all how I see it (and from what I read above also not @ventoy sees it). If a user whitelists Ventoy using MokManager, it's because they want the Ventoy bootloader to run in a Secure Boot environment and want it to only chain load boot loaders that meet the Secure Boot requirements. The idea that Ventoy users "should know what they are getting into" or that "it's pointless to check UEFI bootloaders for Secure Boot" once Ventoy has been enrolled is disingenuous at best. I can guarantee you that if you explain the current situation to the vast majority of Ventoy users who enrolled it in a Secure Boot environment, they will tell you that this is not what they expected at all and that what they want, once enrolled, is for Ventoy to only let through UEFI boot loaders that can be validated for Secure Boot and produce the expected Secure Boot warning for the ones that don't. That's because, if they did want to boot non Secure Boot enabled ones, they would disable Secure Boot themselves. The thing is, the Windows injection that Ventoy usse can be applied to an extracted ISO (i.e. a media that was created without using Ventoy) running in a Secure Boot environment, so if your point is that because Ventoy uses a means to inject content that Microsoft has chosen not to secure, it makes the whole point of checking Secure Boot useless, then that reasoning logically also applies to official unmodified retail Windows ISOs, because you might as well tell everyone who created a Windows installation media (using the MCT for instance): "There's really no point in having Secure Boot enabled on your system, since someone can just create a Windows media with a malicious Again, if someone has Secure Boot enabled, and did not whitelist a third party UEFI bootloader themselves, then they will expect the system to warn them in that third party bootloader fails Secure Boot validation, regardless of whether they did enrol a bootloader that chain loaded that third party bootloader. It's that simple. Really. |
Yes. So maybe Ventoy also need a shim as fedora/ubuntu does. |
|
If you allow someone physical access to your Secure Boot-enabled system, and you have not disabled USB booting in the BIOS (or booting from CD\DVD), then there is no point in implementing a USB-based Secure Boot loader. If Ventoy was intended to be used from an internal hard disk, I would agree with you, but Ventoy is a USB-based multiboot solution and therefore the user must have physical access to the system, so it is the users responsibility to be careful about what he inserts into that USB port. |
Yeah... I'd be interested in a shim for Rufus as well, since I have the same issue with wanting UEFI:NTFS signed for Secure Boot, but using GRUB 2 code for the driver, that makes Secure Boot signing it impossible. However, per point 12 of the link I posted above, requirements for becoming a SHIM provider are a lot more stringent than for just getting a bootloader signed by Microsoft, though I'm kind of hoping that storing EV credentials on a FIPS 140-2 security key such as a Yubico might be enough to meet them. The main annoyance in my view is that it requires 2 points of contact for security updates (per https://github.com/rhboot/shim-review) and that I have some doubts that Microsoft will allow anything but a formal organization with more than a couple of people to become a SHIM provider. However, considering that in the case of Ventoy, you are basically going to chain load GRUB 2, and that most of the SHIMs have been designed to handle precisely that, it might be easier to get Ventoy accepted as a shim payload.
Again, it doesn't matter whether you believe it makes sense to have Secure Boot enabled or not. What matters is what users perceive and expect. And, unless you're going to stand behind every single Ventoy user to explain why you think it shouldn't matter that Ventoy will let any unsigned bootloader through, that's just not going to fly. Users enabled Secure Boot to be warned if a boot loader fails Secure Boot validation, regardless of where that bootloader is executed from. And we've already been over whether USB should be treated differently than internal SATA or NVMe (which, in your opinion it should, and which in mine, and I will assert the majority of people who enable Secure Boot, it shouldn't).
Well, that's pretty much exactly what I suggested in points 1-4 from the original post, with point 4 altered from "an error should be returned to the user and bootx64.efi should not be launched" to "an error should be returned to the user who can then decide if they still want to launch bootx64.efi". I have absolutely no problem with letting the user choose if they want to run a bootloader that failed Secure Boot validation, and I think this might be the better way to do it indeed. The main issue is that users should at least get some warning that a bootloader failed SB validation when SB is enabled, instead of just letting everything go through. |
Yes. The user should be notified when booting an unsigned efi file. |
|
Yeah, I think UEFI However, I would say that, if you are already running "arbritrary" code in UEFI mode to display a user message, while Secure Boot is enabled, then you should be able to craft your own I would say that it probably makes sense to first see what |
|
That's theoretically feasible but is clearly banned by the shim/MS. |
@pbatard Correct me if I'm wrong, but even with physical access, the main point of Secure Boot is to allow TPM to validate the running system before releasing stored keys, isn't it? So even when someone physically unplugs my SSD and installs a malicious bootloader/OS to it, it won't be able to decrypt the main OS partition. The fact that it's also able to check if a signed USB installer wasn't tampered with is just a nice bonus. |
No. The main point of Secure Boot is to prevent (or at least warn about) the execution of bootloaders that have not been vetted by Microsoft or one of the third parties that Microsoft signed a shim for (such as Red Hat). What you want is for users to be alerted if someone picked a Linux or Microsoft media, and the UEFI bootloader was altered from the original. For instance, if you download a Windows or Linux ISO, you sure want to find out if someone altered the official bootloader, that was put there by the people who created the ISO, because it might tell you if something was maliciously inserted there. Now, that one can currently break the trust chain somewhere down the line, by inserting a malicious program at the first level where the trust stops being validated, which, incidentally, as a method (since I am NOT calling Ventoy malicious here) is very similar to what Ventoy is doing for Windows boot, is irrelevant to the matter, because one can very much conceive an OS that is being secured all the way (and, once again, if Microsoft were to start doing just that, then that would most likely mark the end of being able to use Ventoy with Windows ISOs since it would no longer be able to inject an executable that isn't signed by Microsoft as part of the boot process) and that validates the signature of every single binary it runs along the way... which means that the trust chain needs to start somewhere and (as far as user providable binaries are concerned) that trust chain starts with Secure Boot. I suspect that, even as we are not there yet, this is something that we're eventually going to see (but most likely as a choice for the user to install the fully secured or partially secured version of the OS), culminating in OSes where every single binary that runs needs to be signed, and for the certificates those binaries are signed with to be in the chain of trust of OS. Thus, being able to check that an installer or boot loader wasn't tampered with is not a "nice bonus" but is something that must be enforced always in a Secure Boot enabled environment, regardless of the type of media you are booting from, because Secure Boot is very much designed to help users ensure that, when they install an OS, and provided that OS has a chain of trust that extends all the way, any alteration of any of the binary code that the OS executes, be it as part of the installation or when the OS is running, will be detected and reported to the user and prevent the altered binary code to run. And if you somehow let bootloaders that shouldn't be trusted through, such as unsigned ones, then it means your whole chain of trust is utterly broken, because there simply cannot even exist a special case for "USB" vs "something else". And, unfortunately, with Ventoy as it stands, this whole trust mechanism is indeed broken, because you can take an official Windows installation ISO, insert a super malicious UEFI bootloader (that performs a Windows installation while also installing malware) and, even if users have Secure Boot enabled (and added Ventoy in Mok manager), they will not be alerted at all that they are running a malicious bootloader, whereas this is the whole point of Secure Boot! Again, detecting malicious bootloaders, from any media, is not a bonus. It's what Secure Boot is designed to do on account of being a trust chain mechanism that, when enabled, MUST alert if trust is broken. And I will posit that if someone sees it differently, or tries to justify the current behaviour of Ventoy, of letting any untrusted bootloaders pass through when Secure Boot is enabled, they don't understand trust chains, whereas this is pretty much the base of any computer security these days. For instance, if you produce digitally signed software for Windows, to ensure that your users can validate that when they run an application, they can tell with certainty whether it comes from you or not, you really don't want someone to install software on the user computer that will suddenly make applications that weren't signed by you look as if they were signed by you. Yet, that is technically what Ventoy does if you enrol it for Secure Boot, as it makes it look like any bootloader, that wasn't signed by Microsoft, was signed by Microsoft. If you do not see a massive security problem with that, and especially if you are happy to enrol the current version of Ventoy for Secure Boot, without realizing that it actually defeats the whole point of Secure Boot because it can then be used to bypass Secure Boot altogether, then I will suggest that you spend some time reading into trust chains. |
|
@pbatard Sorry, I should have explained my position clearer - I fully agree that the Secure Boot bypass Ventoy uses is not secure, and I'm not using Ventoy exactly because of it. I was just objecting to your claim that Secure Boot is useless when someone has physical access to the device, which I don't think is true, as it is still (afaik) required for TPM-based encryption to work correctly. Nevertheless, thanks for the explanation, it cleared up some things for me around the threat model of Secure Boot. |
|
TPM encryption has historically been independent of Secure Boot. You were able to use TPM for disk encryption long before Secure Boot, and rightfully so, since the process of storing and using data encryption keys is completely different from the process of storing and using trust chain keys to validate binary executables (being able to decrypt something is very different from being able to trust something). You can have BIOS with TPM and disk encryption and, provided your hardware manufacturer implements anti tampering protection to ensure that the TPM is not sharing data it shouldn't share with parts of the system that should not be trusted, it should be no less secure than TPM-based encryption on a Secure Boot enabled system. So, Secure Boot is not required for TPM-based encryption to work correctly. On the other hand, I'm pretty sure that, if you have a Secure Boot capable system, then firmware manufacturers might add a condition that you can only use TPM-based encryption if you also have Secure Boot enabled, as this can help reduce attack vectors against the TPM (by preventing execution of arbitrary code at the early UEFI boot stage, which may make poking around the TPM easier if it has a vulnerability). So, yeah, it's the same as a safe manufacturer, on seeing that you have a room with extra security (e.g. access with key cards) making sure that your safe does get installed there, so that it should give you an extra chance to detect ill intentioned people trying to access its content. But, whereas this is good security practice, that is not a requirement. Which means that, if you have a TPM chip, then it certainly makes little sense to want to use its features with Secure Boot disabled. And it's possible that the UEFI specs went as far as specifying that specific aspects of the platform security, such as disk encryption through TPM, should only be available if Secure Boot is enabled. But, even as I don't actually support the idea that Secure Boot is useless if someone has physical access to the device (that was mostly Steve positing this as a means to justify that not being able to detect Secure Boot breaches on USB media isn't that big a deal), I do believe there currently still exist a bit too many ways to ensure that you can compromise a machine, if you have access to said machine. Heck, in the absolute, if you have the means (And please note here that I'm not saying that any regular Joe, who doesn't already have access to the whole gammut of NSA resources, can do it), you can replace the CPU with your own custom FPGA, and it's pretty much game over, as, apart from easy to defeat matters such as serial number check, your TPM will be designed to work with anything that remotely looks like a CPU, and if you communicate with it like a CPU would, it'll happily help you access whatever data you request... such as decrypted disk content. So, yeah, if you have access to to the hardware, then Secure Boot, TPM or whatever security measure you currently have on consumer-grade products, is pretty much useless because, as long as you can swap hardware components around, or even touch the hardware (to glitch the RAM for instance), then unless the TPM comes with an X-Ray machine that can scan and compare hardware components, you're going to have a very hard time plugging all the many holes through which a dedicated attacker can gain access to your data. Which brings us nicely to what this is all about: Mitigation. All of these security things are there to mitigate risks. They can't eliminate them totally, but they can provide an additional level of protection. Which is why you want to have as many of these enabled in parallel when they exist (such as TPM + Secure Boot, i.e. your point) and you also want them to actually do their designated job, including letting you know, if you have Secure Boot enabled, when some third party UEFI boot loader didn't pass Secure Boot validation, even if that boot loader will only ever be run from someone who has to have physical access to your computer in the first place. |
|
A couple of comments on this subject:
|
Except that what you are stating is complete bullshit. You are just regurgitating propaganda, that has been peddled by Microsoft, and that I have literally spent YEARS dismantling with Rufus and UEFI:NTFS. For one thing, if this is true, then this issue exists with the shim, since the shim allows a GPLv3 licensed GRUB to run and it is signed. So according to you (or rather according to Microsoft) anyone should be able to contact the Shim folks (Red Hat and co) and demand that they hand over their signing keys. Oh, and since Microsoft does happily sign the shim, it does imply that, transitively (because what they state about Secure Boot signed bootloaders does transitively apply to the shim that performs the exact same operation) they don't even believe their own argument that signing anything GPLv3 in a Secure Boot environment forces the people maintaining the trust chain to disclose their private keys since if, they did, they would never allow the shim to be Secure Boot signed, as, according to Microsoft, anyone can force them to disclose their signing key, thereby completely defeating Secure Boot. Second, all the GPLv3 says is that users should be able to run their own executable, build from a version that they derived from the source. Which they can 100% accomplish with current Secure Boot, as long as it is is not locked by the manufacturer (but, and I will elaborate on this below, manufacturer lock is not part of the Secure Boot specs), by installing their own signing keys (or by disabling Secure Boot altogether). The irony is that this is exactly what Ventoy, which is GPLv3 code, is doing. It asks you to enroll its key, and everything's peachy (apart from the whole, "now Secure Boot is no longer working as advertised" but in this legal context, it's a different matter). And, unless my understanding of the UEFI specs is wrong, Secure Boot was designed, from the get go, to let the end user to install their own keys if they wished (which, originally, meant replacing the machine/manufacturer key sitting at the top, rather than use something like the more convenient MokManager to add exceptions at a lower level, but which the Secure Boot specs always made perfectly achievable). So the GPLv3 requirements are and continue to be easily satisfied with Secure Boot as described by the UEFI specs, with no need to resort to scaremongering people into falsely believing that, if GPLv3 code was allowed to be signed for Secure Boot, then the secret key used to perform the signing would have to be handed over. Which leads us to the only reason why Microsoft started to peddle this complete bullshit: They wanted to use Secure Boot to do something that Secure Boot was never ever designed to do, which is grant full vetting control to the manufacturer of the computer, and take that same control away from the user of a machine. This also, or perhaps causally, helped Microsoft prevent the installation of competitor OSes, since Microsoft also knew that GPLv3 introduced a clause against this type of restrictive behaviour, due to the makers of the TiVo device having tried just this type of crap on a device that they had happily used GPL code to develop (i.e. in complete breach of the spirit of the GPL which is to always allow users to run a modified version of a GPL application, on the hardware they own, if they wish), and that, since the GRUB bootloader that is commonly used to boot Linux was now licensed under GPLv3, promoting the idea that the GPLv3 would "force" them to relinquish their Secure Boot signing key, thereby giving them an excuse NOT to sign the GRUB bootloader, would lead to the installation of a non Windows OS a lot more problematic, for a long enough time, to leave Windows with an unfair advantage over its competitors. Now, since what I am saying above can be construed as mere allegation, I will point out that, for anyone who bothers to look, there exists a lot of circumstantial that Microsoft has long wanted and has still not given up on the idea of making it way harder than it should for people to install non Windows OSes, especially on Microsoft hardware, first, when they introduced Windows RT, i.e. ARM Windows devices where they did exactly what I described above and restricted Secure Boot by removing the ability for the user to disable it or install their own certificates (which, unsurprisingly, led to a huge outcry from RT device users, forcing Microsoft not to pursue this kind of fully restricted hardware further) or, much more recently, with things like Surface devices, where Microsoft added an extra version of Secure Boot, that they state is more "secure" than regular Secure Boot, and that only allows bootloaders signed with credentials that only ever apply to Windows code, to run (thus preventing Linux from booting when this "special" version of Secure Boot is enabled, which it is, by default, on surface and other Microsoft devices). But at least, Microsoft seems to have remembered what happened last time they tried to take control away from their users and they have reluctantly granted an option for users to go in their UEFI settings and switch between Microsoft's Secure Boot, (what Microsoft calls) "Third party" Secure Boot (even as it is STILL Microsoft, and Microsoft only, that is signing these "third party" bootloaders) or Secure Boot disabled. If I had time to search for it, I would also point to the very ironical Microsoft KB article where they explained how their own Secure Boot signed stuff should be considered a lot more trustworthy than the stuff they sign for "third parties" (like Shim)... that they published only a few months before they were caught with their pants down with the BlackLotus fiasco (which forced them to revoke ALL of their "much more trustworthy" Secure Boot signed bootloaders, up to May of this year)... But, even if we disregard all of the above, let me explain what would obviously really happen if Microsoft were to allow GPLv3 UEFI bootloaders to be signed, and someone challenged them to hand over their Secure Boot signing key.
Thus, unless someone really wants to dispute any of the points above, I would appreciate if they stopped repeating Microsoft's blatant self-interested FUD about how the GPLv3 would require them to relinquish their signing keys.
Not if the only application that can run unsigned is acting as a gatekeeper. And that is what my proposal is about. The first non "BIOS element" that would run would be unsigned, but it could only ever be the chain loader that does the gatekeeping, and, unless there is a vulnerability in Ventoy (since, in a Secure Boot enabled environment someone cannot simply replace the initial Ventoy bootloader, that runs GRUB that in turn runs the unsigned bootloader, with their own version that would allow them to run a different unsigned bootloader from the special Ventoy chain-loader) this should not happen. Please understand that, somewhere between when the Ventoy EFI executable runs (which is signed and whose cert has been enrolled precisely because the trust chain still works as expected then) and when the EFI bootloader from the ISO runs, the trust chain has indeed been broken, because the EFI bootloader from the ISO can be unsigned and it will happily be let to run. However, at this stage, the breakage is still only internal to Ventoy/GRUB and not something that can be exploited externally. Therefore, you can still "fix" the breakage by always replacing that ISO bootloader with a chain-loader, that will act as a gatekeeper and continue to enforce the trust chain before running the original ISO bootloader. |
|
Keep calm and breath! Be aware that I have been handling GPL issue for embedded system with various suppliers in a big Telco company with several internal lawyers specifically dealing with open source compliance. And they have the exact same position. But I'm ready to educate you. No need to be aggressive. "Except that what you are stating is complete bullshit." What exactly? First shim is signed with microsoft keys as explained here and in many other places https://access.redhat.com/articles/5991201. It was done as a way to separate microsoft world from open source world. Then as you know, shim can be build with its own internal keys see https://wiki.debian.org/SecureBoot and even dynamically import new ones via mokutils. You can also see the available keys it can use via mokutils or in the kernel keyring at boot. So when shim validates the next boot stages signature this is NOT obviously with Microsofts keys, just one of the key it can access. And in any case, depending on the algorithm, It would use the public key for validation not the private part needed to sign. shim itself is not GPLV3. Thus the fact that it is signed with Microsoft key does not imply Microsoft must convey the keys to the shim developers so that they can resign it themselves. What you write above in your answers is just factually incorrect : when you states for shim loading grub will be using Microsoft keys is just false. Then maybe you are not old enough but you should remember that GPLV3 was created to overcome the fact that GPLV2 mandates to give you the right to get the code and rebuild it but that unfortunately it does not require to be able to replace the software with you own modified version in a device you own. This is known Tivoization problem as https://en.wikipedia.org/wiki/Tivoization. And GPLV3 appeared. https://www.gnu.org/licenses/quick-guide-gplv3.en.html On embedded devices, if you sign a firmware image that contains GPLV3 code on a device that belongs to the user (e.g a PC), you should give the end user a way to rebuild a firmware image with the new code. If it is globally signed you have to provide the private key to sign the new image. If is is a single binary, then you have to give the private key for the binary. That's how our lawyers see it, and why many embedded devices stick to GLPV2 version of code (e.g nas with samba). I quote it the Free software foundation text : "This requirement is limited in scope. Distributors are still allowed to use cryptographic keys for any purpose, and they'll only be required to disclose a key if you need it to modify GPLed software on the device they gave you. " You maybe you will be more polite next time. |
Yes I am well aware of this. There is nothing in what I wrote that states otherwise or implies, as you wrongly assert, that I believe that statement to not be true.
Transitivity still applies. What happens to Secure Boot downstream does not isolate upstream.
Yes I am well aware of this. There is nothing in what I wrote that states otherwise or implies, as you wrongly assert, that I believe that statement to not be true.
You are misreading what I wrote. At no point did I even remotely imply that Shim in GPLv3.
Ad hominen. And, probabilistically, chances are that I am actually older than you are, unless you started programming on a Commodore VIC 20. But I am not pretending that age or experience implies more trustworthiness. Only what one writes does.
Are you trying to assert that I don't know what Tivoization is, when I did explicitly mention, I quote "due to the makers of the TiVo device" in what I wrote above, and pretty much explained what it was already?
We're not talking about embedded devices. And we're not talking about rebuilding firmware images. We're talking about Secure Boot signed bootloaders that are not embedded in firmware, and are provided independently of the hardware.
It's not.
And I would encourage you to read what one actually wrote before jumping to conclusions. I'm afraid that there isn't a single point, in what you wrote above, that appears to counter any of the argument I have put forward. |
|
By the way the "if" in the:
is critical. Because my whole point is that, despite what Microsoft states, and in the context of standard Secure Boot (i.e. Secure Boot that is not being extended to do something that it is not designed to do, which is to remove the ability from the user to install their own keys or disable it altogether) you do not need to gain access to the device manufacturer or Secure Boot provider's cryptographic key to "modify (and run) GPLed software on the device they gave you". |
|
Well I'm 60 already. How does ventoy then verify that any code loaded in memory has been verified by a kind of signature if Then I maintain that if the first code that is loaded by EFI bios is GPL V3, then I stick to my point that Microsoft would need to handle the signature key as the end user has right to replace it with a new version. |
|
If the code is GPLV3, I can ask for the code source, way to rebuild it and modify it. And you cannot prevent me to do it so you have to be prepared to handle the keys. Have this discussion with FSF lawyers before asserting I'm wrong. |
Congrats. You are indeed older than I am.
That's the root of the issue we are trying to fix. My understanding is that the GRUB used by Ventoy is simply too permissive, and lets everything go through, but since we are still in DXE, and therefore the Secure Boot validation from I am still unclear on why the GRUB used internally by Ventoy is apparently not using
I'm not asserting that you are wrong when it comes to embedded firmware. I am asserting that this is not relevant to what we are discussing. And I could most certainly say ditto here. Please bear in mind that we only have one side (Microsoft's), which has a very vested interest of (mis)interpreting the GPL in a very specific way, and has a precedent of peddling FUD against the GPL. I have read the terms of the GPLv3, and while I am not a lawyer, I do not see how Microsoft came to the conclusion they did. But, if you think you see anything in there that disproves what I am asserting, I am all ears. |
|
My point was :
So why is /EFI/BOOT/BOOTX64.EFI not signed? If it is because part of the code used is GPLV3 then we are back to my comment. And it is not only microsoft but also BSD, Apple, Intel, most GPL aware companies developing embedded firmware that use secure boot form with signature (not obviously UEFI. Now uboot has boot signature facilities)
|
If booting a Windows image or a Linux distro that uses Shim, it is signed. The problem we are trying to solve, here, is that
You can't if Ventoy runs a special chain-loader first, instead of your bootloader, and properly filters out unsigned bootloaders by performing Secure Boot validation by forcing its own chain-loading bootloader to run first (i.e. by replacing the |
|
"/EFI/BOOT/BOOTX64.EFI comes from the user-selected image, that the user copied on their Ventoy boot media, so it is whatever." Are you sure, I'm lost:
So I'm lost now. My view is that the first code executed is ventoy specific bootloader code in /EFI/BOOT/BOOTX64.EFI and that unfortunately it is not signed. Yet I dunno why exactly. I suspect GPLV3 code derived from grub. |
Well, the problem is that we are talking about multiple There's one for Ventoy, which, in a Secure Boot environment, would be signed and for which you add the signing certificate with Mok Manager. In a Secure Boot environment, that bootloader would simply not run otherwise (and my understanding of Mok Manager is that once you have enrolled a signing certificate then whatever code you sign with the corresponding signing credentials will be accepted by Secure Boot, because the trust chain that Secure Boot validates against will include that certificate and therefore see any code signed with those credentials as trusted for Secure Boot). So that's the first code executed, which, AFAIK, then executes a custom version of GRUB and along with a virtual UEFI CD/DVD driver, which in turn will present and allow the execution of whatever In short, my understanding is as follows (on a system where Secure Boot is enabled):
At least, this is how things seemed to behave last time I tested it, which is what prompted me to open this issue. Addon: Oh and the enrollment with Mok Manager is what allows Ventoy, as pure GPLv3 code, to be run in a Secure Boot environment, because then the trust chain does not need to validate up to Microsoft (which wouldn't allow it), but up to the certificate you installed (which, can 100% be used against GPLv3 code). |
|
I think I need to find a ventoy document describing the boot chain and the keys used to validate each stage. Now I'm puzzled by the boot flow. And yes enrolling keys and enabling to use them later to validate later boot stages is fine. However Linux distrib have shim preprovionned with their own key and so you only need to enrool keys if you build your own Linux kernel or use DKMS to produce modules. I guess only the first element in the boot chain (primary bootloaaer) has to be signed by Microsoft. his is the case on Linux with shim. |
|
I think you miss something. The first code to be run has to be signed with a key that pre-exist in the BIOS .db valid signature database. There is no way to add key there if you did not create the whole key chain or use existing Microsoft boot keys. You can read the efitool documentation that helps to do it :https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/README?id=392836a46ce3c92b55dc88a1aebbcfdfc5dcddce but doing this you may screw up all microsoft keys or Linux keys. Then the MOK enrollment keys use a different key database that comes in addition to the BIOS .db database. A clear indication for that is that Ventoy /EFI/BOOT/BOOTX64.EFI is NOT signed with the key present in the ventoy EFI partition. The code BOOTX64.EFI is just derived form the preloader code in the efitool boot code removing some security checks! Look at https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk So my view is that ventoy should use shim that is signed as a loader and not efitool preloader whose signature are no more in the .db or worst have been added in the .dbx like Super-UEFIinSecureBoot-Disk bootx64.efi (shim) → grubx64.efi (preloader) → grubx64_real.efi (grub2) → EFI file/OS |
Yes. This is standard Secure Boot validation.
Yes (that is unless you are cozy with the manufacturer of your kardware, as they're the ones who have control over the PK for your hardware). A good description of how you can carry out this whole procedure is described here.
These certificates are public, so they're not that difficult to add back even if you recreate the whole thing. As a matter of fact, when we're setting up Secure Boot for the Raspberry Pi UEFI firmware (where we build the whole Secure Boot trust tree from scratch), we do just that.
Indeed. The Shim transitively acts as an additional Secure Boot gatekeeper with its own trust chain. But it essentially performs the same function. You can consider it as Microsoft delegating Secure Boot validation to a third party entity, that will have the same rights (the ability to sign bootloaders that they consider trustworthy) and the same constraints (making sure that whatever they sign has been properly vetted, so that it's not going to defeat the whole thing. And for the record, adding your own MOK key(s) is not defeating Secure Boot, since it does require manual intervention). Curiously though, you will also find that these constraints do not include any clause about not signing GPLv3 code (since GRUB bootloaders are happily signed by the people behind Shim), even as the Shim folks sure maintain their own signing database, with their own private signing keys and should therefore be subject to the exact same legal requirements and alleged licensing pitfalls as Microsoft themselves...
Well, the first bootloader that resides in
If you're talking about the initial As you explained above, which is similar to my understanding, the initial
My understanding is that Ventoy/Super-UEFIinSecureBoot-Disk very much do, because if they didn't, nothing would boot when Secure Boot is enabled, as there is no such thing as a nonrevoked public bootloader, signed by Microsoft, that lets everything through. On the other hand, since, when you use the Shim, you can run MokManager to enroll pretty much any binary you want, and MokManager is signed by the Shim people (for convenience, so that it can run in a Secure Boot enabled environment as a second stage to Shim without having to ask people to disable Secure Boot), you may be under the impression that there is some kind of "bypass", but the only bypass, really, is having people manually enrol a certificate that the Shim will then consider as trusted. And that's still a far cry from anything resembling automatic Secure Boot bypass or some kind of unaddressed Secure Boot vulnerability. In short, Ventoy is not exploiting some kind of advanced "flaw" here. It's just using Shim so that it can ask Ventoy users to enrol the Ventoy cert in the Shim's MOK database, and, of course, once you are enrolled, you can do anything you want, including completely bypass Secure Boot, since you have now explicitly told Shim: "You should blindly trust bootloaders signed with these credentials". Unless someone had information to disprove it, that's how I assert Super-UEFIinSecureBoot-Disk eventually gets to run unsigned/invalid bootloaders and that's how Ventoy does so too.
I'd amend it like this (in a Secure Boot enabled environment), because I assert that what matters is who's in control of what part:
And yes, it's very possible that there's a preloader in between, but I have to stress out again that anything that intervenes before the code that is under Ventoy's control executes will be subject to the standard Secure Boot rules, and will be both outside of Ventoy's control and (allegedly) not subject to any known vulnerability/bypass that allows unsigned bootloaders to run. It's only ever once we have code that is under Ventoy's control that starts to run that unsigned bootloaders might execute. But not before (or else, you will definitely get either Microsoft or Red Hat to revoke your bootloader). |
Well looking at description on how to recompile from source (as this is the only way to know what is really done) So my guess is that /EFI/BOOT/BOOTX64.EFI is not correctly signed for recent bios (or BIOS with updated bdx which is the case for my laptop) and BTW if you look at the link for the other bug above, I list the signature for the boot code and the Ms signature is the old MS signature and not the one shim uses. You will also see that the dev acknowledge the BIOS should accept to boot a non correctly signed first stage boot loader
The key is then Debian one (in my case) and using mokutils you can replace the grub2 signature with your own MOK key so no need to disclose the Debian private key to replace any GPLV3 code (grub2) by a modified version. And BTW, a big thank you for Rufus that I use regularly with M$ related isos or Linux non hybrid iso. I just hopped ventoy would allow to replace my 10+ keys with a single SSD with all the iso on it. |
Yes, I got that. We know that something is disabling the Secure Boot checks that should normally intervene, be it in Ventoy (which is what led to this issue) or SuperEfi.
That makes no sense. There's no such thing as half working Secure Boot signatures. Either it's valid or it's been revoked. There's no middle ground, as anything that lets improperly signed bootloaders pass through will be revoked by Microsoft.
Then that is likely the reason. If you look at https://uefi.org/sites/default/files/resources/dbx_info.csv and compute the PE256 Authenticode of your Other possibility, if your
I'm not seeing that. And I don't know what dev you are talking about (the dev of Ventoy is @ventoy/longpanda, who I have not seen commenting on the issue you linked). If what we are calling a first stage bootloader is the Once again, if you do enroll your bootloader by adding your signing certificate as a MOK, you will still only ever be able to run your signed bootloaders as second stage bootloaders through the Shim, but not as first stage, because first stage still requires a Microsoft signature. All in all, I'm still not entirely clear as to how you are testing your custom Ventoy install, but what I can state is that:
Somehow, I get a feeling that you've been trying to mix both these options, whereas you really only need to choose one.
Which is exactly my point. As opposed to what Microsoft is pretending, there clearly exist options that do not force them to disclose their private signing key in order to satisfy the legal requirements of the GPLv3 (since they could easily create their own cert management suite too for users to interactively install their own signing certs). Ergo, their argument that they will be forced to publish their private key, if they start signing GPLv3 code, is utter and complete bullshit. |
extract from https://github.com/ventoy/Ventoy/blob/master/DOC/BuildVentoyFromSource.txt 5.10 UEFIinSecureBoot INSTALL/EFI/BOOT/BOOTX64.EFI --> EFI/BOOT/BOOTX64.EFI SHA-256: 475552c7476ad45e42344eee8b30d44c264d200ac2468428aa86fc8795fb6e34 So I understand it should be shim as you say but not sure about the shim version because they mention Super-UEFIinSecureBoot-Disk_minimal_v3.zip whereas the last version is _v3.4 and in bug 15 ValdikSS/Super-UEFIinSecureBoot-Disk#15 there are mention that people have problem with several version and explicitly mention a version used by ventoy. Some even complain like me that ventoy is not bootable even with most recent version. In addition there is a bug with some AMD AGESA BIOS (which i happen to have on the two machines) Regarding the signature (from untouched ventoy 1.096 tar.gz) cd ventoy-1.0.96/ventoy sbverify --list /mnt/EFI/BOOT/BOOTX64.EFI warning: data remaining[808656 vs 934024]: gaps between PE/COFF sections?
ls -l /mnt/EFI/BOOT/BOOTX64.EFI Thats for original ventoy BOOTX64.efi valette@tri-yann5:~/local/bin/ventoy-1.0.96/ventoy$ sbverify --list /boot/efi/EFI/debian/shimx64.efi warning: data remaining[823184 vs 948768]: gaps between PE/COFF sections?
That for shim on my debian system that boots as I'm currently using it So indeed Microsoft signature looks the same but one is accepted by BIOS in secure boot mode (as it is listed when I hit the bios key to select bootable device) the other is not so I'm still puzzled. However the shim sizes differ and probably the versions. Or is is because the ventoy efi partition is not normally build (FAT16 instead of FAT32, partition flags should be boot,esp and not hidden ...). So still no clue of why ventoy disk is not even proposed as bootable in the two machines.
But then, this means they should require everyone to recreate the PK and db, dbx database which is probably out of reach by most people (and many laptop BIOS do not have the option to recreate the chain of trust with new keys). |
|
Well, the Shim used by This means that, whatever issue people encounter with this, it has nothing to do with Secure Boot validation. Oh and I have no issue booting a media created from
Well, if the files are not revoked, then they should boot on any UEFI compliant system, which would tend to indicate that, if they don't, some manufacturers screwed up their UEFI compliance. Wouldn't be the first time (I used to see loads of UEFI compliance issues with Dells for instance) and won't be the last. I saw a few of those with my Secure Boot signed UEFI:NTFS bootloader which doesn't use the Shim, as it's a first stage bootloader), where people with specific machines sometimes reported issues, though in most cases they would get an error code from UEFI:NTFS itself, but my understanding is also that the people developing the Shim have taken the opposite approach of not reporting anything at all on error. There could also be issues with how the Shim is built in the first place, as the Shim folks recently took upon themselves to drastically overhaul gnu-efi, which they use in their build process, and introduced some regressions in the process, and of course, as the Shim code itself evolve, it can always introduce some platform specific bugs... So, yeah, if you can't immediately identify a UEFI bootloader as revoked, figuring out exactly why it doesn't boot may be a tough nut to crack...
As I said earlier, the Ventoy ESP complies 100% with the UEFI specs, because, as opposed to what many think, the UEFI specs have no special requirements when it comes to the type of FAT, or the flags. At least, that one should be easy to test, as you should be able to create a FAT16 hidden ESP with no boot flag, place a Secure Boot signed bootloader that you have found boots on your system, such as that debian system one, and see if that bootloader appears in your boot options (which it should, regardless of whether you have GRUB as the second stage bootloader for the Shim, as UEFI boot options just check for the presence of a
Well, I'm pretty confident that, since unlike the Shim, they do have their certificate installed by default, Microsoft could come up with means to delegate trust to a user-specific certificate if they wanted/needed to. But also, you seem to posit that having to recreate the trust chain runs contrary to the GPLv3 requirement whereas my reading of the GPLv3 license, and especially the "Installation Information" paragraph of section 6, seems to make it pretty clear that as long as you can recreate the whole trust chain to run your code alongside the original binaries which you can most certainly do if you recreate the Secure Boot databases from scratch (I have done it), you have satisfied the GPLv3 conditions. As a matter of fact, my interpretation of the section is that it's is 100% satisfied as long a you can disable Secure Boot altogether, as the whole point of the GPL is to let you run code that you modified on your hardware. I would encourage anyone to read the GPLv3 carefully, as you will find that it does not set any specific conditions about the user not having to alter the hardware settings to run their code. Instead it talks about:
and a procedure or method that allows using one's credentials, such as the method that consists of installing your own PK and all the certificates and revocation databases underneath clearly will meet the GPLv3 requirements (you also want to pay attention that the license terms use an 'or' and not an 'and', meaning that if you have a method or procedure that allows you to _"install and execute modified versions of a covered work", then you don't need the "authorization keys". That is why fully locked down hardware (like TiVo) is a problem with the GPLv3. But regular Secure Boot (i.e. one that you can disable or one where you can reinstall your own trust chain) is not locked down, so, again, contrary to what Microsoft is trying to bullshit people with, regular Secure Boot will never force you to disclose your signing keys there. Therefore, Microsoft's excuse for not signing GPLv3 code does not stand ground (and, as stated above, even if it did, Microsoft would have plenty of other alternatives to satisfy these requirements without disclosing its signing keys) and even if their goal was to ultimately be able to produce fully locked down hardware, i.e. one where the user cannot disable Secure Boot or install their own trust chain, they would always have the ability to release a firmware update, that unlocks the hardware, to avoid having to publish their signing keys. So, I have to be explicitly clear about this, no matter how you look at it, if you carefully place Microsoft's allegations of what the GPLv3 might ultimately require of them against the actual terms of the GPLv3, you realize that:
|
|
This issue is becoming rather chatty, I'm unsubscribing. Please tag me if it's related to my code in #135 (comment) or #135 (comment). |
|
@ValdikSS It is probably not related to your code as other UEFI system loader does not work either with the same Samsung T5 disk. I did a couple of extra experiments:
I suspect, the Samsung T5 USB controller and the BIOS EFI device selection dislike each other. Have no clue why yet. I verified the BIOS detect the disk correctly in the settings on USB disk. Sorry for the noise. But at least I learned a lot more on UEFI, ventoy and Super-UEFIinSecureBoot-Disk. Of course the disk works perfectly on the same port once booted. Even flashed the last Samsung firmware just in case. No change. Thanks for your patience. |
|
Having Ventoy run non secure boot on secure boot is a clear positive. Secure boot is not a security feature but instead a vendor lock in system that only allows Windows or distros that pay a fee to Microsoft. While on most computers you can disable it, some specific computers force it to be on. |
"Making the locks of my house ineffective is a clear positive"
"Locks are not a security feature."
Please provide the make and model of computers that allegedly force secure boot on. The only models I know that did that were the ill-fated WinRT ARM32 devices (namely Microsoft Surface RT and the Asus Vivo RT), that Microsoft introduced to test the waters on Secure Boot lock-in, and that resulted in enough of a blacklash from users that they had to give up on the idea of providing devices where Secure Boot could not be disabled. That was 10 years ago. Since then, and you better believe that I have been monitoring the situation very closely, I am not aware of a single machine where Secure Boot could not be disabled, and, even with the above devices (which were for ARM32 only), I am not aware of a single x86 based PC where Secure Boot cannot be disabled. So, if you do have information on a PC where Secure Boot cannot be disabled, I (and others) would really like to hear from you. Also the irony is that, on the devices where Secure Boot could not be disabled, Microsoft made sure that only their own internally signed binaries could run and not anything else, even if these other binaries were signed for regular Secure Boot, which means that, if such a scheme were to be adopted for PCs, you wouldn't even be able to use MokManager to enrol Ventoy, and you wouldn't be able to use Ventoy at all! Oh this story gets even better, because, since these devices were a bit too locked down, even for Microsoft's taste, they included a golden key (basically a Secure Boot backdoor that they would be able to use, without having to go to the trouble of signing binaries with their master key)... that, like all backdoors, eventually got found and leaked, which immediately rendered all these devices completely insecure... So, for people wishing to comment on this thread and who are misconstruing a desire to make Ventoy better (because I'm pretty sure the chain loading solution I described above, where Ventoy would replace the UEFI bootloader from the image with a chain-loading one, that does performs Secure Boot validation, is a workable solution to the issue) as an some kind of attack of Ventoy, I can only encourage you to do your research and, if you want to claim things like "Having a Secure Boot that doesn't actually does what's expected of Secure Boot is better" or "There are platforms, where Ventoy can run, where Secure Boot can not be disabled", to make sure you have done your research and to be prepared to provide some evidence to back up these claims |
|
slightly offtopic, but about policyhax: it did end up getting fixed with a neat trick that i didn't think was possible at the time (of discovery/documentation). the policyhax fix DID work on qualcomm ARMv7 systems (but not nvidia tegra systems due to how UEFI signed variable support was implemented, and at least one lenovo model got bricked by the fix, even though according to someone involved with the fix they gave out the test case beforehand at a UEFI Plugfest on gold-coloured USB flash drives), hence why I ported baton drop to ARMv7. not that it really matters in the end, as the "neat trick" was to avoid revoking production bootloaders, which turned out to have other vulns present anyway! (indeed, latest bootmgr builds have removed that "neat trick" to prevent vulnerable bootloaders from loading an affected secure boot policy, as it's no longer required) regarding other systems with secure boot locked on: windows phones, hololens (and probably other WCOS-based devices), Surface Hub all had/have secure boot locked on. i'm not sure about systems running actual client/server windows though (where I'm not counting PPIPro as "actual client/server windows"). |
|
Interesting. I kinda expected the now discontinued Windows Phone to be locked but I didn't know about the Surface Hub so I was wrong: there actually is one x64 based device where you cannot disable Secure Boot. But then again, seeing their security overview page, and as I hinted at above, you're never going to be able to run Ventoy on that device anyway, because, it appears to only let through bootloaders that use platform/Microsoft specific signature, which is different from the signature that Microsoft uses for regular Securer Boot. So you can forget about using MokManager to enrol the Ventoy key, which means that, people who do like the unexpected feature of Ventoy of letting any bootloaders through even when Secure Boot is enabled, would still be unhappy with such a platform. Now, to try to come back to the actual topic, and try to devise an actual solution to the issue (rather than expand on endless discussions about the pros but mostly cons of Secure Boot and Microsoft's monopoly on it), I'm going to point out that one test that should validate if the concept of having Ventoy replace the original UEFI bootloader with one that performs Secure Boot validation and only chain load the original bootloader if that validation passed should be relatively easy to check out by:
If (and this is what I logically expect to happen, since we should still be running with the UEFI boot services at this stage) you do get a validation error from the extra bootloader, then we have a clear path of how Ventoy could fix this very issue by:
And the nice thing is Ventoy wouldn't even have to get that chain loading bootloader officially signed for Secure Boot, as it should be able to sign it with the same key Ventoy is signed with to have it work in a Secure Boot enabled environment. And of course, this solution does not require altering GRUB at all, since, from what I gather, that seems to be the main point that is halting progress on this matter. I am planning to see if I can test something like this at some stage, but it'll probably be weeks (or months) as I'd rather use my time elsewhere at the moment, so if anybody wants to give it a try before I do, feel free to go ahead as, again, I'd much rather see this issue resolved than have it prompt another debate of X vs Y, where zero progress is made in the end. |
|
Okay, so my idea of trying to access the original At any rate, it does seem a bit pointless to go through an effort to reinstate Secure Boot validation dowstream, when, as @ValdikSS pointed out, it was disabled through code that is entirely under Ventoy's control (even if it is not code that was written for Ventoy originally), in the @ValdikSS, since I was testing, I finally try to play with your preloader-for-ventoy-prerelease-1.0.40.zip, but none of the UEFI bootloaders I tried to load from a All I got was a very brief: And of course, the same Still, I believe that the proper way to address the issue is indeed to fix the Super UEFIinSecureBoot binary used by Ventoy so that Oh and for the record, the MokManager currently used by Ventoy appears to have an issue when trying to enroll certificates with short names (will produce an |
Secure Boot must die. |
|
Secure Boot must die.
If you don't like it, don't use it, but stop with the pointless religious war (and with useless spam).
|
and others
Currently, on x64 systems, Ventoy is able to run when Secure Boot is enabled, through the use of MokManager to enroll the certificate with which Ventoy's EFI executable is signed.
However, because no additional validation is performed after that, this leaves system wide open to malicious ISOs.
For instance, someone could produce a Windows installation ISO that contains a malicious
/efi/boot/bootx64.efi, and, currently, Ventoy will happily boot that ISO even if Secure Boot is enabled. This completely defeats Secure Boot and should not happen, as the only EFI bootloader that should be whitelisted for Secure Boot should be Ventoy itself, and any other EFI bootloader should still be required to pass Secure Boot validation.Therefore, Ventoy/Grub should be altered as follows:
bootx64.efiis performedbootx64.efiis either not signed, or signed with credentials that aren't enrolled in this machine's Secure Boot store, or signed with credentials enrolled but with a hash that is in the Secure Boot revocation DBX), an error should be returned to the user andbootx64.efishould not be launched.Hopefully this shouldn't be too complex to add, though it may require some research, and modifying GRUB to do just that might require a lot of work.
I also hope that the people who are adamant about never disabling Secure Boot do realize that, as it stands, the current version of Ventoy leaves them about as exposed as if Secure Boot was disabled, which of course isn't too great... Thankfully, this can be fixed so that, even when using Ventoy, Secure Boot can continue to fulfill the purpose it was actually designed for.
The text was updated successfully, but these errors were encountered: