Ventoy should only allow the execution of Secure Boot signed executables when Secure Boot is enabled

[pbatard]

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:

1. Detect if Secure Boot is enabled
2. If Secure Boot is not enabled, proceed as normal.
3. If Secure Boot is enabled, signature validation of any chain loaded bootx64.efi is performed
4. If the signature validation fails (i.e. if the bootx64.efi is 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 and bootx64.efi should 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.

[mylesgoose]

I was able to boot unsigned operating systems in secure boot mode with this software. For example install Ventoy onto a usb device with secure boot enabled enrol the mok key. windows will boot bitlocker encrypted devices and kali Linux will not boot. It says secure boot policy issue yet if you try to chain load kali Linux it is not able to secure boot. If you copy the kali linux grub.cfg file to ventoy folder named vtoy_grub or similar the kali linux boot menu shows up, if you press F6 and it will boot up any system with secure boot enabled that is not actually secure without voiding the secure boot policy. It’s quite handy to be able to boot any insecure operating systems with the bios set to secure boot without having to enrol a new key every time with this chain loading method.

[mylesgoose]

You do understand that anyone with a usb device can simply upload a new bios to override the password on it. And disable any key management software and enrol their own keys. So allowing ventoy to boot unsigned operating systems while in secure boot mode with its enroled keys does not constitute a new security vulnerability of any system. In fact it’s a very handy feature. Because in order to use windows bit locker you must have the bios set to secure boot. And it is a pain in the bum having to switch bios from secure boot to non secure boot to boot unsigned kernels. With ventoy you simply need to enrol ventoy key once in the bios. And a small hack to trick ventoy with a signed shim for grub from Debian for example. And then we can boot any unsigned kernels with one trick kernel. Thereby only having to enrol one key for ventoy. All programs run nicely thinking the bios is in secure boot mode. The thing with secure booting is it’s very overrated. And it gets in the way of genuine programming without providing any real security features. If someone has assess to your physical machine your in trouble. Consider for example a keyboard logger to clone on day one your keystrokes and password to login. Or bios reset or even override your password in windows. Very simple to do. You can do that with free software now. In my opinion having ventoy keeping secure boot on in all situations enabling bitlocker for windows etc makes the system a little more secure than without ventoy. The the constant loading and unloading of secure boot to boot alternate distros makes it more likely to disable bitlocker etc.

[pbatard]

<sigh> Alright, I'll bite.

You do understand that anyone with a usb device can simply upload a new bios to override the password on it.

Except this will leave a very obvious trail to the user, who will find that their password has been changed. There's a huge difference between stealthy and non stealthy adversarial action.

So allowing ventoy to boot unsigned operating systems while in secure boot mode with its enroled keys does not constitute a new security vulnerability of any system.

One could consider it does when malware, that Secure Boot is designed to filter out can be executed, without leaving any trail, and that is the core of the issue, even though I agree that it's difficult to qualify this behaviour as a "vulnerability" when a vulnerability is something that a developer overlooked, that allows malware to run, whereas, in this case, we have Ventoy pretty much disabling Secure Boot by design, once you enrol it into MokManager...

In fact it’s a very handy feature.

No it isn't. Promoting the complete bypass of a first line of defence, because you are arguing that it inconveniences you on account that it makes your walking path longer because you have to skirt a fortification wall and that "this first line of defence will be useless in the face of a large enough trebuchet anyway", does not constitute a valid argument. Furthermore, I will assert that you are either willingly or unwillingly misconstruing what the whole issue really is really about, in an attempt to dismiss it as invalid.

So, let me (re)frame the issue back to what it is actually about which is that:

1. There exists a first line of defence, called Secure Boot, that, like antivirus solutions, does have drawbacks and advantages, which we could discuss at length, but that, when enabled by a large enough number of people, does work fairly well as a first line of defence to help prevent the spread of malware. And yes, this applies even if, with someone with state/government level of resources (as we have long already established above), this line of defence would probably be trivial to stealthily bypass (and again, the key here is stealth, because if your attempt to run malware is detectable by the user, then that detectable malware a lot less dangerous than one that does not leave an obvious trail, because it can be identified and mitigated early).
2. Incidentally, this first line of defence also allows users to issue bypasses for software they want to vet, just like, someone controlling a first line of defence might be able to issue special passes to specific individuals whom they trust and that they want to allow through one of the the defence's gate.
3. As the stewards of their own gate, people may decide that Ventoy is trusworthy enough to be issued a bypass with the OBVIOUS expectation that such a bypass should apply to Ventoy and to Ventoy only.
4. However, what Ventoy is currently doing is effectively letting anyone who wants to, to use the Ventoy-specific bypass to let themselves in through the first line of defence, including bad actors.

And I'm afraid that none of your arguments above address point 3 and 4, which are the crux of the matter here.

In short, what Ventoy is doing is akin to someone whitelisting an application in their antivirus solution, because they think that this specific application should be trustworthy enough, only to find out that said application now allows any other application to effectively whitelist itself as they wish, thereby defeating the whole point of running the antivirus in the first place.

So, once again, and it seems I have to make this ABUNDANTLY CLEAR, the root of the matter is not about how effective or inconvenient Secure Boot (or antivirus solutions) are or how one's anecdotal experience that they find it more inconvenient than useful should be construed as a clear indication that nobody who whitelisted Ventoy should ever want a working Secure Boot again....

Instead, the root of the matter is that the vast majority of people who have Secure Boot enabled will be expecting Secure Boot to still fulfil its purpose of detecting bootloaders that are either not Secure Boot signed or have failed Secure Boot validation, even after they have whitelisted Ventoy, and, currently, this is most certainly not the case. Instead, and I think I need to hammer that point down explicitly again, if you have whitelisted Ventoy on your computer, and have Secure Boot enabled, anybody can run any unsigned or compromised bootloader they want, whereas, on a Secure Boot enabled computer where Ventoy has not been enrolled, these will be blocked, thereby helping preventing the spread of the common malware that Secure Boot was designed to prevent.

The thing with secure booting is it’s very overrated.

It's not overrated. It just appears to be grossly misconstrued by people who erroneously assume that, if it cannot stop all forms of malware, including the kind of stealthy state-backed one or the not-so-stealthy "I have had physical access to your computer" one, or if it happened to inconvenience them once, then this must mean that it is useless.

This is the same line of arguing that would state that, if vaccines are not 100% effective, as they are, then nobody should ever get themselves vaccinated...

All programs run nicely thinking the bios is in secure boot mode.

Yeah, that's like having a fake antivirus running just to stop Windows complaining that you don't have an antivirus running, thereby missing the whole point of antiviruses which is that, if you do have enough people running up to date antiviruses, common malware will not be able to spread as effectively and, collectively, everyone will be better of.

If someone has assess to your physical machine your in trouble.

Yes, we have long established that, quite a few posts ago (if you do care to read them). And we have also established that this is irrelevant to the matter at hand, which is that people who have Secure Boot enabled do not expect Secure Boot to be rendered completely useless the minute their enroll Ventoy in MokManager.

And I am still seeing very few people, where most simply appear be annoyed that someone is pointing a rather obvious flaw that I am still hopeful the Ventoy developer will consider serious enough to fix, trying to justify how having Ventoy effectively disabling Secure Boot, without explicitly notifying its users that they are effectively disabling Secure Boot, is okay.

Instead, what we are seeing are people waxing lyrical on how Secure Boot is irrelevant/overrated anyway, whilst completely skirting the point that users will have no idea that the Secure Boot: Enabled they see in their UEFI interface turns into a big fat lie the minute they enrol Ventoy, because a computer with Secure Boot enabled should NEVER EVER let through the kind of bootloaders Ventoy will now be let through, without second glance.

In my opinion having ventoy keeping secure boot on in all situations enabling bitlocker for windows etc makes the system a little more secure than without ventoy.

Again, that is not the point. The point is that, as Ventoy becomes more and more popular, and more and more unsuspecting people enroll Ventoy, and as long as nothing continues to be done in Ventoy to either perform the kind of Secure Boot duties that a user with a Secure Boot enabled machine rightfully expects (which is to check the signature of all UEFI bootloaders and stop or warn if a bootloader has an invalid signature) or explicitly alert them in the user guide that if they enrols the application in MokManager, they will effectively have disabled Secure Boot, Ventoy is becoming as a contributing factor to the spread of easy-to-create/hard-to-eradicate/stealth malware, that Secure Boot is designed to prevent...

[steve6375]

Assuming Ventoy had already been white listed using MOK manager at some point.

How difficult would it be, in practise, to write virus software (downloaded and run whilst using an OS) to install the Ventoy efi boot file and then automatically load their own boot-time virus code? Won't the Ventoy boot code in the EFI boot file do certain checks that it is booting from a Ventoy drive (ptn2 = 32MB, Ptn2 sector start position, MBR has Ventoy signature, etc.) and so prevent any further viral payload from being executed?

So the only danger is that Ventoy will allow non-secure files to be manually run from a Ventoy drive when someone has physical access?

So all that is needed is for Ventoy to warn the user, before the Ventoy menu is usable, that although Secure Boot is enabled, unsecure payloads can now be run? i.e. WARNING: Secure Boot has been disabled! Press 1 to continue...

Would this suffice?

[pbatard]

Well, I don't really have a horse on how Ventoy should do it.

My preference, since I still believe this should be achievable, would be for Ventoy to invoke the UEFI Boot Services LoadImage() to vet the bootloader before it starts it, as, in a Secure Boot environment it should return EFI_ACCESS_DENIED or EFI_SECURITY_VIOLATION if the bootloader does not pass Secure Boot validation.

But I would still be fine with any kind of explicit warning to the user that Secure Boot is effectively not vetting bootloaders when Ventoy is being used to load them.

As to your question:

So the only danger is that Ventoy will allow non-secure files to be manually run from a Ventoy drive when someone has physical access?

No the danger is that, I, as a malware author, create a Windows 10 23H2 ISO pre-activated.iso that I upload for unsuspecting users (making all the more alluring that there is not in fact a 23H2 for Windows 10, but the same would work for a preactivated Windows 11 23H2), where I replaced the Microsoft Secure Boot signed bootloader with a version that installs permanent UEFI malware before actually running the Micrsoft bootloader.

If "unsuspecting user" happens to use Ventoy to install Windows, then it's game over. I have stealthily implanted malware on their computer that no amount of reinstalling the OS will eradicate and accomplished exactly the kind of thing that Secure Boot is designed to make difficult enough for non state-backed malware authors not to be able to perform.

And obviously, I did not require physical access to compromise their machine. Just a tempting enough lure...

[steve6375]

I don't quite understand? As soon as the user rebooted, because Secure Boot is enabled, the malware boot loader would not boot as it would not be signed? Or would it white list its own boot loader during install?

[pbatard]

If you have UEFI boot, you can exploit UEFI vulnerabilities. For instance, we don't have to look more than 2 days ago to find one. Or you can just install one of the BlackLotus-vulnerable Secure Boot signed bootloaders that Microsoft still hasn't revoked... Or, as you pointed out, you can most likely add some exception for your bootloader, since you did gain full control to a Secure Boot enabled environment in the first place.

I'm not a malware author, but if I was, I wouldn't worry about being able to continue to have access to a system if I am able to gain full control to it's UEFI environment once, because my understanding is that you will have more than enough means of performing privileged actions to fully compromise the system.

And, to get back to my original point, you shouldn't consider that it's ever okay to let a first line of defence get bypassed, just because you think a second or third line of defence might hold.

[mylesgoose]

I test security vulnerability and my point is that secure boot is a white coat, a knight in shiny tin foil. It’s letting everyone believe they have a secure system when it’s simply not. My argument is that it is best for someone to not have false security and believe their boot loader is secure because they have secure boot enabled. Imagine a castle with a polystyrene wall painted like bricks. This is secure boot. So my arguments are that ventoy does not make it any easier for a hacker to gain acess because there are freely available tools now like black lotus to bypass that if you have physical access. On a windows machine yesterday I took a copy of the registry for the keys override it with my own keys and then pasted back the users keys. So I don’t know the users keys but I was able to gain full access to their system and now I can flash back their original keys they have no idea I was their. Well they do because they asked me to login. Yet if they had bitlocker enabled I would have had to wait for gpu to hash that out because they had forgotten their password. Or you can take a dump of someone bios and upload a bios without a password I have even done this via JTag to most secure operating systems in world like Xbox bios etc.with Sony PlayStation it was simple as using a usb micro controller. with physical access the device is not secure. In this instance the user has chosen to disable secure boot to allow ventoy to operate. While it is still “enabled” for Microsoft boot sequence if you don’t choose to boot with ventoy first. This allows for bitlocker to be enabled and allows the user to run unsigned operating in a second environment while having bitlocker enabled. The bad maid attack still exits here. Your argument seems to stem from the fact that this makes the device vulnerable to future attacks. My point is that the device is currently vulnerable anyway with an operated with a usb device.. Except less vulnerable now the user knows secure boot is essentially disabled while reporting to be enabled. I was yesterday able to run the Linux image kali inside a vhd file with secure boot enabled with mok key for ventoy enrolled. Without any further modifications to the. Grub loader. So there are now two known ways to boot unsigned kernels with ventoy which i can confirm. What is supposed to happen is grub itself prevents it. Which it does do if you simply try to run it by booting the efi directly from grub in ventoy. I was only able to run encrypted operating systems inside a vhd or vdi file it won’t run directly from the stick open after grub screen, it can’t locate (hd1,gpt7)the encrypted partition as this is not in grub 2.04. So we can say that this can also be achieved with the original grub source code to boot any unsigned kernels by signing our first bootloader. Grub2. What I can say is this is actually a grub 2 vulnerability not a ventoy vulnerability. And most certainly is a secure boot problem. So what needs to happen is to fix secure boot . And stop pretending it’s secure the name is a contradiction of terms . One of the funny things with windows is it makes you enter your key as soon as boot loader changes and if the bootloader has changed they key is stolen as soon as you reenter it. On a wifi attack a clone of the wifi login page is given to users and the user reenters their password Microsoft is essentially helping by presenting the bitlocker unlock screen for reentry. Did you know there is also a system to disable the check on secure boot by windows and it still thinks it’s booted securely? There is modifications to the dll files in windows. By the hacked bootloader so the user does not even get notifications that the bios is changed. With the drive encrypted it takes one more boot cycle and notification before we can insert the code into the operating system as the user is presented with a password screen. At this point if he or she does not enter the decryption key and reinstalls bios or bootloader he would be secure if is password was long enough. Yet that is only from a malware distant attack. Because secure boot is disabled in the operating system itself on the second boot.. Yet it thinks it’s still turned on. There only needs to be one known entry point to make secure boot fail. And these entry points exit prior to ventoy being installed. We can argue with ventoy to update the grub bootloader as soon as the issue is fixed in the grub version that’s available now and that won’t be fixed until the entire process is redesigned for the boot system. How many times do you log into your bios also to check if the password is the same? As soon as I can flash a new password to the device and put a new firmware on without password it was not secure anyway also.

[mylesgoose]

I don't quite understand? As soon as the user rebooted, because Secure Boot is enabled, the malware boot loader would not boot as it would not be signed? Or would it white list its own boot loader during install?

Because you enrol a MOK key into your bios and say trust ventoy, grub 2.04 as a trusted bootloader the bios passes control and security over to ventoy and no longer checks if the kernel is signed because we are self signing it and saying we agree it’s not verified by Microsoft yet run it anyway and report it’s secure and trusted. The next step grub and ventoy are supposed to check if the future iso vhd vdi files or efi files are secure and only boot them if they are. And this can’t be done or the program would be useless. So it can boot any kernel signed or secure or unsigned and insecure from that point. The vulnerability lies with chain loading the boot process to install and load a hacked key logger or memory dump tool in between the primary operating system and grub2. And the system then boots normally checks with bios if secure boot is enabled and carry’s on normally. The operating system thinks it’s secure because we have enroled a trusted key. The next operating system can use its own trusted key like windows and report everything is okay. When it’s not okay. Because if you have been hacked this badly everything is digital saved to secret storage vhd folder or transmission to secure server and reporting that it’s just an update process or something similar. Anyone with computer acess can install this without ventoy. So the issue is not with ventoy itself. It’s about chain loading and not checking the ram for other operating systems etc it’s laziness by Microsoft. If someone wanted to steal your credit cards or identification or monitor you this approach would work currently.

[pbatard]

Your argument seems to stem from the fact that this makes the device vulnerable to future attacks.

No. Once again, you are constructing a straw man.

My argument is that someone who enabled Secure Boot and allowed a specific application (Ventoy) to be enrolled for Secure Boot, does not expect that it will now enable themselves or other people to let boot media with a UEFI bootloader that is unsigned or doesn't validate the Secure Boot check, to pass through.

Except less vulnerable now the user knows secure boot is essentially disabled while reporting to be enabled.

The user does not know that Secure Boot is essentially disabled. That is my whole point.

All the user knows is that they enabled Ventoy to work with Secure Boot. And that their UEFI menu still reports that Secure Boot is enabled. So I'm going to ask in which world you live to pretend that when something says its white, users are somehow expected to understand that it's actually black.

If you can create bootable media with an unsigned UEFI bootloader that will boot, in UEFI mode, on a system where Secure Boot is enabled, then it logically follows that, for all intents and purposed, you have effectively disabled Secure Boot because it can now be completely bypassed.

What I can say is this is actually a grub 2 vulnerability not a ventoy vulnerability.

Doesn't matter where it is located. Ventoy reuses GRUB, and, if you read what I stated above, there is no issue about whether we should qualify this as a vulnerability and for what codebase. I really couldn't care less about finger pointing, because I did not open the issue to point the finger at anyone. What I do care about are the expectations from the users who enrolled Ventoy, and last time I checked, there was absolutely nothing even remotely hitting to Ventoy users that if they currently enrol Ventoy, then anybody will be able to bypass Secure Boot on their system. And please, since it seems I have to stress this out again, note that I am not mentioning the merits or lack thereof of Secure Boot, because all I am only talking about are user expectations.

So, once again, the issue, has to do with user expectations that is a UEFI firmware says that Secure Boot is enabled, then the system should not let non Secure Boot bootloaders pass through. And whoever needs to do something to fix this needs to fix this, be it by either modifying their codebase, placing a big warning about what enrolling Ventoy really entails when it comes to Secure Boot, or by pestering the GRUB or Shim folks so that they sort something out upstream.

What shouldn't be done on the other hand, is pretend that everything is in fact peachy, dispute at length who should actually be blamed for the issue (especially if it seems we are somehow now trying to pin part of the blame on Microsoft), and wrongly assert that end users should "know" that when their UEFI firmware says that Secure Boot is enabled, it is actually effectively disabled "but that they are actually safer this way"...

And stop pretending it’s secure

Who are you addressing here?

If it's myself, then you're trying to put words in my mouth that I have never ever uttered, and therefore trying to construct a straw man. Heck, if you want to fling anecdotal evidence around, to confuse people reading this so that they completely miss the point, I could point to the fact that I personally identified Secure Boot vulnerable bootloaders that Microsoft forgot to revoke as part of some BlackLotus prospection. But, whereas this should give you some evidence that I should be the last person to claim that Secure Boot is "secure", is that relevant to the issue at hand? No. Because, once again, and as a security person I'd expect you to know something about this, we are talking about mitigation, which is something Secure Boot is meant to accomplish (regardless of whether you want to dispute its actual effectiveness) and which, as always, is the best we can ever hope to accomplish in terms of security.

All in all, it seems that you are taking objection to someone (not me, else you would see that term appear in the post where I opened the issue) apparently trying to squeeze "Ventoy" and "vulnerability" in the same sentence, instead of acknowledging the point, which I am not seeing you address, that someone who enrolled Ventoy will not be expecting that doing so will leave their system's door open to running unsigned UEFI bootloaders when that same system states that Secure Boot is enabled.

So please do everybody, who are probably tired of reading through the now countless paragraphs that are being added to this issue, a favour and, if you want to reply further, make a concerted effort to try to only address the root of the matter which is solely about what a user, whose system states that Secure Boot is enabled, and who has enrolled Ventoy, should be entitled to expect (my point being that unsigned or non validating UEFI bootloaders should not be let through), or be warned about (my point being that, if we can't get the former, there should be a HUGE WARNING somewhere, that enrolling Ventoy for Secure Boot will effectively disable Secure Boot).

[mylesgoose]

Any idiot knows if you download a Chinese application and install it to your system and it asks you to enrol a new MOK key that secure boot is now disabled for that application. Yet it will report as enabled. It seems your grief is that ventoy does not notify the novice user that any unsigned code can now run if deployed from ventoy or someone uses their mok key. Which is now enrolled. And publicly available. Should ventoy also notify the user that the hacker can still enrol their own mok key as they just did as well? I agree it is not clear to most that the system can now run any kernel. Once enroled. Yet you do agree that the hacker can simply achieve the same results without ventoy given the current flaws with the boot loader secure boot design.

[pbatard]

"Any idiot" is entitled to think that if it enrolled a single UEFI application (which, transitively means that they have chosen to trust that application and only that application), they haven't effectively enrolled every single other UEFI application in existence, which is effectively what happens when their system will now let let any single UEFI booloader pass through.

It seems your grief is that ventoy does not notify the novice user that any unsigned code can now run if deployed from ventoy

Well, duh. But only partially.

My grief is that people do expect Secure Boot to still work as designed, which is to filter out every single UEFI bootloader that has not been signed by Microsoft (or the shim folks if a ahim is used) or whitelisted by the user, and Ventoy breaks that promise.

It's really as simple as this.

Should ventoy also notify the user that the hacker can still enrol their own mok key

Can people enrol Mok keys without user interaction? And, since I suspect you will try to turn this thing on its head and pretend it's a chicken and egg problem, whereas it really isn't, I guess I need to add: in a Secure Boot environment that works as advertised and does not let any unsigned bootloaders pass through.

I agree it is not clear to most that the system can now run any kernel.

Wow, we are actually getting somewhere.

I will assert that it is not clear at all to the vast majority of Ventoy users, who will be following some guide telling them that if they want to run Ventoy along with Secure Boot, they should enroll Ventoy, and who will have no idea that this does a lot more than only allow the Ventoy/GRUB UEFI bootloaders to run...

Yet you do agree that the hacker can simply achieve the same results without ventoy given the current flaws with the boot loader secure boot design.

Nope. You're putting words in my mouth again, and whereas you were having me defending Secure Boot as secure earlier (which I never did) you are now having me stating that Secure Boot is insecure (which I never said either).

So, for the nth time, all I am saying, which I believe is a reasonable expectation that has absolutely nothing to do with whether one feels like qualifying Secure Boot as secure or insecure or whether there may exist exploits at one time or another, is that one is entitled to think that, after they enrolled Ventoy, Secure Boot will still continue to filter out invalidated UEFI bootloaders, whether they are provisioned by an image residing on a Ventoy enabled media (which will no longer be the case) or directly (which will still be the case).

There's no need to involve "idiocy" (or more accurately "No true Scotsman") here. Regardless of where Ventoy originates from (China, Antarctica or the Moon), and whether you are requested/guided to enrol a Mok key for that specific application to run, I will assert that it is an exceedingly reasonable expectation to have that Secure Boot will still continue to work in the manner it was designed, and continue to act as a filter for UEFI bootloaders, regardless of their provenance. Or, if that contract is broken, that the breakage will be made very explicit to the user so that, no matter how much one wants to insult their level of intelligence, they can still try to make an educated decision about it.

[mylesgoose]

Ventoy boots what you load in there. It’s that simple. The users is responsible to ensure he installs trusted programs with it.

[pbatard]

The users is responsible to ensure he installs trusted programs with it.

"The user is responsible never to install malware. Having an antivirus say "enabled" when it is actually disabled, thereby rendering a first line of defence against malware utterly ineffective falls on the user (who should be more careful about not installing malware, even by accident) and not the application that effectively disabled it..."

Yeah, that flies...

Oh, and you are still brushing an issue under the carpet that, even if the user is careful to only install trusted programs with it, anybody else can now come and install malicious programs on the user's system without the user being able to do anything about it, which is a big part of the problem (and the reason why, because it's inconvenient, a lot of people here seem to want to resort to the fallacy of "well, if someone has physical access to your system, it's game over anyway", which we've already gone over at length, and which does not take into account that we're talking about a security feature designed to help prevent these kind of things now falsely stating that it's preventing them when it actually isn't).

[mylesgoose]

The users is responsible to ensure he installs trusted programs with it.

You have quote marks around a statement your making? It represents a security vulnerability having to turn bit locker and secure boot on and off each day to run unsigned kernels. With this system you can dual boot signed and unsigned. The encrypted signed one only notifies you that secure boot has changed and you don’t type your bitlocker key in and check firmware boot etc. because you fail to understand a key logger is easy with direct access more so than direct access with isos on ventoy. makes for a very secure system. Also boot any isos pretty cool. I don’t see what your whining about. Do you want to enrol this key yes or no. It does not do so without asking. Secure boot is fake name anyway it’s like an antivirus program without root acess. Uselesss.

[Wack0]

Easy solution in my opinion:

if secure boot is enabled, require physical user presence (ie, keyboard input) before running any .efi file.

Bypassing secure boot as long as keyboard input is required to do so is allowed; MS themselves do that ("disable driver signature enforcement" on winload advanced options menu allows for arbitrary code execution before ExitBootServices).

Given that this appears to be some usb boot menu: if secure boot is enabled, require showing the boot menu (even if only one option available) and disable any automatic boot timeout/etc, such that keyboard input is required to boot anything.

[pbatard]

Well, the thing is, if there is code in Ventoy to detect when Secure Boot is enabled and perform a Ventoy specific action (which I think is your suggestion above, as I don't think GRUB on its own can do what you suggest... but I will point out that I don't know enough about the Ventoy+GRUB intrinsics so I may stand corrected), then it should be possible to have code that vets the EFI executable by sending it to LoadImage() and check if it returns an error code, which is really all that is needed to find out if a EFI executable passes Secure Boot validation or not.

Then again, as long as the prompt while waiting for keyboard input does warn the user that they are being asked for input because they may run bootloaders, including potentially malicious ones, that Secure Boot would normally filter out, it'd still be much better than the "Secure Boot is enabled... but not really" that we currently have after Ventoy is enrolled.

[pbatard]

Another avenue, and that might be worth exploring is that, since the main feature of Ventoy (insofar as how I understand the application to work) is to present the system with a virtual CD/DVD device where Ventoy has the ability to map content from an image as well as modify it on the fly (so as to inject or overlay additional data it wants the system to see), one way of properly addressing the issue at hand would be for Ventoy to overlay/replace the original efi/boot/boot###.efi bootloader from the ISO with a Ventoy specific boot###.efi, signed with the same credentials that are used to sign the ventoy efi application that gets enrolled, and that would:

1. Fetch the original ISO boot###.efi bootloader from the Ventoy virtual device (through a special virtual device query or something).
2. Run that bootloader through LoadImage() (which it'll need to do to chain load it anyway)
3. If the previous step validated, which will only happen if the bootloader passed the Secure Boot validation run StartImage() on the loaded image to chain load the original ISO bootloader. Or, if we want to be more permissive, one could also warn the user the the bootloader they try to launch violated Secure Boot validation and ask them if they still want to run it anyway.

Considering that the process of enrolling the Ventoy certificate does allow the owner of said certificate, i.e. the developer of Ventoy, to sign any EFI executable it wishes and have it pass Secure Boot validation, it does look to me like using an overlaid/replaced UEFI chain-loader, signed by the Ventoy developer might offer a solution to the issue at hand, and place all the modifications required to fix this issue outside of the GRUB codebase.

I'll also point out that writing a UEFI chain loader is very-easy, at least as long as you can sort out for the second stage bootloader you chain load to either reside on a file system you have access to or be loaded in a buffer. An example of doing this can be found in uefi-ntfs for instance.

Now, the potential caveats:

1. I'm not sure how capable the Ventoy virtual CD/DVD device is during the UEFI DXE phase or whether Ventoy is not simply reusing virtual device code from GRUB. So it's possible that overlay/replacement might not be (easily) feasible that early.
2. ISOHybrid images may shove their UEFI bootloaders, along with the whole ESP, into a efi.img FAT image that itself resides on the ISO-9660/UDF file system. So you can't just look at searching for a efi/boot/boot###.efi on the ISO file system and replace/overlay that (though, to boot an ISOHybrid, the virtual device should obvioulsy always have mapped the bootloaders into a file system that the UEFI system can see, so this may not be that big a deal).
3. As usual, you're going to have to multiply the UEFI chain-loaders for all the archs you want to support. But then again, Ventoy already has to do that for the main UEFI application and, in the absolute, you don't even have to detect the arch to present the right bootloader to the system, if you always make them all available regardless of the arch (i.e. the virtual device can pretend that the bootx64.efi, bootia32.efi, bootiaa64.efi Secure Boot validating chain-loaders are always present on the virtual image, and rely on the system to pick the relevant one, rather than only present bootx64.efi for x86_64, bootia32.efi for x86_32, etc as needed).

[pbatard]

Just adding a note that it seems I'm still thinking in terms of Secure Boot working as designed even after Ventoy has been enrolled, which, as we have seen, it doesn't, so there shouldn't even be a need to sign the Ventoy UEFI chain loader (since the problem we are trying to solve is that Ventoy does run any unsigned UEFI bootloaders when Secure Boot is enabled).

Still, if we can make sure that the chain loader is always executed in place of the original UEFI bootloader from the image, and that Secure Boot validation is performed by that boot loader, I'm hoping that something along the line of what I'm describing is feasible.

[EricV]

A couple of comments on this subject:

1) It is normal if you want to keep your keys secrets you cannot allow GPLV3 => it give the user the right to replace the file even when signed so you end up giving the private keys for signature or infringe the GPLV3, 2) In another thread I discovered that /EFI/BOOT/BOOTX64.EFI is unsigned and I thing anything loaded shall be signed with allowed keys (and shim layer allows you to add some). 3) the concept of trusted boot relies on a trusted chain and root of trust and here even the first non BIOS element is untrusted, so signing anything after that is useless from a pure security point of view.

