Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[issue]: Update to latest Shim (Verifying shim SBAT data failed) #2947

Open
1 task done
z0rgster opened this issue Aug 15, 2024 · 44 comments
Open
1 task done

[issue]: Update to latest Shim (Verifying shim SBAT data failed) #2947

z0rgster opened this issue Aug 15, 2024 · 44 comments

Comments

@z0rgster
Copy link

z0rgster commented Aug 15, 2024 •
edited
Loading

Official FAQ

  • I have checked the official FAQ.

Ventoy Version

1.0.99

What about latest release

Yes. I have tried the latest release, but the bug still exist.

Try alternative boot mode

Yes. I have tried them, but the bug still exist.

BIOS Mode

UEFI Mode

Partition Style

GPT

Disk Capacity

200GB

Disk Manufacturer

Framework

Image file checksum (if applicable)

None

Image file download link (if applicable)

No response

What happened?

As far as I understand this topic, the latest Windows Update from August 13, 2024 did some changes to some UEFI tables so that there were signatures of vulnerable Shims blacklisted. Therefore, booting Ventoy now fails with the message

Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation

This topic was already discussed for a supposedly earlier Shim version in #2692 which is still open for some reason.
The recent issue was posted on forums here and here

As a temporary workaround, secure boot must be disabled until there is an updated version of ventoy with the latest Shim version available.

Edit:
As pointed out by KevinLenoir, the target OS for SecureBoot can be changed from "Windows" to "Other OS" on Machines which support this feature. This way, Secure Boot might not have to be disabled completely.

More Information on how Shim works can be found on Arch Wiki. More info on the topic of SBAT revocation lists can be found in the rhboot/shim repository here and here
@ArielHeleneto
Copy link

I found same problem on my mom's PC with Windows 11

@OwenD30
Copy link

OwenD30 commented Aug 17, 2024

Same here

@samdh90
Copy link

samdh90 commented Aug 17, 2024

Same issue here. Seemed to have occurred randomly, it worked one week but failed the next. I have also tried formatting the USB and reinstalling Ventoy 1.0.99 again, no dice. Only thing that works is disabling secure boot. Restoring platform keys and bios CMOS resets do not seem to help.

Running a b550 AM4 motherboard from MSI, with AGESA ComboAm4v2PI 1.2.0.C

@nemya9066
Copy link

Same here problem started when I added the fedora ISO to my usb.

@travino
Copy link

travino commented Aug 18, 2024 •
edited
Loading

I think it has something to do with recent sb-related updates to Windows?
https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d

Yep.

[Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.

https://support.microsoft.com/en-us/topic/august-13-2024-kb5041571-os-build-26100-1457-d218c08d-8de2-4f9a-8fe1-a2c2fd83ca9a

@TechySkills
Copy link

So uh... we hope that Ventoy team gives an update 2.0.0?? with also giving a fix to the 1.9.9 error?
#2902

@majidfer
Copy link

same here

@digital-spinner
Copy link

same issue here :(

@nxjosephofficial
Copy link

same here

@1aladdin1
Copy link

afaik the issue we are observing is related to BOOTX64.EFI from the hidden VTOYEFI partition

@LukyKrob
Copy link

Same issue on Yoga 7

@punktiktok
Copy link

I turned secure boot off and it fixes everything but still there is a security problem if we leave it disable

@TechySkills
Copy link

TechySkills commented Aug 22, 2024 via email

@leonsk29
Copy link

Same here.

@Snoodking
Copy link

Issue is with secure boot patch issued by Microsoft. Need Ventoy update to correct the issue. Works if you disable secure boot, but negates using Ventoy for Windows 11 installs, unless you employ the system requirements bypass hack.

@KevinLenoir
Copy link

Hey ! Just found out that we might not need to disable the secure boot. In the bios, there was a setting about "Secure boot OS", which was either "Windows" or "Other OS". Turning this option to "Other OS" worked for me

@Snoodking
Copy link

Snoodking commented Aug 23, 2024 via email

@don-dolarson
Copy link

don-dolarson commented Aug 24, 2024 •
edited
Loading

Is this really a problem created by Microsoft?
I've installed Linux Mint 22 on my laptop (UEFI with Secure Boot enabled) a couple of days ago and there wasn't a single problem. I decided to reinstall the very same Mint today (again) using the same Ventoy stick with 1.0.96 on it and suddenly there is a shim problem this time. I haven't had anything with Microsoft to do. Wasn't even connected to the internet on this machine in like a half the year...

@don-dolarson
Copy link

don-dolarson commented Aug 24, 2024 •
edited
Loading

Just updated Ventoy to the latest 1.0.99 on another Linux machine, booted Ventoy without the shim error, booted the very same Mint 22 live image on it.

Double checked with sudo mokutil --sb-state and indeed SecureBoot is enabled.

Don't know what's going on. The machine is a MSI laptop from 2013.

@samdh90
Copy link

samdh90 commented Aug 24, 2024 •
edited
Loading

Just updated Ventoy to the latest 1.0.99 on another Linux machine, booted Ventoy without the shim error, booted the very same Mint 22 live image on it.

Double checked with sudo mokutil --sb-state and indeed SecureBoot is enabled.

Don't know what's going on. The machine is a MSI laptop from 2013.

It seems to be specifically affecting Windows 11 users. Looks like Microsoft released a SHIM revocation update this month that caused the issues. If your PC was not running Windows 11, you wouldn't have received the revocation update. I don't believe this affected existing systems running Windows 10 either.

@don-dolarson
Copy link

The machine hasn't seen Windows in years but still I could see the same shim error described in this topic when tried to reinstall from Mint 22 to Mint 22 today using the same stick for both installations, hence why I'm here. It wasn't a problem for 3 days ago when I put that stick into the laptop and installed Mint 22 for the first time but today, I couldn't load Ventoy boot screen and the laptop shutdown after 3 seconds with the shim error before that. Updating the stick and Ventoy on it to the latest solved the problem for me but I was surprised that you blame Microsoft for this when the machine wasn't even been connected to the internet in more than 6 months. The last BIOS/UEFI update was done someday in 2015.

Strange situation.

@deveshl
Copy link

deveshl commented Aug 25, 2024

Just updated Ventoy to the latest 1.0.99 on another Linux machine, booted Ventoy without the shim error, booted the very same Mint 22 live image on it.
Double checked with sudo mokutil --sb-state and indeed SecureBoot is enabled.
Don't know what's going on. The machine is a MSI laptop from 2013.

It seems to be specifically affecting Windows 11 users. Looks like Microsoft released a SHIM revocation update this month that caused the issues. If your PC was not running Windows 11, you wouldn't have received the revocation update. I don't believe this affected existing systems running Windows 10 either.

Nope. Windows 10 user, this problem prevented my Ventoy USB from being booted on my PC. It worked fine on my Windows 11 laptop, but that's probably because it hasn't been turned on in a bit so didn't get the revoked SBAT update...

@digital-spinner
Copy link

It looks like Microsoft is playing a god role. I'm sick of this... When I find a good Linux distro with TPM-LUKS capabilities and XRDP OOBE i'm going away from this nonsense.

@TechySkills
Copy link

TechySkills commented Aug 25, 2024 via email

@1aladdin1
Copy link

obviously secure-boot signature verification complains about the shim binary used by Ventoy.
question: how can we find out which shim version is used by Ventoy 1.0.99 ?

@kastentop2005
Copy link

ASUS TUF F17 is hit by this issue as well

@htcfreek
Copy link

obviously secure-boot signature verification complains about the shim binary used by Ventoy. question: how can we find out which shim version is used by Ventoy 1.0.99 ?

  1. According to the folder structure of this repo the Grub2 version is 2.04: GRUB2/MOD_SRC/grub-2.04
  2. According to MS they blocked all Grub2 versions affected by CVE-2022-2601. And the CVE says that all Grub2 version lower or equal to version 2.06 are affected.
  3. So I think the devs needs to update the Grub2 to a version newer than version 2.06.

@htcfreek htcfreek mentioned this issue Aug 26, 2024
Open
1 task
@postmaxin
Copy link

So I think the devs needs to update the Grub2 to a version newer than version 2.06.

I took a quick look and it's not likely to be as simple as just dropping a new version in: the devs have also patched bits of grub-2.04 to suit Ventoy's needs -- lots of little changes.

@SagePtr
Copy link

SagePtr commented Aug 26, 2024 •
edited
Loading

  1. According to the folder structure of this repo the Grub2 version is 2.04: GRUB2/MOD_SRC/grub-2.04
  2. According to MS they blocked all Grub2 versions affected by CVE-2022-2601. And the CVE says that all Grub2 version lower or equal to version 2.06 are affected.
  3. So I think the devs needs to update the Grub2 to a version newer than version 2.06.

Does this matter if grub is signed by MOK? According to my investigations, they blocked shim by SBAT policy, not grub. And if I replace shim with one which cames from Fedora (see comments in this issue: #2692) - it passes the check despite of old grub. This can be fixed quickly by replacing few signed files.

@htcfreek
Copy link

  1. According to the folder structure of this repo the Grub2 version is 2.04: GRUB2/MOD_SRC/grub-2.04
  2. According to MS they blocked all Grub2 versions affected by CVE-2022-2601. And the CVE says that all Grub2 version lower or equal to version 2.06 are affected.
  3. So I think the devs needs to update the Grub2 to a version newer than version 2.06.

Does this matter if grub is signed by MOK? According to my investigations, they blocked shim by SBAT policy, not grub. And if I replace shim with one which cames from Fedora (see comments in this issue: #2692) - it passes the check despite of old grub. This can be fixed quickly by replacing few signed files.

I don't know. Thought they blocked grub as bootloader in specific versions.

@cvb011
Copy link

cvb011 commented Aug 28, 2024

There is a way to reset Microsoft's new sbat policy to default (I'm currently using this way).

  1. Add this reg key to prevent Windows add flawed sbat policy: reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD
    According to this post, it should fix the problem. If not, go forward.
  2. Disable Secure Boot then boot to RU (A CMOS edit toolkit)
  3. Press Alt + = and set all SbatLevelRT & SbatLevel data to 00
  4. Reboot and enable Secure Boot, the sbat policy will reset to system default

@WilsonHuangDev
Copy link

WilsonHuangDev commented Aug 29, 2024 •
edited
Loading

According to Microsoft's article, it has something to do with recent security updates to Windows.

https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23H2#3377msgdesc
image

@TechySkills
Copy link

TechySkills commented Aug 29, 2024 via email

@TechySkills
Copy link

TechySkills commented Sep 1, 2024 via email

@RENANZG
Copy link

RENANZG commented Sep 6, 2024 •
edited
Loading

Incredible, Microsoft managed to fuck up my Linux system inside a virtual machine...

https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/

meme_sbat_strike

@digital-spinner
Copy link

You should be able to reset SECURE BOOT configuration in UEFI. At the end you can also disable SECURE BOOT and just use linux as intended. I don't understand how that happen from the inside of the VM guest if this is what you are saying.

@RENANZG
Copy link

RENANZG commented Sep 6, 2024 •
edited
Loading

You should be able to reset SECURE BOOT configuration in UEFI. At the end you can also disable SECURE BOOT and just use linux as intended. I don't understand how that happen from the inside of the VM guest if this is what you are saying.

The update of Windows 10 in a VM running in a UEFI environment with Secure Boot enabled may have altered Shim or boot-related binaries, which should not directly affect the Linux host. However, if there is any state sharing between the VM and the host, this could have caused inconsistencies in the physical machine's Secure Boot. Furthermore, if the Linux host uses Secure Boot and relies on binaries like Shim, the VM update may have caused incompatibilities with SBAT or the binary signatures on the host. 🐣 🙄

https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/

How I Solved my case:

  1. Disable Secure Boot in the BIOS
  2. Boot your Linux System
  3. Go to Terminal
  4. Commands:

sudo apt update
sudo apt install --reinstall shim-signed grub-efi

*If not working, also try:

sudo mokutil –list-sbat-revocations
sudo mokutil –set-sbat-policy delete
sudo mokutil –list-sbat-revocations

To fix the virtual network of the virtualization ("Nertwork 'default' is not active"):

sudo virsh net-list -all
sudoo virsh net-start default

@omidshojaee
Copy link

Same here.
OEM pc (HP EliteDesk)
Secure boot is disabled in BIOS.

@etim808
Copy link

etim808 commented Sep 15, 2024

i am experiencing this issue as well on an MSI intel, 14th generation board.

@g1ngernator
Copy link

Same issue, I use my ventoy on constantly different devices so workarounds aren't really helpful.

@nsi-test
Copy link

The answer of RENANZG is really helpful! Here is how I do the similar thing. I disable secure boot, I boot from a live linux desktop (Ubuntu 24.04 in my case), I opened a terminal and typed (see his answer):

sudo mokutil –list-sbat-revocations
sudo mokutil –set-sbat-policy delete
sudo mokutil –list-sbat-revocations

The first and the last line are informative and they don't change. Then I do reboot and I REENABLE secure boot. After restart Ventoy is working on that machine.

May be

sudo apt update
sudo apt install --reinstall shim-signed grub-efi

would help too, but I don't have a computer for now to test.
Thank you RENANZG!

@SagePtr
Copy link

SagePtr commented Sep 18, 2024 •
edited
Loading

Same issue, I use my ventoy on constantly different devices so workarounds aren't really helpful.

If you use single/few Ventoy USB dongle(s) on many different PCs, it's much better to upgrade Shim on Ventoy partition itself to solve the issue for your Ventoy instance, rather than do workaround on each target machine: #2692 (comment)

@aflyhorse
Copy link

same here. update the embedded grub plz.

@nsi-test
Copy link

Same issue, I use my ventoy on constantly different devices so workarounds aren't really helpful.

If you use single/few Ventoy USB dongle(s) on many different PCs, it's much better to upgrade Shim on Ventoy partition itself to solve the issue for your Ventoy instance, rather than do workaround on each target machine: #2692 (comment)

Thank you very much @SagePtr, I found a "clean" computer to test. Your advice really works! With a "patched" Ventoy flash drive, it behaves as in normal situation. Thanks also to the original source - @onenowy . I highly recommend this variant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests