Linux and Secure Boot certificate expiration : linux@programming.dev

Linux and Secure Boot certificate expiration (lwn.net)

submitted 1 year ago by cm0002@programming.dev to c/linux@programming.dev

20 comments fedilink hide all child comments

Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage UEFI bootloader that is used by Linux distributions to boot the kernel with Secure Boot. But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen. It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.

[–] rivalary@lemmy.ca 13 points 1 year ago

What people in the comments here expect the average person to know about and do is pretty out of touch with reality.

permalink

fedilink

source

[+] 9tr6gyp3@lemmy.world -33 points 1 year ago* (18 children)

I know Ill get flak for this, but you shouldn't be using end-of-life hardware, including motherboards. Once the vendor stops providing firmware updates, its time to look at replacing that hardware. It doesn't matter what operating system you use, if there are hardware vulnerabilities, then your OS isn't able to properly protect you.

If your hardware is still supported, you should regularly be updating the firmware.

permalink

fedilink

source

hideshow 18 child comments

[+] bacon_pdp@lemmy.world 25 points 1 year ago (4 children)

[deleted]

permalink

fedilink

source

parent

hideshow 4 child comments

[–] 9tr6gyp3@lemmy.world -1 points 1 year ago (3 children)

As much as I would like to agree with that, each piece of hardware is going to have its own niche set of problems that the coreboot/libreboot team is not going to research and maintain. It wont be because they dont want to. They just dont have the resources and source code from the vendors. You will get your standardized updates, but it will not cover a lot of the proprietary blobs necessary for the hardware to operate.

Once the vendor stops supporting it, thats it. Its a ticking time bomb. Its how we get articles like the one in the OP. The vendor and user are not going to put in work to keep this updated. Even if they had coreboot/libreboot, it wont get updated.

Its a shitty thing that isn't easy to solve except by tying in hardware and software into single, unified products that are written in perfect code. Its not possible.

permalink

fedilink

source

parent

hideshow 3 child comments

[+] bacon_pdp@lemmy.world 6 points 1 year ago (3 children)

[deleted]

permalink

fedilink

source

parent

hideshow 3 child comments

[–] 9tr6gyp3@lemmy.world 1 point 1 year ago* (2 children)

Generally, motherboard manufacturers source their components from other companies. They do not manufacture the entire board themselves. This includes CPUs, Wifi cards, USB controllers, bluetooth, audio, display controllers, etc. Each and every one of them create new products, maintain their own firmware for all those new products, and push updates to the motherboard manufacturers when there are updates.

Coreboot/libreboot do not update those components themselves. They also must be provided that source code.

Just for coreboot alone, the last release had more than 120 contributors push over 900 commits. One person is not able to maintain that piece of software, as it is an enormous task.

permalink

fedilink

source

parent

hideshow 2 child comments

[+] bacon_pdp@lemmy.world 3 points 1 year ago (2 children)

[deleted]

permalink

fedilink

source

parent

hideshow 2 child comments

[–] 9tr6gyp3@lemmy.world 0 points 1 year ago (1 child)

Even if the code is there, you will need someone to maintain that code. Easier or not, even in a git repository, those individual components will eventually not have the support necessary to patch it.

If an eight year old usb controller has flaws, and the manufacturer is not maintaining that git repository anymore because they cannot possibly afford to hire someone to look at that code after so long, then it is going to keep those flaws. It wont matter if that code is proprietary or open source and included in coreboot. Its just simply not feasible to support hardware properly once most of the world has moved on to other products.

permalink

fedilink

source

parent

hideshow 1 child comment

[+] bacon_pdp@lemmy.world 0 points 1 year ago (1 child)

[deleted]

permalink

fedilink

source

parent

hideshow 1 child comment

[–] 9tr6gyp3@lemmy.world 1 point 1 year ago

I wish all the firmware for every motherboard was made public and open sourced. Even if a company has proprietary firmware/drivers, I would hope that once that product reaches end of life that they do in fact open source that code so that someone else can pick up where they left off.

I 100% agree that they should not brick their hardware once it reaches end of life. There might be someone out there who would take on the task of maintaining it, which is better than nobody maintaining it.

permalink

fedilink

source

parent

load more comments (-1 replies)

[–] Infernal_pizza@lemmy.dbzer0.com 8 points 1 year ago (2 children)

Are there any hardware manufacturers that aren't completely shit at providing firmware updates? My motherboard does still get updates but they can take a while to arrive even when there's a known exploit for my CPU which requires a firmware update to fix (made even worse by the fact that AMD are awful at providing fixes in the first place)

permalink

fedilink

source

parent

hideshow 2 child comments