[pbatard]

it give the user the right to replace the file even when signed so you end up giving the private keys for signature or infringe the GPLV3,

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.

1. Microsoft would of course not bend over and say "Oh, you're totally right. You got us: here you go" and hand over their signing keys, but instead, they would call on their army of lawyers to challenge the request in a US court.
2. This would lead to a super interesting legal proceeding where, if the "prosecution" (but I am using the word loosely here) lawyers do even a half-assed job, it would become either very apparent that Microsoft could not have logically believed their statement to be factual while simultaneously allowing bootloaders like Shim to be signed, as well as what I would expect statements from the FSF along the lines of "Microsoft appears to have chosen to interpret the terms we added for GPLv3 wrong".
3. Finally, an half awake jury would agree that, rather than Microsoft being forced to hand over their secret key, the GPLv3 legal requirements can be fully satisfied, if needed, as long as the provider of the hardware provides a UEFI update that allows the user to install their own certificate or disable Secure Boot altogether, which, as we have seen above, should NOT occur if a hardware manufacturer does stick to the UEFI specs, but is instead hell bent to add additional rules on its own, in order to restrict what the person who purchased the hardware should have the freedom to do.

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.

3. the concept of trusted boot relies on a trusted chain and root of trust and here even the first non BIOS element is untrusted, so signing anything after that is useless from a pure security point of view.

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.

