MSI accidentally broke Secure Boot

L

Lakados

[H]F Junkie
Joined
Feb 3, 2014
Messages
10,387
https://www.bleepingcomputer.com/ne...aks-secure-boot-for-hundreds-of-motherboards/
Bios version 7C02V3C turns off secure boot and breaks the flags that would otherwise prevent a system built with secure boot enabled from booting by defaulting Allow Booting on Security Violations and Image Execution Policy to Always Execute.
290 models are included in this update, full list here: https://github.com/Foxboron/sbctl/issues/181

Got a message from the guys at Bleeping Computer.

Update to incorrect info in one of your posts

Hey Hardforum editors/mods,

I am the owner of BleepingComputer and just wanted to give you a heads up that we had wrong info in our story that should be corrected here:

https://hardforum.com/threads/msi-accidentally-broke-secure-boot.2024924/

Turns out the issue was introduced in some firmware in September 2021, not with "7C02v3C released on January 18, 2022."

We updated our story and saw that you had the incorrect info. Just wanted to give a friendly heads up.
 
Last edited by a moderator:
Zarathustra[H] said:
Does anyone actually want secureboot?

It just seems like it causes more problems than it solves.
Click to expand...
I couldn't go without it not anymore at least, is shuts down so many attack methods.
For the home user who barely knows how to turn on their machine and panics on every popup with more than one button to click, it's probably doing them a favor.
 
Lakados said:
I couldn't go without it not anymore at least, is shuts down so many attack methods.
For the home user who barely knows how to turn on their machine and panics on every popup with more than one button to click, it's probably doing them a favor.
Click to expand...
Ehhh - I feel like there are more CVEs and showstopper issues filed against secureboot and it’s related tooling than it mitigates or actually prevents. The primary purpose and main goal of secureboot is still that you the user cede control of your hardware to someone else in the name of sEcUrItY. What we’re actually securing against is always hidden or obscured behind silly-named “vulnerability” disclosures and papers by researchers pressured to publish.

Disclaimer: I previously did professional work in OS hardening and actually contributed to parts of the architecture and implementation of secureboot for a certain arch.
 
Lakados said:
I couldn't go without it not anymore at least, is shuts down so many attack methods.
For the home user who barely knows how to turn on their machine and panics on every popup with more than one button to click, it's probably doing them a favor.
Click to expand...

Meh.

"Secure Boot" prevents the boot loader on a motherboard from loading unsigned boot code. That's all it does.

It presumes you are somehow exposed to malware that does something to the bootloader, but doesn't have the ability to attack the OS itself.

I'm not a security researcher, but I can't think of a single attack vector where an attacker could write to your boot loader, but not just easily make changes to the OS itself that accomplishes everything they want to do.

To me it seems like a solution in search of a problem, and once that causes lots of headaches at that, including - in many cases - limiting or preventing end users from using their hardware the way they want to.

I'm not a fan.

Heck, if it weren't for the fact that it is needed in order to boot from NVMe drives, I'd go back to a pre-EFI world in it's entirety. It's just needless complication that causes headaches.
 
Not being antagonistic, genuinely curious why EFI is problematic?
 
EFI is fine. SecureBoot we use on all hosts at work as one of the security requirements. (One of like 500 things on a checklist).

Where a 'secured system' gets touchy is when its encrypted boot disks with bitlocker. You have to remember to "pause" it while making any changes that affect the boot disk, or when changing motherboards.
 
OutOfPhase said:
Not being antagonistic, genuinely curious why EFI is problematic?
Click to expand...

It's just overly complicated, requiring a separate partition on the drive with information on it to support booting. it can get messed up if you start installing multiple operating systems, or overwriting previous installs. Converting to and from it can also be a nuisance.

The old MBT based system was much easier, and just worked.
 
Lakados said:
I couldn't go without it not anymore at least, is shuts down so many attack methods.
Click to expand...

It really doesn't. It's just Microsoft controlling what you can and can't do on an x86 machine with SB, since they do the key signing.

Intel Management Engine and AMD's PSP have unrestricted bare metal access to every single piece of hardware in the system, and both are obfuscated black boxes. Both have also been exploited, which makes Secure Boot a waste of time.