[–] SheeEttin@lemmy.zip 1 point 1 year ago

Only the really big names like Intel, Dell, HP... but even then they'll still go out of support eventually.

permalink

fedilink

source

parent

[–] 9tr6gyp3@lemmy.world 0 points 1 year ago

AMD are generally quick with providing microcode updates. Once they have them, they provide them to your motherboard manufacturer to include in a firmware update. This is the part that usually takes a while, if done at all.

permalink

fedilink

source

parent

[–] VeganCheesecake@lemmy.blahaj.zone 7 points 1 year ago (5 children)

This implies a world in which motherboard vendors actually regularly publish updates for their boards, or publish information about a board being officially end-of-life, which, for many consumer boards, just isn't the case.

Some vendors still have a red flag on their support page discouraging uefi updates unless you're actively experiencing problems.

permalink

fedilink

source

parent

hideshow 5 child comments

[–] 9tr6gyp3@lemmy.world -1 points 1 year ago* (last edited 1 year ago) (4 children)

Some vendors still have a red flag on their support page discouraging uefi updates unless you're actively experiencing problems.

I dont know which vendor you are referring to, but that is a horrible practice. There should be active support and release notes stating that "This release is a security fix" at a bare minimum. If your motherboard manufacturer does not offer that, then I could never recommend them to someone. They need to be held to a higher standard.

At least from my experience, ASUS, Dell, and Apple will publish that information.

permalink

fedilink

source

parent

hideshow 4 child comments

[–] VeganCheesecake@lemmy.blahaj.zone 1 point 1 year ago* (last edited 1 year ago)

I'm pretty sure that warning used to be on the UEFI download page for Biostar boards, but they've completely redesigned it, so if it was them, it isn't there anymore.

I've seen some Asus and MSI Boards getting only uefi updates marked as beta, with the next update, months later, also being marked as beta. With Asus, there have been allegation that they try to get out of warranty claims this way.

I've had less problems with Dell and Lenovo, which probably comes from them being more enterprise focused. I think the problem is that the for the average consumer, uefi updates are last on their mind when picking a board.

Apple, and, to a lesser degree, Lenovo and Dell, seem hardly comparable, since their focus isn't selling mainboards as a stand-alone component.

permalink

fedilink

source

parent

[–] SkavarSharraddas@gehirneimer.de 1 point 1 year ago (2 children)

From https://www.gigabyte.com/Motherboard/GA-AX370M-Gaming-3-rev-1x/support#support-dl-bios (manual contains the same, plus a recommendation to keep the default settings):

" Warning: Because BIOS flashing is potentially risky, if you do not encounter problems using the current version of BIOS, it is recommended that you not flash the BIOS. To flash the BIOS, do it with caution. Inadequate BIOS flashing may result in system malfunction."

permalink

fedilink

source

parent

hideshow 2 child comments

[–] 9tr6gyp3@lemmy.world 0 points 1 year ago (1 child)

Its funny because the release notes for their December '21 BIOS update says:

Major vulnerabilities updates, customers are strongly encouraged to update to this release at the earliest.

And many of their release notes say that they fix security issues. I would say that supercedes the footnote at the bottom that says to update your BIOS only if you're having issues.

Plus, doesn't Gigabyte have A/B BIOS updates? So if you have a failed flash, you can switch to the previous BIOS that was working?

permalink

fedilink

source

parent

hideshow 1 child comment

[–] SkavarSharraddas@gehirneimer.de 1 point 1 year ago

Most of the recent(ish) updates are vulnerability fixes (after all, the platform is over eight years old now), and they've removed various intermediate versions already or there'd be even more.

This board has a dual BIOS, the integrated flashing utility by default only flashes the main BIOS, and you have to enable the option to flash the backup explicitly. Never had to use the backup, afaik it activates automatically if booting the main BIOS fails several times.

My ASUS "only" has a recovery function (flash BIOS from USB stick automatically if bootup fails) and no warning that I could find.

permalink

fedilink

source

parent

[–] victorz@lemmy.world 2 points 1 year ago (4 children)

What would you recommend as a schedule for "regularly"?

permalink

fedilink

source

parent

hideshow 4 child comments

[–] 9tr6gyp3@lemmy.world -2 points 1 year ago* (last edited 1 year ago) (3 children)

IMO, keep an rss feed of your vendors firmware updates being released on their website or periodically check it yourself. As soon as its released, go ahead and install it. If you want to be cautious, maybe give it a week or two to make sure they dont pull the update due to issues with that particular release.

Even better, if the manufacturer offers a utility to keep updates installed, just run that periodically.

permalink

fedilink

source

parent

hideshow 3 child comments