[EricV]

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.

[pbatard]

First shim is signed with microsoft keys

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.

It was done as a way to separate microsoft world from open source world.

Transitivity still applies. What happens to Secure Boot downstream does not isolate upstream.

So when shim validates the next boot stages signature this is NOT with Microsofts keys.

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.

So what you states for shim is just false and then shim itslef is not GPLV3 so what you say is totally not relevant.

You are misreading what I wrote. At no point did I even remotely imply that Shim in GPLv3. What I stated is that Shim is used to load GRUB, and GRUB is GPLv3.

They maybe you are not old enough

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.

This is known Tivoization problem

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?

On embedded devices, if you sign a firmware image that contains GPLV3 code, you should give the end user a way to rebuild a firmware image with the new code.

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.

If is is a single binary (...)

It's not.

maybe you will be more polite next time.

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.

[pbatard]

By the way the "if" in the:

if you need it to modify GPLed software on the device they gave you.

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".

[EricV]

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 /EFI/BOOT/BOOTX64.EFI is not? This is the secure boot principle (trust chain).

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. And that is why they refuse to sign GPLV3 code.

[EricV]

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.

[pbatard]

Well I'm 60 already.

Congrats. You are indeed older than I am.

How does ventoy then verify that any code loaded in memory has been verified by a kind of signature if /EFI/BOOT/BOOTX64.EFI is not?

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 LoadImage() should still apply (because that's a boot service, or at least its Secure Boot validation part, that can't be disabled unless the user does it in the UEFI settings), then because Ventoy has control over the first UEFI bootloader that is being run from GRUB (since my understanding is that it provides a virtual CD/DVD device and can therefore control what bootloader it presents to the GRUB used internally by Ventoy) it can verify the signature in a manner that will uphold Secure Boot.

I am still unclear on why the GRUB used internally by Ventoy is apparently not using LoadImage() to run UEFI bootloaders, as it seems counter intuitive to write your own equivalent, and if it did, then I wouldn't expect this issue to materialize.

Have this discussion with FSF lawyers before asserting I'm wrong.

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.

[EricV]

My point was :

1) There is no secure boot if the first element loaded in RAM of what is supposed to be a chain of trust is unsigned. Currently /EFI/BOOT/BOOTX64.EFI is not. It must be signed to pretend to have UEFI secure boot support and this has to be with a Microsoft key as it is the first element that only has access to BIOS/Microsoft provisioned keys. The ventoy documentation is just lying about verified secure boot support.

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)

2) You may want the rest of the trust chain to be secure (your point was the way grub is used by ventoy and I agree on this part) but secure boot is already defeated as I can replace BOOTX64.EFI by any bootloader code including an additional malware like UEFI malware.

[pbatard]

So why is /EFI/BOOT/BOOTX64.EFI not signed?

/EFI/BOOT/BOOTX64.EFI comes from the user-selected image, that the user copied on their Ventoy boot media, so it is whatever.

If booting a Windows image or a Linux distro that uses Shim, it is signed. If booting a malicious modified image, or a Linux distro that doesn't use Shim, or whatever, it will not be signed.

