I understand their caution. They can't test on all the millions of combinations of PC hardware out there, and some of them are inevitably going to have their boot records toasted by this update, bricking the machines.
If MSFT were acting carefully to avoid bugs, they wouldn't be abolishing the QA department and replacing it with Windows Insiders and Telemetry and Virtualization, and they wouldn't be releasing a bug every time they release a monthly patch.
Isn't it stupid that when MSFT sold Windows 11, they urged people to buy PCs with TPM 2.0 for improved security, but Windows 11 has vulnerabilities that cannot be easily addressed?
It's sad, because they did some cool things with SecureBoot on X64: you can install your own keys and sign your Linux payloads to prevent an evil maid attack using a default Windows thumbdrive signed with Microsoft keys
And I don't mean just the old/BlackLotus affected ones: you have full control of what you allow your system to run.
Compare that with BootGuard which doesn't let you patch your Bios, like you'd want to do to fix PE32 modules :(
For systems where there's a real fear of physical compromise, you'd think there would be more physical mitigations.
The crypto stuff is nice, but I feel like it's difficult to package in a way that non-technical audiences will understand it and not shoot their foot off somehow.
I feel like PCs where the storage can be pulled like a video game cartridge would reduce the threat surface, while avoiding a lot of the crypto risk (lost keys, broken TPMs)
Do you also understand the ripple effects of having a known zero day exploit open for a year? Lose/lose situation for the customers and their related networks, ie almost everyone in the world
The vast majority of home users have never heard of secure boot, which defaults to off. Every corporate network I've walked into I have been the one to push it, as most have never heard of it. Both Microsoft and aws only recently introduced support in the cloud environments, so the majority of cloud hosted environments have not turned it on (which requires replacing the vm). It is far from almost everyone in the world who is even in a position to be impacted by a secure boot bypass.
There is literally no such thing as a "known zero-day". That is a contradiction in terms. Either it is unknown, and exploited as a zero-day, or it is known, and therefore no longer a zero-day at all.
the target audience is all supported+patchable windows systems capable of secure boot; bootable media should be inclusive of all storage used: hdd, ssd, nvme, usb, cd, ect.
They may be relying on the "recovery" partition or whatever it's called. Not sure if for PCs coming with windows pre-installed with a bunch of bloatware that's handled by windows directly so it could be updated by windows update, or if it's managed by the manufacturer, in which case it probably never will.
Windows will shrink its own partition as needed to create a recovery partition (type 0x27 in gdisk), which is just a NTFS partition.
It depends on it to boot when bitlocker encryption is on: \EFI\Microsoft\Boot\bootmgfw.efi => bootmgr.efi => boot.sdi IIRC
You can store other things in this 0x27 partition if you make it larger, like full ISO images like for Ubuntu Live: just place grubfmx64 in your \EFI partition, add it with efibootmgr and you can boot a baremetal Linux when WSL2 doesn't cut it.
Personally, I'm considering keeping a copy of the old bootloader and not updating the revocation DB as chainloading from bootmg to a Linux EKI with an entry when you press F8 could be a fun thing to add (I've read it could be done with Windows 7 and grub.efi but I have no experience with that)
What I've done on a pc that needs to dual boot and has a single drive is create a bigger /efi partition and store a unified kernel image that I boot directly with the uefi. No grub or shim or systemd-boot or whatever extra moving part. I can use the integrated uefi boot selector to switch to the non-default os.
I've had this setup for a while now, and the multiple windows updates never bothered to make windows the default boot entry.
I do the same! My EFI partitions are always a few gigs, because I even stuff .isos into it for easy reinstall/rescue operations:)
For people who are stuck with a 260 (or 100M) EFI, repurposing the 0x27 partition is easier: just shrink the end of your windows partition, and add what you gained to the 0x27 partition after backing up its content - no need to touch the other partitions!
Shrinking a partition from the beginning (as what would be needed to get a larger EFI) can be harder
> No grub or shim or systemd-boot or whatever extra moving part.
Same, the arch way is just better! FYI you may want to add a grubfmx64.efi in there, to be able to select entries more easily for rescue ops. You also get a grub commandline.
I don't like grub as a normal bootloader, but I like having its flexibility when I want to.
Ha, sticking a rescue ISO on a partition is actually a nice touch, never thought of that.
> you may want to add a grubfmx64.efi in there, to be able to select entries more easily for rescue ops
I hate having to deal with bootloaders with a passion. But it could come in handy if my efi can't boot directly from the iso. It does have the option to browse local drives and boot random files, but I've never tried an iso.
Although my rescue iso is custom-made with archlive so that it supports zfs. I could probably just write it to some extra partition and boot it directly.
It's pretty basic, really. Follow the Arch Wiki guide to build an ISO and add the packages from the archzfs repo. One unrelated tip is to also bake your ssh pubkey in the ISO, it comes in handy.
I'm not surprised. UEFI has to publish the revocation keys, then board manufacturers have to update their BIOSes, then the OSes have to enforce them on their level... although tfa makes it sound like Microsoft is skipping the board manufacturers?
I vaguely recall some keys being revoked a couple years ago, but I don't remember why. FWIW, here's a list of previous revocation keys... https://uefi.org/revocationlistfile/archive
Usually systems have a KEK (key exchange key) from Microsoft installed, then Microsoft can revoke keys on their own withot involvement of the UEFI forum, board manufacturers or anyone else (Unless the KEK itself is compromised). They usually publish these revocations later on the UEFI website, but that's not necessarily blocking the rollout.
The actual issue is that the revoked key is the key used by Windows, so revoking it makes Windows unbootable.
Seems a bit weird to call this a Secure Boot vulnerability though since Secure Boot still works, it's just that a validly signed binary happens to be vulnerable and boots arbitrary stuff in a later stage. While this circumvents Secure Boot on all systems which allow booting Windows (so all systems where noone explicitly changes the Secure Boot setup), it sounds more like a Windows boot loader vulnerability than a Secure Boot issue.
Secure Boot by itself is plenty open and user maintainable. On my HP laptop I only have my own keys installed and it only boots my particular Linux install. It won't boot Windows at all nor regular Linux distros like Ubuntu. Other manufacturers intentionally limit their hardware, but that's nothing new, really.
This particular issue is not so much about being able to manage the certificates in Secure Boot. Rather, you can't revoke the old signatures because many people rely on media having them (legitimately) and expect to be able to boot from that media. So now, those systems will boot anything with the old signature, such as a compromised windows bootloader that will happily accept some malware if asked nicely.
According to the arch wiki that doesn't always work so well (didn't try it, though). But what does, is signing the MS certificate with your own key. I do that on my work laptop and it works well. I don't need windows on my personal one.
The advice around the keys and signing is pretty generic. What's arch specific are the various integrations with the package manager than handle automatic signing of the kernel image after an upgrade.
Lower on the page there's a section about signing MS's certificates, so you can dual-boot windows while using your own keys. I have that setup on my work laptop and it works fine.
Sounds like it's pretty garbage though. Given that it's currently broken. How can my computers security depend on MS like that? Theyre not interested in my interests. I think I'll see if now I can replace it with something thats less conflicted, like coreboot.
Can't wait until the other various secure enclave gets hacked so I can get rid of them too.
If you don't want to use it, can't you just disable it?
Again, this isn't a failure of secure boot, but a windows security issue. Basically you can't prevent something from running (the bootloader) if you want to be able to... run it.
Getting rid of secure boot and friends wouldn't change anything to this situation. Either you consider you're unlikely to be infected by black lotus or something similar, in which case you're fine (with SB enabled or disabled). Or you can be infected, in which case disabling secure boot doesn't actually do anything, since the rootkit will run fine without it.
What is broken in this particular situation is not secure boot but the windows bootloader.
Unfortunately, I am suspicious based on some recent circumstances that this bug is being exploited in the wild.
If you do run Windows, be sure to check that your TPM/SecureBoot devices are enabled, and that Core Isolation/Code Integrity (for example, Hypervisor Enforced Code Integrity) is enabled if possible. Unfortunately, this setting can sometimes cause driver incompatibilities and enabling it via the registry manually may be experimental/crashprone.
I think people are overly quick to dismiss the effectiveness of IDS. Yes, rules often match symptoms/exploit instances rather than actual vulnerability semantics (though this has improved. But like a bike lock, even imperfect IDS gives you protection against opportunistic attacks that are pervasive for any system connected to the Internet.
The fact that IDS can respond without needing to validate a new software release means it can also very often outpace remediation through software updates.
Users that dual/triple boot are terrified that after a security update, their alternative systems wont boot. On my MacBookPro back in 2018/2019, an Win10 update prevented Win10 EFI BootManager from loading Win10 if it was installed on the 4th partition. Its sad how fragile their systems are after all these years.
The headline is sensationalist fake news, but I don't expect decency from journalism anymore.
The patch itself is finished and out, Microsoft themselves even provide instructions for turning everything on. Anyone who actually cares about this can follow the instructions, so this is a sensationalist nothingburger.
As the article states below, this secure boot vulnerability affects not only businesses but also consumers.
"Secure Boot has been enabled by default for over a decade on most Windows PCs sold by companies like Dell, Lenovo, HP, Acer, and others. PCs running Windows 11 must have it enabled to meet the software's system requirements."
This is a lose/lose situation for Microsoft.