You can't secure a system that has a complete system within it that can't be audited and is always running.
 
Lakados said:
https://www.bleepingcomputer.com/ne...aks-secure-boot-for-hundreds-of-motherboards/
Bios version 7C02V3C turns off secure boot and breaks the flags that would otherwise prevent a system built with secure boot enabled from booting by defaulting Allow Booting on Security Violations and Image Execution Policy to Always Execute.
290 models are included in this update, full list here: https://github.com/Foxboron/sbctl/issues/181
Click to expand...

looks like my MSI MAG X570 Tomahawk board is not on the list....what's going on with MSI lately- didn't they have issues with a recent BIOS, MSI Afterburner issues and now this
 
This is funny given that the latest MSI firmwares turn on secure boot by default, which causes problems with some older graphics cards (and without a screen you can't turn the option off). So they caused problems without adding any security.
 
Luke M said:
This is funny given that the latest MSI firmwares turn on secure boot by default, which causes problems with some older graphics cards (and without a screen you can't turn the option off). So they caused problems without adding any security.
Click to expand...

HP is also guilty of this. They're also guilty of having a TERRIBLE verification system, where you have to reboot and type in some random number to "confirm" you want to disable SB. But the problem is that verification system is broken on some machines, and you can't input any numbers, and therefore can't disable SB at all.

Some HP laptops also have a 32 bit UEFI and can't install 64 bit OSes in secure boot OR even UEFI mode LOL.
 
polonyc2 said:
looks like my MSI MAG X570 Tomahawk board is not on the list....what's going on with MSI lately- didn't they have issues with a recent BIOS, MSI Afterburner issues and now this
Click to expand...
Can't confirm that this is the issue you're referring to, but I have read that the dev (yeah I'm curious why it is just one guy too lol) for Afterburner is in Ukraine, and he can't get paid because the contract is affected by the war:

https://www.tomshardware.com/news/msi-afterburner-ukraine-war-complications
I'm can't imagine trying to make a living that way while getting bombed out. Really hope MSI does what they can for him - their statement didn't sound like it included him as much as the software in mind. Of course....there's only so much they can do too...
 
Zarathustra[H] said:
It's just overly complicated, requiring a separate partition on the drive with information on it to support booting.
Click to expand...
It requires all of 100MB to store the boot table.
Zarathustra[H] said:
it can get messed up if you start installing multiple operating systems, or overwriting previous installs.
Click to expand...
Can you provide examples? I always format my drive when I reinstall an OS. I multi-booted Windows 7 and Windows 10 off the same GPT-partitioned drive for a couple years without issues. I eventually decided to reclaim the space from Windows 7 since I wasn't using it anymore and still never had an issue after deleting that partition.
Zarathustra[H] said:
Converting to and from it can also be a nuisance.
Click to expand...
I never converted back to MBR, but the process to convert to GPT is seamless and takes seconds.
Zarathustra[H] said:
The old MBT based system was much easier, and just worked.
Click to expand...
GPT is just as easy and also "just works." If you want to use a drive bigger than 2TB then it has to be GPT.
 
Got a message from the guys at Bleeping Computer.

Update to incorrect info in one of your posts

Hey Hardforum editors/mods,

I am the owner of BleepingComputer and just wanted to give you a heads up that we had wrong info in our story that should be corrected here:

https://hardforum.com/threads/msi-accidentally-broke-secure-boot.2024924/

Turns out the issue was introduced in some firmware in September 2021, not with "7C02v3C released on January 18, 2022."

We updated our story and saw that you had the incorrect info. Just wanted to give a friendly heads up.
 
Armenius said:
It requires all of 100MB to store the boot table.

Can you provide examples? I always format my drive when I reinstall an OS. I multi-booted Windows 7 and Windows 10 off the same GPT-partitioned drive for a couple years without issues. I eventually decided to reclaim the space from Windows 7 since I wasn't using it anymore and still never had an issue after deleting that partition.

I never converted back to MBR, but the process to convert to GPT is seamless and takes seconds.

GPT is just as easy and also "just works." If you want to use a drive bigger than 2TB then it has to be GPT.
Click to expand...

You are mixing up GPT and EFI.

I have no problems with GPT. It is EFI I find bothersome.
 
Zarathustra[H] said:
You are mixing up GPT and EFI.
I have no problems with GPT. It is EFI I find bothersome.
Click to expand...
Yup. And while I can see some use cases, personally I do not have any boot volumes / devices that are larger than 2TB,
so BIOS/CMS + MBR boot is just dandy.
 
WhoBeDaPlaya said:
Yup. And while I can see some use cases, personally I do not have any boot volumes / devices that are larger than 2TB,
so BIOS/CMS + MBR boot is just dandy.
Click to expand...

Same, except BIOS/MBR does not boot from NVMe drives to my knowledge.

(With the possible exception of first gen NVMe drives, some of which actually had boot roms. My old Intel SSD750 in my testbench is like that)

Because of this I find myself forced to use EFI. Otherwise I never would. It just causes more problems than it is worth.
 
Absolutely correct, forgot about NVMe.
Then again, with the stacks of 120-240GB SATA SSDs I have, I just use one of those as the boot device/volume
 
Zarathustra[H] said:
You are mixing up GPT and EFI.

I have no problems with GPT. It is EFI I find bothersome.
Click to expand...
Still begs the question what exactly you have an issue with. I haven't used legacy boot mode or mixed boot in a decade at this point.
 
Zarathustra[H] said:
I'm referring to EFI in that sentence.
Click to expand...

Zarathustra[H] said:
It's just overly complicated, requiring a separate partition on the drive with information on it to support booting. it can get messed up if you start installing multiple operating systems, or overwriting previous installs. Converting to and from it can also be a nuisance.

The old MBT based system was much easier, and just worked.
Click to expand...
EFI is amazing you dirty heathen. And heck, every OS outside of OpenBSD auto-detects the EFI configuration and mounts the volumes the right way for multi-boot anyway.

First time you need to do low-level firmware updates and don't have to build a DOS Boot USB or floppy... or a Linux LiveCD... OMG yes. Just slap the file and utility on a FAT32/ExFAT USB drive, go to EFI shell, and run the updater. Especially powerful in the enterprise for things like SAS controllers and the like. :D So much power there, if you need it, or can make use of it. And no OS compatibility required - the EFI system is a defined RFC so it works on ANY system, anywhere.

Heck, I scripted firmware updates for 50 hosts and it took me no more time than the reboots. Plug USB drive in to first node, hit go - boots to EFI shell, run command, reboot - plug drive into next host and wait for it to drop to EFI shell, repeat. Vs booting to something ... yeah no.
 
lopoetve said:
EFI is amazing you dirty heathen. And heck, every OS outside of OpenBSD auto-detects the EFI configuration and mounts the volumes the right way for multi-boot anyway.

First time you need to do low-level firmware updates and don't have to build a DOS Boot USB or floppy... or a Linux LiveCD... OMG yes. Just slap the file and utility on a FAT32/ExFAT USB drive, go to EFI shell, and run the updater. Especially powerful in the enterprise for things like SAS controllers and the like. :D So much power there, if you need it, or can make use of it. And no OS compatibility required - the EFI system is a defined RFC so it works on ANY system, anywhere.

Heck, I scripted firmware updates for 50 hosts and it took me no more time than the reboots. Plug USB drive in to first node, hit go - boots to EFI shell, run command, reboot - plug drive into next host and wait for it to drop to EFI shell, repeat. Vs booting to something ... yeah no.
Click to expand...
Being able to edit option rom settings (like NIC, HBA, RAID cards) without having to hit multiple hotkeys and reboot in between is such a time saver plus you can script it if you really want to deploy a lot of machines.

For enthusiasts and gamers using CSM means no resizable bar so you're losing free FPS.

Luke M said:
This is funny given that the latest MSI firmwares turn on secure boot by default, which causes problems with some older graphics cards (and without a screen you can't turn the option off). So they caused problems without adding any security.
Click to expand...
This was a microsoft thing, if you notice all vendors released a bios to enable it by default as the only change.
 
You must log in or register to reply here.
Back
Top