The problem we are trying to solve, here, is that /EFI/BOOT/BOOTX64.EFI can be either signed or unsigned, because it is dependent on the ISO the user selected (not Ventoy, not anything else) and that, right now, Ventoy lets signed or unsigned through, even if Secure Boot is enabled.

as I can replace BOOTX64.EFI by any bootloader code including an additional malware like UEFI malware.

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 that the ISO provides) and only run the original /EFI/BOOT/BOOTX64.EFI from the ISO if it passed Secure Boot validation. As long as Ventoy runs its own Secure Boot validation bootloader first, you can craft any ISO you want with unsigned bootloaders, and if the Ventoy bootloader does its job, it will not let these through (and you should have a very hard time bypassing the Ventoy bootloader to make your bootloader run, because all Ventoy is designed to do, when it comes to UEFI boot, is pass the UEFI bootloader from an ISO along with the rest of the ISO content, and that's it).

[EricV]

"/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: 1) There are many iso file possible with ventoy and I can select dynamically and add them by just writing in the first partition, 2) When you create the bootable disk, you specify if you want a secure version (-s, -g flags) not the iso you will use and anyway their can be changed afterward, 3) When asked on another bug why /EFI/BOOT/BOOTX64.EFI is not signed I was answered it is the ventoy boot code and it cannot be replaced by a signed version from one iso,

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.

[pbatard]

My view is that the first code executed is ventoy specific bootloader code in /EFI/BOOT/BOOTX64.EFI

Well, the problem is that we are talking about multiple /EFI/BOOT/BOOTX64.EFI.

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 /EFI/BOOT/BOOTX64.EFI resides on the ISO that was selected during the initial GRUB/Ventoy selection screen.

In short, my understanding is as follows (on a system where Secure Boot is enabled):

1. The Ventoy /EFI/BOOT/BOOTX64.EFI is signed, and needs to, because otherwise (well, outside of whitelisting the executable itself through its hash, but then you'd have to do that every time there's a new Ventoy update) it would never pass the Secure Boot validation check.
2. To pass the Secure Boot validation check, the signing certificate for that Ventoy /EFI/BOOT/BOOTX64.EFI bootloader also needs to have been added to the system once, prior to running Ventoy, using Mok Manager.
3. Once you have done that, you can still not run any unsigned /EFI/BOOT/BOOTX64.EFI directly. But you can run any unsigned /EFI/BOOT/BOOTX64.EFI if you shove them onto an ISO, and then select that ISO through Ventoy.

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).

[EricV]

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.

[EricV]

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

[pbatard]

The first code to be run has to be signed with a key that pre-exist in the BIOS .db valid signature database.

Yes. This is standard Secure Boot validation.

There is no way to add key there if you did not create the whole key chain or use existing Microsoft boot keys.

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.

but doing this you may screw up all microsoft keys or Linux keys.

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.

Then the MOK enrollment keys use a different key database that comes in addition to the BIOS .db database.

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...

A clear indication for that is that Ventoy /EFI/BOOT/BOOTX64.EFI is NOT signed with the key present in the ventoy EFI partition.

Well, the first bootloader that resides in /EFI/BOOT/ in the ESP obviously must satisfy the default (non Shim, since Shim hasn't run yet) Secure Boot rules. So, yeah, you wouldn't be able to sign it with anything but a standard Secure Boot credential, which commonly means Microsoft Third Party, rather than something specific like the Ventoy credentials or the ones that Red Hat/Fedora/etc use.

The code BOOTX64.EFI is just derived form the preloader code in the efitool boot code removing some security checks!

If you're talking about the initial /EFI/BOOT/BOOTX64.EFI that is signed by Microsoft, then, no, that bootloader does not have Security Checks removed as this would still be the Shim (or something equivalent that was signed by Microsoft and that would be very quickly revoked by Microsoft if its security was confirmed to be lax).

As you explained above, which is similar to my understanding, the initial /EFI/BOOT/BOOTX64.EFI that is executed from the ESP can only be something that has been validated and signed by Microsoft, and the page you point to very much describes that the bypass to execute any bootloader only works AFTER you used MokManager to enroll a key (in the Shim DB, since Shim will still need to execute first). So that means it has to be Shim or a Microsoft vetted Shim equivalent (but since we're using MokManager, it's gotta be Shim). See https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk#based-on which lists the order in which each component executes.

So my view is that ventoy should use shim that is signed as a loader

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.

bootx64.efi (shim) → grubx64.efi (preloader) → grubx64_real.efi (grub2) → EFI file/OS

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:

bootx64.efi (Shim — Vetted and signed by Microsoft, controlled by Red Hat & co. NOT controlled by Ventoy at all) → whatever.efi (Controlled by Ventoy, signed by Ventoy & enrolled through MokManager in the MOK database so that Shim will run it) → bootx64.efi (from the disc image, that, to fix this issue, should be validated against Secure Boot before execution).

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).

[EricV]

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.

Well looking at description on how to recompile from source (as this is the only way to know what is really done) I found that the patches applied by SuperEfi... are disabling original efitool signature security checks (see readme via link above) and if you look at https://github.com/ventoy/Ventoy/issues/2673 , the fact is that on secure boot enabled computers (one MSI laptop with Linux 12+ and windows 11, on one self build PC based on asrock rand new mother board), in both case, the ventoy USB disk is not even proposed as a bootable device (using bios key to select boot device). It is, ONLY if I disable secure boot.

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

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...

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.

[pbatard]

I found that the patches applied by SuperEfi... are disabling original efitool signature security checks

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.

So my guess is that /EFI/BOOT/BOOTX64.EFI is not correctly signed for recent bios

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.

or BIOS with updated bdx

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 BOOTX64.EFI (which you need to do from PowerShell using the Get-AppLockerFileInformation command, as this is NOT a regular SHA-256 and even the "SHA-256 FLAT" from the list isn't) you will probably find that it is there (there are a few Shim EFI executables that have been revoked, so I suspect you might be using one, though I also expect current Ventoy to use an up to date non-revoked one). However, on most UEFI systems, you should get an explicit message telling you that there is a Security Violation, so, if you don't even see that, I would look into boot order priority or UEFI firmware quirks, since some manufacturers have UEFI firmwares that are not entirely specs compliant...

Other possibility, if your /EFI/BOOT/BOOTX64.EFI is not the Shim, is that you are trying to boot a EFI bootloader that you signed yourself and installed the MOK certificate for, which of course will not work unless it's being chain-loaded through the Shim (so that will not boot if you try to do it directly, even after you enrolled the key, as anything that's MOK signed needs a 2 stage loading).

You will also see that the dev acknowledge the BIOS should accept to boot a non correctly signed first stage boot loader

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 /EFI/BOOT/BOOTX64.EFI that the UEFI firmware runs from the ESP (by the way, the UEFI specs have no constraints on the location of the ESP, or the type of FAT being used, or specific flags, which means that a specs compliant UEFI firmware will readily accept FAT16 without boot flags at the end of the disk as ESP), then the first stage bootloader will never boot if it's not correctly signed with the Microsoft Certificate (or with your own certificate if you replaced the whole trust chain, but I'm assuming that this is not the case). There again, there's no inbetween.

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:

1. If you replaced all the certificates from the Secure Boot trust chain, then, provided that you properly signed your UEFI bootloader, you should be able to boot that directly when Secure Boot is enabled, i.e. single stage bootloading.
2. If you used MOK Manager to add your signing certificate (which does not require replacing the whole certificate trust chain), then you still need to boot the unmodified Shim first and then have Shim boot your signed bootloader, i.e. two stage bootloading.

Somehow, I get a feeling that you've been trying to mix both these options, whereas you really only need to choose one.

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.

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.

[EricV]

Other possibility, if your /EFI/BOOT/BOOTX64.EFI is not the Shim, is that you are trying to boot a EFI bootloader that you signed yourself and installed the MOK certificate for, which of course will not work unless it's being chain-loaded through the Shim (so that will not boot if you try to do it directly, even after you enrolled the key, as anything that's MOK signed needs a 2 stage loading).

extract from https://github.com/ventoy/Ventoy/blob/master/DOC/BuildVentoyFromSource.txt

5.10 UEFIinSecureBoot https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk/releases Super-UEFIinSecureBoot-Disk_minimal_v3.zip unzip it and get Super-UEFIinSecureBoot-Disk_minimal.img, extract the img by 7zip.

INSTALL/EFI/BOOT/BOOTX64.EFI --> EFI/BOOT/BOOTX64.EFI SHA-256: 475552c7476ad45e42344eee8b30d44c264d200ac2468428aa86fc8795fb6e34 INSTALL/EFI/BOOT/grubx64.efi --> EFI/BOOT/grubx64.efi SHA-256: 25d858157349dc52fa70f3cdf5c62fe1e0bae37ddfc3a6b6528af9a3c745775f INSTALL/EFI/BOOT/MokManager.efi --> EFI/BOOT/MokManager.efi SHA-256: 3bf1f46cee0832355c7dd1dba880dea9bcaa78cc44375a1559d43bc9db18933b

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 https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk/issues/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 xzcat ventoy.disk.img.xz > ventoy.disk sudo mount -o loop ventoy.disk /mnt ls /mnt EFI ENROLL_THIS_KEY_IN_MOKMANAGER.cer grub tool ventoy

sbverify --list /mnt/EFI/BOOT/BOOTX64.EFI

warning: data remaining[808656 vs 934024]: gaps between PE/COFF sections? signature 1 image signature issuers:

• /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates:
• subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
• subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root signature 2 image signature issuers:
• /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org image signature certificates:
• subject: /CN=openSUSE Secure Boot Signkey/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org issuer: /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/emailAddress=build@opensuse.org

ls -l /mnt/EFI/BOOT/BOOTX64.EFI -rwxr-xr-x 1 root root 934024 6 oct. 16:35 /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? signature 1 image signature issuers:

• /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates:
• subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
• subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root valette@tri-yann5:~/local/bin/ventoy-1.0.96/ventoy$ ls -l /boot/efi/EFI/debian/shimx64.efi -rwxr-xr-x 1 root root 948768 4 déc. 11:22 /boot/efi/EFI/debian/shimx64.efi

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.

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.

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).

[pbatard]

Well, the Shim used by Super-UEFIinSecureBoot-Disk_minimal_v3-4.zip (i.e. EFI\BOOT\BOOX64.EFI from the .img) is certainly not in the currently revoked list. By the way, its SHA-256 (or what Microsoft calls "PE256 Authenticode" which is what you need to use to check it against the DBX) is 2D78D880AB1B08B8757B5BDD52104AE1FC38421E22B1E7A18D84E3C6000DC305. The regular SHA-256 computed by standard SHA-256 tools will not provide you with a value you can check against the DBX.

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 Super-UEFIinSecureBoot-Disk_minimal_v3-4.zip in a Secure Boot enabled environment with a fully up to date DBX (tested on an Intel NUC).

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.

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...

Or is is because the ventoy efi partition is not normally build

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 EFI\BOOT\BOOX64.EFI on anything that looks like an ESP).

But then, this means they should require everyone to recreate the PK and db, dbx database

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:

methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work

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:

1. There does not actually exists a realistic scenario where Microsoft would have no other alternative but to release their signing keys.
2. There can only have been one reason for Microsoft to peddle their bullshit about GPLv3 potentially forcing them to release their signing key, which is that they wanted to have free reign to produce fully locked down hardware.

[ValdikSS]

This issue is becoming rather chatty, I'm unsubscribing. Please tag me if it's related to my code in https://github.com/ventoy/Ventoy/issues/135#issuecomment-789948929 or https://github.com/ventoy/Ventoy/issues/135#issuecomment-819517941.

[EricV]

@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:

1. Using the last version of rufus with Windows installer iso and does not work when used on my target Samsung T5 SSD disk and my laptop/USB port but works with the same laptop/USB port when using the same rufus/iso combination on a classical Sandisk USB key,
2. Using Debian network installer hybrid iso image via dd on the same T5 disk does not work either. It also works on Sandisk USB key,
3. I cloned the laptop internal NVME EFI partition on the T5 disk and it does not work either,
4. I remember booting an old Samsung Internal SSD disk from an defunct machine with a USB->Sata adapter on the same laptop/USB port and it did work (at least up to fixing some config options because of underlying hardware change). So it is not using "big" SSD disk per se or samsung brand,

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.

[account183892]

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.

[pbatard]

Having Ventoy run non secure boot on secure boot is a clear positive.

"Making the locks of my house ineffective is a clear positive"

Secure boot is not a security feature

"Locks are not a security feature."

While on most computers you can disable it, some specific computers force it to be on.

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

[Wack0]

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").

[pbatard]

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:

1. Taking an ISO that should not boot in a Secure Boot environment (A simple ISO with a UEFI Shell should do, as Shell can never be signed for Secure Boot by policy)
2. Rename the original \efi\boot\bootx64.efi to something else (e.g. \efi\boot\bootx64_original.efi)
3. Craft your own UEFI bootloader that calls on LoadImage() and StartImage() to load the original bootloader (as LoadImage() automatically performs Secure Boot validation when Secure Boot is enabled, and will return an error if validation checks), in a manner a bit similar to what I'm doing in UEFI:NTFS). Oh and it goes without saying that, when Secure Boot is disabled, LoadImage() lets anything through.
4. Sign your own copy of Ventoy and this bootloader and install the relevant keys for Secure Boot
5. Recreate the image with the (signed) \efi\boot\bootx64.efi and original \efi\boot\bootx64_original.efi, then copy it into a Ventoy drive that uses your own signed version and see how it behaves in the Secure Boot environment where you installed your own keys.

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:

1. Crafting a chain loading bootloader similar to the above, that automatically performs Secure Boot validation.
2. Virtually replace any \efi\boot\bootx64.efi from UEFI images with that bootloader, while making the original bootloader available under a different name (since my understanding is that Ventoy has full dynamic control of how it presents the virtual UEFI file system of the image to the image's bootloader).

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.

[pbatard]

Okay, so my idea of trying to access the original LoadImage() doesn't work because there's no easy way to access the address of the call as it was before Shim overrides it with its own versions (and recursing through all the parents of the current loaded image doesn't help as they all appear to use the same Boot Services reference, so the override applies to them all, and you'd have to hack into the actual Shim binary image in memory to locate the original address of LoadImage()).

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 grub.efi/Super UEFIinSecureBoot binary that is invoked by Shim, so, indeed, the place to address the issue is there. And yes, it should require Ventoy modules and the grub_real files to be signed, but quite frankly, if you allow any unsigned executables to run, even if they are located on the Ventoy system partition, then it still leaves major security issues and signing UEFI binaries is really not a big deal (though it means that, in a Secure Boot enabled environment, only modules that have been signed by @ventoy will have the ability to run, which again, is REALLY what you want).

@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 test.vtoy VHD image wanted to load in a Secure Boot enabled environment, whether they were unsigned, signed for formal Secure Boot or using a MOK key that had been enrolled.

All I got was a very brief:

error: cannot load image.
error: you need to load the kernel first.

And of course, the same .vtoy works fine when Secure Boot is disabled.

Still, I believe that the proper way to address the issue is indeed to fix the Super UEFIinSecureBoot binary used by Ventoy so that LoadImage() only lets through EFI binaries that either pass Secure Boot or Shim validation.

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 Only DER encoded certificate (*.cer/der/crt) is supported error, but it you simply rename the file to CERTIFICATE_WITH_SUPER_LONG_FILE_NAME.cer the issue goes away), which I believe is due to rhboot/shim#143 and has to do with using a version that was compiled with an old version of gnu-efi. Not something that is likely to affect regular Ventoy users, but I sure wasted a couple hours trying to figure out why the default Ventoy cert would enroll but not my custom one.

[Werenter]

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:

1. Detect if Secure Boot is enabled

2. If Secure Boot is not enabled, proceed as normal.

3. If Secure Boot is enabled, signature validation of any chain loaded `bootx64.efi` is performed

4. If the signature validation fails (i.e. if the `bootx64.efi` is 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 and `bootx64.efi` should 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.

Secure Boot must die.

[MatejKafka]

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).

[seba2282]

it give the user the right to replace the file even when signed so you end up giving the private keys for signature or infringe the GPLV3,

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.

1. Microsoft would of course not bend over and say "Oh, you're totally right. You got us: here you go" and hand over their signing keys, but instead, they would call on their army of lawyers to challenge the request in a US court.
2. This would lead to a super interesting legal proceeding where, if the "prosecution" (but I am using the word loosely here) lawyers do even a half-assed job, it would become either very apparent that Microsoft could not have logically believed their statement to be factual while simultaneously allowing bootloaders like Shim to be signed, as well as what I would expect statements from the FSF along the lines of "Microsoft appears to have chosen to interpret the terms we added for GPLv3 wrong".
3. Finally, an half awake jury would agree that, rather than Microsoft being forced to hand over their secret key, the GPLv3 legal requirements can be fully satisfied, if needed, as long as the provider of the hardware provides a UEFI update that allows the user to install their own certificate or disable Secure Boot altogether, which, as we have seen above, should NOT occur if a hardware manufacturer does stick to the UEFI specs, but is instead hell bent to add additional rules on its own, in order to restrict what the person who purchased the hardware should have the freedom to do.

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.

3. the concept of trusted boot relies on a trusted chain and root of trust and here even the first non BIOS element is untrusted, so signing anything after that is useless from a pure security point of view.

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.

I think maybe you will make Rufus for can let's much iso's on one pendrive? How Ventoy let's. When I putted topic about multi boot, you faster closed "how you will not". Multi boot is future. And about. In uefi i have secure boot "other system" not only Microsoft. And I think that is way to don't block some Linuxes on secure boot or I don't know. But fact. When Rufus finally let's on multi boot?

[pbatard]

@seba2282, please don't add off-topic comments about unrelated software to an already overly long thread. And since you also posted about this in the Rufus issue tracker, please see my answer there. As I have stated repeatedly, I'm fairly happy that Ventoy can take care of the multiboot "market", and I have no plan to have Rufus become some kind of "clone" of Ventoy in terms of its ability to copy ISO wholesale (which IMO is the actual killer feature of Ventoy, rather than multiboot) or multiboot. Outside of the Secure Boot issue, I think that Ventoy does it's job very well, and I genuinely feel no need to try to compete with it in Rufus because I think both our approaches have pros and cons, and I'd rather let users choose the one they feel is best for them. Also, I have no idea why you felt the need to quote a super long answer that has nothing to do with what you want to talk about.

I would suggest to @ventoy to delete both this reply and @seba2282's post, since they are 100% off topic and irrelevant, and this thread is already way longer than it should.

[account183892]

Pluton is going to be forcing Restricted Boot on a ton of PCs