To me this makes a lot of sense, and really is the reason why most things are by default insecure.
Most people who are building their own computer are not going to be an expert in UEFI and secure boot (some may have never even heard of these things).
These people are almost guaranteed to need to install their own OS.
So if they try, and it "doesn't work", they are going to need tech support or most likely return the motherboard as defective.
Thus it makes more sense to make the default permissive.
On the other hand, someone who does want to run secure boot securely is probably an expert, so they can probably figure out how to actually turn it on and harden their setup. As long as you can lock stuff down, having these people jump through a few more hoops seems like a reasonable trade-off.
(Also FWIW, most pre-builts or integrated devices do have real secure boot enabled, since the expectation is that users of these will likely never need to install an OS that won't work with a strict secure boot enforcement policy.)
This is actually a pretty nice pro-consumer feature as this makes it trivial to lie to Windows that secure boot is enabled while hooking things.
Great for game cheat developers for example, who often want very deep hooks on the system to bypass anti-cheat tooling and with some modern games requiring secure boot to be enabled, this could provide an interesting alternative strategy.
It will just lead to multiplayer games locking out all of these motherboards until they update their BIOS to fix this default, market share be damned. Valorant had no problems locking out Windows 11 users with Secure Boot disabled.
I am shocked that Windows isn't using a TPM Measurement for verification, as the TPM can be used to prove that Secure Boot was enabled. Instead... Windows just seems happy trusting the UEFI and letting any apps that want to ask the TPM. Which... why? I mean, I suppose it's a holdover from Windows 10 where Secure Boot existed without TPM but there's no reason in Windows 11 where both should be present.
If MSI keeps this feature, I would probably buy their boards. I don't get the love for trusted computing, it can have severe negative effects if you look beyond the direct effects of validating your system OS. It can lock down free and open computing and this is far greater than the threat by trojans that I didn't have in the last 20 years.
Since Windows will force secure boot, this is a very welcome convenience feature.
As I understand it, it simulates secure boot being enabled. This is handy for the OS that try to enforce it.
It is not too hard to see that some kind of software will also try to enforce it. Mechanisms like remote attestation are pretty hostile in my opinion. This is about control for me, not about sensible security.
If you really wanted to verify that secure boot was enabled, and that a user wasn't doing "funky things", you'd need to also check for a TPM attestation, as you allude to - this isn't really simulating a whole lot from a security perspective.
You can fairly easily "spoof" secure boot being enabled on a non-secure-boot system, since effectively you are exposing a 1 instead of a 0 (and with secure boot off, can hook whatever you need to). Admittedly, having a button in the UEFI menu is more convenient for an end user though.
If you have a TPM attestation of the device state, PCR 7 is sealed around the secure boot state, and that would be more interesting for someone trying to lock someone in. As you say, if your TPM is then being used to attest that the system is unmodified, then that is pretty user hostile.
For a regular normal non-technical user though, having some "sane defaults" arguably makes sense - if we raise the bar on compromising a regular person's computer by a few notches (i.e. you can't just replace the bootloader with a keylogger and chain-load the regular bootloader), it can help with platform security. The problem is that, on top of that platform, end users run all kinds of (what we'd previously call) spyware/adware, which just sends their data off the system. When this "non-technical user protection" starts to get in the way of expert users, that's when it becomes more of a problem for being in control of your own system.
I also would want to spoof the remote attestations. Let us be honest here, the features to expect is that Netflix doesn't work on your non-approved "secure" device. Not many other benefits to the user are provided.
The most locked down systems are the ones that expose the most data. Granted, that is because of the type of the device in many cases, but that is the current reality.
Some multiplayer games use Secure Boot and remote attestation as confirmation that the user can’t load cheats. Like any anti-cheating solution it’s not perfect, but it can lower the prevalence of cheats dramatically, and that’s one hell of a user benefit.
Not for every user. Besides, the protections this would offer would be easily and cheaply circumvented via a raspberry pi and usb peripheral emulation. The is no escaping the analog hole as you stated.
I'm not willing to give up my control as an owner over my device for a reason as flimsy as this. Gamers who want to give up control for a slightly lower percentage of cheaters can get dedicated computing hardware (consoles) instead.
Not every feature has to benefit every single user. Otherwise let's just remove WSL because it's in use by <1% of Windows users.
> I'm not willing to give up my control as an owner over my device for a reason as flimsy as this. Gamers who want to give up control for a slightly lower percentage of cheaters can get dedicated computing hardware (consoles) instead.
Okay, then turn off Secure Boot. And just don't play these games. No one's saying all computers must have Secure Boot on and untoggleable.
Secured Core is optional and it's very enterprise-focused, i.e.: businesses gating domain join to Secured Core PCs for extra perimeter control.
> It can lock down free and open computing and this is far greater than the threat by trojans that I didn't have in the last 20 years.
I see this claim made over and over, yet we are still to see an actual "act of aggression" (modulo incompetence of an individual vendor - slip ups happen[0]). Every single PC system I ever heard of, allows either enrolling your own keys, or just disabling secure boot; most accept the MS-signed bootloader shim found in common desktop distros; I think this is even mandated in MS' specification that it must be possible for the users to bypass this.
If you haven't had a trojan in the last 20 years, you have been diligent and/or lucky. Scattershot malware (cryptolockers, miners) is incredibly common, one of our customers was hit several times (on systems we weren't managing). More sophisticated attacks are an everyday thing against high-value targets[1][2]. Exploiting computer (in)security is a multi-billion dollar business, platforms far more locked down than PC are being routinely targeted and exploited. Real people, fighting for IRL freedom - journalists, activists, opposition politicians - are in danger.
Please stop spreading the FUD against secure boot, and please back your claims with facts.
Because there was pushback against it. Originally with Windows 8 certification MS didn't care if OEMs had an option to disable Secure Boot or not. After the initial outcry an option was added. They then tried again with Windows 10. And this only applies to x86 based machines, ARM models have secure boot stuck on since RT launched.
Did secure boot stop those malware attacks? Somehow despite secure boot being enabled as default for like 10 years I still routinely hear about XYZ getting hit by ransomware so I'm guessing no. Software freedom can help IRL too.
Secure boot is designed to stop a class of APTs, it is by itself ineffective at preventing malware infection.
> Software freedom can help IRL too.
I never argued against software freedom (or freedom in general) - quite the opposite. But I am disturbed whenever free software advocates paint freedom in one-dimensional terms. You can have hardware that is designed to compromise one of your freedoms, but simultaneously reinforce another. And you can often still utilise that hardware to empower the user, without any compromises. However the rhetoric keeps boiling down to "secure = locked down = non-free = evil".
If an "act of aggression" would happen, I would have no recourse against it. But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry. That is not surprising if you look at the economic interests of involved parties.
On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies.
The primary vector of malware isn't near boot, it is quite exotic these days. Maybe not rare, but not the primary attack for usual targets. But that is also irrelevant if I could just spoof any attestation. Just give me the option. Shouldn't be too much of a request, no?
One prediction is that there will be classes of devices. Trusted and untrusted. We already see that happening. This is not desirable for security and in the interest of users. That especially includes journalists and activists.
For security it isn't enough to wait for aggression, you also have to look at a larger picture. Some people argued HDCP is to shield against eavesdropping.
And it if is in the interest of security, you would need to propose very foundational security arguments. As it is exposing your security state to third parties is an additional threat itself.
> If an "act of aggression" would happen, I would have no recourse against it.
You have the same recourse as you've always had. Vote with your wallet, don't buy the hardware.
I am much more concerned about Intel ME and AMD PSP, where's the outrage about that?
> But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry.
Can you please link me some articles/references? This is relevant to my interests, I would like to actually see something that backs up the counter-argument.
> On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies.
I'm aware I'm stretching things, but the stance "Secure Boot = attack on computing freedom" is quite regularly stretched to argue against many other hardware security features, such as TPM or Secure Enclave. If my laptop is stolen, confidentiality of all my data is only as good as my passphrase. Am I paranoid enough to employ a complex, unique, zxcvbn-proof passphrase? Hell no. I would much rather use four random dictionary words, and let the TPM throttle cracking attempts.
(Yes, I know LUKS offers KDF, with a number of iterations picked to reasonably throttle cracking attempts on today's hardware. I would still rather see the cracking stopped dead after 10 attempts, and this physically requires dedicated hardware.)
It's 2023, Thinkpads have been shipping with TPMs for over a decade, and I still can't easily utilise a TPM to keep the FDE decryption key - is it because the TPM genuinely does not offer tangible improvement over plain LUKS, or is it because it was being actively pushed back against in the free software community, and nobody bothered to integrate the functionality?
Repeat this for GPG/SSH/FIDO keys, I am expected to buy a dongle that I can lose, and plug it into a USB port - but can't sensibly utilise the hardware that has been soldered onto my motherboard, which was designed with that explicit purpose?
Please correct me if I'm wrong, but all I'm seeing is a pattern of: "dedicated security hardware = attack on freedom", with pushbacks at any attempts to utilise such hardware for the benefit of the user.
> The primary vector of malware isn't near boot, it is quite exotic these days.
APTs / evil maid never stopped being a thing. Security isn't about what's unlikely, it's about the entire chain. Maybe your targeted attack requires a key logger to remain dormant/undetected until a particular moment in time, six months from now, and the best way to hide it is by paravirtualising your kernel. We've seen attacks way more sophisticated than that (stuxnet).
> But that is also irrelevant if I could just spoof any attestation.
I agree 100%, attestation is just layers of bullshit. But I still want my device to ring an alarm if an APT is suspected.
So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited.
> > But that is besides the fact that these acts of aggression
Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do.
My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell.
> Vote with your wallet, don't buy the hardware.
> ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that?
With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers).
> I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality?
I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.)
> Security isn't about what's unlikely, it's about the entire chain.
... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).
> If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited.
This is exactly the area where I would double down on the "vote with your wallet" argument. There is enough variety and choice in the Android ecosystem, and if you do really care about running LineageOS / GrapheneOS / PostmarketOS / etc, you probably already know what your options are.
> With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers).
You will always be able to buy hardware and support vendors that are explicitly non-hostile. System76, Frame.work, MNT... More maintstream options also exist, Dell was shipping laptops with Ubuntu as far as in 2006 (I remember it was big news at the time, I don't know how is it like nowadays). Even Apple seems committed to allowing (quietly encouraging?) third-party OS's, so I'm watching the progress on Asahi as well.
> A great thread and arguments provided here, how Microsoft [...] will not sign anything GPLv3 for SecureBoot
Complex licenses result in complex issues. I understand why FSF chose to design that license the way they did, but it's my personal opinion that they've caused more harm to the users of their software with it than they've done good. Software has value when it can be used. If I can't use it (e.g. because my vendor won't ship it), it has no value to me.
I don't understand why Free Software advocates want their users on non-free platforms to suffer. Just a couple days ago someone on HN suggested that GIMP shouldn't have been ported to M1 Macs[0]. Emacs disables already-working features, because support exists only on macOS[1]. The BSDs had to ship with years, almost decades old forks of GCC[2]. I think these moves are an underhanded attack on the users' four software freedoms. I might have no choice of operating system (e.g. because this is what my employer mandates, this is the hardware that I was able to afford, there is other non-free software I must run to earn my living, etc), and FSF/RMS think I should be punished for that.
From my (user's) point of view, neither FSF nor MS care at all about what benefits me - the user, and instead just want to play out some petty political conflict.
> But if I followed through, then still the weakest point is/becomes the keyboard.
Nope, keyboard has no more importance than any other part of the device. Once an adversary has physical access, all bets are off. Nuke it from the orbit, restore from backups, and rotate all credentials.
About choosing phones: I agree, but for newbies the realization may come after the purchase. And the custom ROM experiment may be postponed until the next purchase... and then forever.
I have had a good example of a late realization where choosing the right iirc car/phone in advance would have been needed to avoid incompatibility, but I forgot what it was.
About the laptops: I looked at Tuxedo first, I liked the big battery but disliked the rest. As I continued reading, I found out they are reusing OEM laptop chassis, so their only contribution is branding an a distro customization (probably to integrate it better with hardware). I suppose it's what most others do too. After this realization I began looking at mainstream manufacturers and "compromised" on a good model without an OS pre-installed or proprietary plugs.
Would I want to compromise on price or features to set a clear signal? At least MS didn't get paid for the license :)
About FSF: oh that Emacs story is terrible. Outside of this idiotic disablement, I can understand both sides. "I cater to users, but at the same time I don't want to spend my time enriching an Apple/MS ecosystem for free". Ranted about by wm4 of mpv[1]. This doesn't apply to willing maintainers :)
Another point about GPL licensing was brought up in no pretty words by digdeeper[2]. Someplaces twisting words and the intended logic, but it is an argument close to OpenBSDs:
> GPLv3 is (in our opinion) not actually free, and we are not able import anything encumbered by it. GCC 2.4.1 and Binutils 2.17 are the last GPLv2 releases.
My own conclusion: if you want a revolution, an opposition to the closed source (enterprise world) then you show it with a GPL license. To make sure the fruits of your labor are not exploited and only the FOSS part of the software world grows richer. You see where the rhetoric is going. The good examples are coreutils and GNU libc. The bad examples: only few giant companies care to follow the license terms. Many avoid GPL, many exploit it ignoring the terms.
TLDR: If you want improve some part of computing in the world, BSD or MIT. If you want to have a FOSS project, a variant of GPL (imho).
About politics: I wonder how many are actually still developers and not some... non-developing profession? Although FSFE (Europe; with no affiliation to FSF) exists, I was surprised to learn they only have lawyer and related positions to offer. No development happening apparently.
> About choosing phones: I agree, but for newbies the realization may come after the purchase. And the custom ROM experiment may be postponed until the next purchase... and then forever.
Well it means it's not an important factor for those people. 99.99% of the market is served by a device that runs WhatsApp, TikTok, Google Maps, and the local banking app. For most people, "freedom" is the freedom to have the free time to talk to their parents who are half a world away from them; NOT the freedom to mess up their bootloader.
I stand by my claim: if you care about these issues, you know what to buy.
> My own conclusion: if you want a revolution, an opposition to the closed source (enterprise world) then you show it with a GPL license.
I don't want any revolution, I want Free Software to be objectively better - because using bad software just sucks. Free Software should be able to go toe-to-toe with proprietary software, heck even be just better - it has the clear advantage of accumulating volunteer contributions and so on. And yet rather than building a better product that can win with the alternatives by its own merit, we're caught up in bullshit political games.
That's exactly the problem with FSF, they're long done actually improving their software, and are just using their position to leverage themselves politically, while making choices that actively hurt their user base. Their technology is stagnating and becoming more and more irrelevant as alternatives are catching up or surpassing them (clang/llvm), most remaining value is in broad (in)compatibility (glibc, bash, coreutils), which hurts other FS projects too (*BSD, Alpine). I've been using Emacs for 20 years and feel more and more trapped with it - no other editor/IDE comes close, despite FSF's efforts to undermine the project. As a potential contributor, I'm scared away by their practices of turning down improvements on political grounds. As a user, I feel trapped in their staged shitshow.
> As a potential contributor, I'm scared away by their practices of turning down improvements on political grounds.
As a potential contributor I suggest you to be present on their mailing list (filter for OSX and other keywords if you wish) to have a voice when needed.
> Their technology is stagnating and becoming more and more irrelevant as alternatives are catching up or surpassing them (clang/llvm)
I would say clang+LLVM is a poor example, because for C/C++ they're directly comparable in final performance (state of the art). The Clang suite is newer and I'd argue benefits from this and the lack of legacy. Then Apple has it as their compiler of choice and this entails a lot of dedicated work force.
Instead I'd say GNU/FSF have stagnated in their methods of collaboration. I've looked at their GCC website. It probably looked not too different in 1999. That's not a bad thing but mailing lists... I understand the love for e-mail but not the mailing lists. I think if the wonder called Rust didn't embrace the new ways of thinking, communication and tooling, it would not have developed into what it is today and as fast as it has.
Finally GNU/FSF may have served their purpose. They spawned the idea of radically free and open source software. A decade later (1990s-2000s) the thousands of neat programs were being made for Win32 and very few developers chose to open source their creations even when the software was perpetually free. "I dont want others to see my code" sometimes out of fear of being judged, remember those arguments? Think of the developer effort wasted in discontinued programs that are no longer available/working and either have no successors or their successors had to be remade from scratch. Thankfully nowadays the mentality has changed and it's rare to see a free/shareware program that still remains closed to the public.
> Do you think secure boot stops cryptolockers? By what means?
You took my sentence out of its specific context (GP was arguing that they hadn't had any malware in 20 years), and put it in another, where quite obviously my argument is painted much weaker.
What exactly is Windows supposed to verify? There isn’t a standard PCR with some standard value indicating that a certain image was booted.
DRTM is a credible (sort of) alternative, but at that point Secure Boot isn’t really necessary — the whole point of DRTM is that you verify the current state of the system, not how it got there.
> There isn’t a standard PCR with some standard value indicating that a certain image was booted.
No, but there is a standard PCR with a standard value indicating that a certain certificate was used to sign what was booted, and Windows is signed with its own certificate rather than the third party UEFI CA one.
I looked into this on my motherboard, and the issue is that MSI's firmware measures in the TPM events saying "Secure Boot is On", even when it is in this insecure mode.
This means that even if Windows "checks" (via measured boot) that Secure Boot is on, they are still being lied to by the motherboard firmware.
PCR 7 doesn't just indicate whether secure boot was enabled, it also contains information about which certificates were used to boot. Obviously if you'll happily sign something unsigned the unsigned thing can just fake a measurement that contains the expected certificate, but I'd be interested to see what the event log looks like on one of these systems when it boots an unsigned binary.
Windows does do that, it’s called Secure Launch. It uses DRTM and SRTM for remote attestation to prove to remote machines that the OS booted in a well known state. The biggest problem is that there is such a modge podge of hardware and firmware to measure, that the only real use of it is in corporate environments where the hardware deployed is fairly homogenous.
>Most people who are building their own computer are not going to be an expert in UEFI and secure boot (some may have never even heard of these things). These people are almost guaranteed to need to install their own OS. So if they try, and it "doesn't work", they are going to need tech support or most likely return the motherboard as defective. Thus it makes more sense to make the default permissive.
Not only that, a popular tool for creating windows USB installers[1] fails to boot if secureboot is enabled. I looked into it a few years ago and it was because it defaults to NTFS formatting if install.wim is greater than 4GB (because of FAT32 limitations), which is most windows ISOs. Most UEFI implementations don't support NTFS, so it installs a shim loader, which is unsigned and therefore fails to boot with secureboot enabled.
Huh, interesting. I know he'd been working on it for a while and wasn't getting anywhere because of Microsoft, but apparently he finally got it working. The only real issue is getting your bootloader signed by MS. There's no other way to pass Secure Boot verification.
• Microsoft refuses to sign GPL3 code for secure boot, because the anti-Tivoization clause is specifically designed to prevent this (the system basically tries to achieve what Tivo did, only supporting boot authorized by people with a given key).
• The Rufus developer did work to get the GPL2 ntfs-3g drivers usable in UEFI.
• Microsoft appears to have no issues signing that.
I never used Rufus but I prepared USB sticks few times. Here're my observations:
1. Every computer I've used supports NTFS in its UEFI. I even thought it was standard. So simplest way to create a bootable USB stick: format it with GPT, create one big enough NTFS partition and copy ISO contents inside. That's it.
2. Converting install.wim to sub-4GB chunks is trivial one command. Create one big FAT32 partition, copy all but install.wim, convert install.wim with `dism` and copy it.
That's it. Much easier and faster than using some tool doing strange things with shim loaders and whatnot.
Linux sticks could be created exactly the same way. UEFI is awesome.
> Every computer I've used supports NTFS in its UEFI. I even thought it was standard.
I've never seen a motherboard supporting anything else than FAT for an UEFI partition. What is likely happening is that you're booting using a small EFI System Partition (ESP) formatted in FAT32 which contains a bootloader with an NTFS driver.
It can get confusing because the EFI bootloader generally registers new boot entries for each non-ESP partition, but these are booting the ESP with the selected partition GUID.
> I've never seen a motherboard supporting anything else than FAT for an UEFI partition.
Then you haven't used any Gigabyte, Asus or Intel motherboard for the last 5-7 years, because all the ones I tried include a native NTFS UEFI driver alongside the mandatory FAT32 UEFI driver.
But, as others have pointed out, while it is definitely getting commoditized, you can't rely on NTFS being available in a UEFI firmware.
> I've never seen a motherboard supporting anything else than FAT for an UEFI partition.
I've seen exactly one model line, that does support NTFS in UEFI: Intel NUCs. It was quite nice, but nobody preparing boot media can rely on the availability, as the only mandatory filesystem is FAT32.
I'm pretty sure it didn't happen because I partitioned disk myself using diskpart and I did not create any small partition with bootloader or whatever. Just one 10GB NTFS partition and copy files from mounted ISO to this partition using ordinary explorer Ctrl+C, Ctrl+V.
I've used that with few Asus motherboards (I prefer this brand) and one dell laptop. They were 2015+, so relatively modern, I guess.
Most people are going to install Windows and Windows works out of the box with secure boot enabled. Most other people will use a popular distribution like Ubuntu or Fedora which work out of the box with secure boot enabled.
I doubt people installing their OS will run into this. Even still, the firmware contains the ability to prompt the user about secure boot failures, so if you're going to neuter it, at least pick that as the default option so people notice.
Instead, my suspicion is that these policies are in place so non-OS firmware can run, such as firmware update tools for upgrading the BIOS itself or perhaps management chips/HDDs/SSDs/peripheral controllers. If I were to lock down my previous laptop with secure boot, HP's firmware updates would no longer be able to run without enrolling their signature keys.
> Most other people will use a popular distribution like Ubuntu or Fedora which work out of the box with secure boot enabled.
I installed Fedora on a Thinkpad recently and it most definitely did not work OOTB. I had to enable the third party cert in the BIOS. Not sure about other vendors
It's a Microsoft thing. "Secured-core" PCs are becoming a thing, and Lenovo selling primarily to businesses became one of the first. If you haven't seen it yet from other OEMs, you will soon. :(
> Even still, the firmware contains the ability to prompt the user about secure boot failures, so if you're going to neuter it, at least pick that as the default option so people notice.
People don’t read error messages. By this I don’t mean that no one ever in the history of the universe has, but rather that a high percentage will just contact tech support or RMA the board as broken. I can’t really blame mobo manufacturers from making the choice that minimizes tech support costs from consumers who won’t read and understand an error message.
> If I were to lock down my previous laptop with secure boot, HP's firmware updates would no longer be able to run without enrolling their signature keys.
Well that's... really dumb and shows why OEM's are terrible at security, as there isn't a reason I am aware of on why Secure Boot can't trust two keys simultaneously (one for OS and one for vendor). Heck, Microsoft themselves seems to do it with "Windows + 3rd Party UEFI CA."
I suppose I _could_ sign the extracted UEFI loader manually to make the updates work, but that pretty much breaks the automated process and requires me shuffling the boot order manually after the failed boot. Not a great solution and that assumes the UEFI image doesn't do something weird like its own signature.
It makes sense to use UEFI programs to update the UEFI, but secure boot adds a layer of complexity on top of that which requires taking special notice.
I'm not one to praise my HP machines, but this is one area where I've had zero issues with them.
Are you by chance using "consumer" models? My "enterprise" level PCs, starting with models of the intel 6th gen era, up to 12th gen, have been smooth-sailing secure-boot wise. I didn't interact with any older model.
I run Arch (which isn't signed by MS like Ubuntu / Fedora) and sign the bootloader with my own key that I've generated myself. On some computers where I need to dual-boot with Windows, I've signed MS's Windows key (not the third-party one) with my key. Everything has always worked fine, including automatically upgrading the UEFI over the network from the UEFI itself, installing Windows 11, etc.
I never needed to disable Secure Boot (apart from initial Arch install) or sign any HP-specific key. The only thing that "breaks", but that's expected and HP warns you during the update, is that whatever relies on measuring the UEFI image will break. That's typically the case with BitLocker (mentioned specifically) and LUKS.
Can't say anything about secure boot, but we have HP at work and the BIOS is the most brain damaged thing ever.
Just the built-in update process... It doesn't always find the latest version, ie lags behind the website by weeks sometimes. Then when it checks for updates and finds there isn't a new version available, it offers you to downgrade to the previous version but apart from the text being a bit different, the blue button below still says "UPGRADE", so the first time I accidentally started a downgrade. So it started flashing the BIOS, then something like the nic firmware, then came to the Intel ME firmware and suddenly said "uh no, I cannot downgrade that" and just aborted the whole update process. No idea if it would've kept flashing other stuff after the ME, and evidently it didn't break anything, but holy crap that looks like a half-arsed feature.
HP Probook 450 G2, I believe that's part of the business lineup. I run it as a home server these days and after many years they finally stopped making updates for that thing, so I can't say I care too much.
There's a very good chance they changed their update procedures, but when I last ran the update I needed to run a special .efi file that would handle the flashing.
For what it's worth, I consider the HP Probook line to be excellent in terms of both durability and support. They may not be three millimetres thick like their competition but design wise they're quite alright, the machines are quite sturdy for their weight class. Their repair guide has very detailed step by step instructions on how to replace parts as well as listings of known replacement part product numbers which are great for finding replacement fans.
I think I've received at least seven years of UEFI updates, which is about 6 more than I expected for the price. HP graphics drivers actually got updates and they offer a way to keep track of updates through email without having any crapware installed. The UEFI itself is also one of the best I've used, miles ahead of the Lenovo one. The ability to browse EFI partitions and navigate to an image of your choice is excellent and I can't believe I haven't seen this on other brands.
Enrolling keys, however, required clearing the certificate cache. I could reset it back to factory settings and load the default Microsoft keys, but for their custom updaters I would need to disable secure boot or find the key they used and import it. Hardly a deal breaker, that's just how Secure Boot is supposed to work, but still something to think about when designing an updater process.
Interesting, I have a 430 G2 I occasionally use as a media player, and it's the only one on which I never attempted to install anything else besides Ubuntu or Windows, so never had to deal with Secure Boot. I actually don't even know if it's on or off.
On newer models, you also have to "clear the certificate cache" to enroll your own keys. But there's an option on the same page like "reset to factory defaults", which reloads the MS keys and such.
The manual UEFI update is indeed a bit cumbersome, especially since the downloaded archive seems to be some windows executable. And, in my case, I don't remember I could navigate in the partitions, it would just complain that it couldn't find the update if it wasn't in the right directory.
I work in tech(professional programmer) and I frankly don't know anyone who runs anything other than Windows. I guess it just depends what area of tech you're in. And yes, myself and all my friends built our PCs by hand and installed windows on them ourselves - I'm glad secure boot wasn't getting in the way of that.
Must really depend on the field. People around me are mostly running gnu/linux or macos (roughly 80/20 split). I think some have dual-boot with windows.
All my friends, even developers, use their PC's mostly for gaming and "office" work (text editing for work and hobbies). Most of them are capable enough to run Linux, but most of them prefer Window as the default. They often run Linux at work for development, but stick to good ol' Windows 10 at home. I can't fault them for their preferences, even though I'm definitely Linux-first myself.
What he meant is that people don't install Windows, it's almost always pre-installed. Most PC nowadays don't even come with a physical copy of Windows, only with the pre-installed OEM image.
The people I was referring to built their own PC. The people who do that are a minority for sure, but they're going to be the customer for most of these specially branded MSI boards.
> I can't recall a single person that brought a personal computer and then installed Windows on it on the last 2 decades.
Interesting bubble. 50% of the programmers I know installed Windows and the rest use prebuilts that came with Windows. Same 50/50 statistics for gamers in my bubble.
> Most people are going to install Windows and Windows works out of the box with secure boot enabled.
Any windows version after windows 10 isn't going to work nicely without extra process if you want to do a usb install. Because the ISO file already exceed FAT 32 4GB limit.
And DVD burner? Who still have them these days?
So most people will going to use one of these 3 party tools. And some of them will use an old version tool, fail, going into support queue.
My default method of installing Windows is extracting the ISO file to a FAT partition and that has always worked without trouble for me. The official Microsoft tool does some extra magic to the drive (I think it also fixes the partition table for you) but I've rarely needed to run that.
You don't need to store the entire ISO file on the drive as a 4GiB+ file, as long as the contents can be extracted onto FAT32 the installer can be booted.
MSI's BIOS falsely reports to Windows that Secure Boot is enabled. This is very different from just shipping with Secure Boot disabled but available. That would be pretty normal (at least of a few years ago) - but shipping with a mode where it is "enabled," and Windows is convinced that it is "enabled," even though it is doing practically nothing - that's an inexcusable situation. Assuming that I interpreted this rather vague statement correctly, of course:
> When we enter the menu, we can see the disappointing default settings. It's doing no verification. It's useless. It's just there to satisfy Windows 11 requirements. OS has no idea that Secure Boot is doing nothing, it just knows that it's "enabled".
As he says, this would totally break UEFI Spec. Secure Boot being available but disabled is OK and common - Secure Boot being available and saying enabled while actually not checking is a violation.
The Windows installer does an awful job at guiding the user through this. If Secure Boot is turned off, it doesn't tell you this. It just says "Your computer is not compatible with Windows 11"
I have a brand new desktop and Windows just flat out says you can't install it when I'm sure it just involves changing some settings.
Windows 11 requires information from the BIOS that Secure Boot is available, not that it is enabled.
EDIT: I stand corrected. Windows 11 is OK with Secure Boot capable if you are upgrading from Windows 10, but requires enabled for a fresh install, though Secure Boot can be disabled after installation.
> While the requirement to upgrade a Windows 10 device to Windows 11 is only that the PC be Secure Boot capable by having UEFI/BIOS enabled, you may also consider enabling or turning Secure Boot on for better security.
Yup, this is the confusing thing about Windows 11. The requirements for upgrades and fresh installs are different so upgrading will work but installing from scratch on the same machine may fail.
I think MS deliberately chose to let users upgrade from Win10 without secure boot because too many PCs have it disabled by default, and your average user cannot be expected to go into their UEFI security options to resolve that. The secure boot requirement is mostly intended for vendors AFAIK, requiring them to turn it on by default (and leaving it up to the user to disable it) so Windows 11 can make use of the additional security features out of the box.
For the 99% use-case, secure boot being enabled and enforcing by default shouldn't really be an issue in the last few years.
Almost all major Linux distributions (i.e. the ones with an easy install disc image you write to a USB stick) use a signed bootloader, and shim or mok or another way to validate the boot chain - the installer will boot fine, and after install, the OS will boot fine, under secure boot.
Windows since 8.0 (?) has also shipped signed - installer and resulting install will both work.
Unless you're dealing with an edge case (i.e. you want to install a non-secure boot capable Linux OS, or BSD or something less common, which isn't using a signed loader), an end user should never really encounter secure boot issues in theory. That's not to say there shouldn't be an "off" switch; but that these days there are very few scenarios where an end user doing their own OS install will hit a secure boot failure.
Having to handle 1 customer support ticket for every 100 board sales seems like an extremely serious problem well worth supporting!
The failure rate of motherboards is only ~3%, imagine adding an extra 1% on top...
(I know you're trying to make a point with the 1%, but _any_ reduction in support tickets by adjusting the secure boot default (which is essentially free) is going to be worth it to the manufacturer. )
You don’t have to know about UEFI or Secure Boot to properly install Windows. You download an EXE from Microsoft, make an installation USB, and it‘s fully configured for you. That’s what everyone does (especially in the desktop PC space) and it’s works with Secure Boot perfectly well.
Whether it's intentional or not, I like that there are still companies which are willing to subvert the corporate authoritarianism of Big Tech.
What's funny is that "Allow Execute" and "Query User" options are breaking UEFI specification
They're giving the user freedom, which the specification is against. IMHO they chose the right path. Willful disobedience applies to software too. My opinion of MSI just got a little better.
No, the specification is not against user freedom. "Always Execute" is not against the spec. "Query User" is partially broken, so it's not even that useful. If you use a bootloader, you will only be able to confirm booting of the bootloader, you won’t be able to confirm the OS that it starts. You will get the dialog, but the input won’t work.
At one point, I would have agreed with you. But Microsoft and Intel have been strong-arming implementations to reduce or eliminate user freedom over the past few years.
I hope that they provide a visible warning that secure boot is subverted.
So it's not that some evil maid could replace the boot chain and update the firmware settings to make it behave as if nothing happened.
Just for those folks who use and want it.
And maybe also introduce a TOFU model i.e. "allow execute" but ask when the hash changes, so booting the same unsigned binary is OK but updates aren't silently allowed and require a quick confirmation (possibly with a timer for unattended reboots). Won't help against physical attacker but should help against a malware that manages to get root and tries to install itself into the boot chain.
So the maid replaces your keyboard instead. There is no security in this scenario, the only option is "don't use the computer".
Meanwhile, there is a really weird segment of "security people" that focus a whole lot about attestation and signatures and "secure boot" and the like but very little about what actually ends up breaking systems. Call it the Sony syndrome where you ship 15 layers of chainloaded bootloaders and security systems but don't bother updating the years old WebKit. Apple has it too, always money around for implementing another mitigation scheme in XNU but if you ask why nobody updated the outdated open-source PDF library embedded in their Objective C messaging program it's crickets.
Well, it's another level of sophistication, requiring some more investment?
Replacing a bootloader or a kernel (or initrd) and disabling Secure Boot is easy for just about anyone with 5-10 minutes access to a machine. A modified keyboard is less so.
Then you set an administrator password in your BIOS and prevent changes by anyone but you. Some laptops even allow you to use the fingerprint reader for this. (Had a ThinkPad that did this)
I’ve never understood secure boot. If someone gains physical access to one of my devices, they can do any number of things to compromise it. I don’t really understand what threat model secure boot protects against, but I have spent so much time digging thru bios settings trying to figure out how to disable secure boot so I can install my preferred Linux distro that it seems the primary “threat” is users who don’t want to install Windows.
Secure Boot is designed to help with malware compromising boot code that runs before the OS gets to run and thus has the ability to hide itself from OS and everything running on it while also able to intercept everything an OS is doing.
Given that often physical access allows secure boot to be turned off, it’s clearly not made to protect against a physical attacker.
Now, what’s left is a bit of a mixture of a political issue and developer laziness that makes secure boot a binary toggle of on=boots only microsoft-sanctioned OSes and off.
Ideally there was a safe way for a user to get their own boot loader and OSes signed to allow them to safely boot their own OS while still being sure that it was the user‘s intention to boot that thing.
> I’ve never understood secure boot. [...] I don’t really understand what threat model secure boot protects against
It helps if you remember the context in which Secure Boot was created. Back then, boot sector viruses and similar malware were common. The way they operated was by hooking the operating system while it was being loaded. The operating system (or software running on top of it, like anti-virus and other anti-malware stuff) could protect itself against something which loaded after the kernel and device drivers, but not against something which loaded before the operating system kernel itself.
That is: the main threat model Secure Boot protects against is boot sector viruses and similar. Even if some malware gets write access to the full raw disk, it still cannot inject itself before the kernel in the startup sequence.
> t helps if you remember the context in which Secure Boot was created. Back then, boot sector viruses and similar malware were common.
At the time the Secure Boot was conceived, boot sector viruses were extinct by about a decade. What was new, was the VM* set of instructions, and the scare that there could be a new kind of boot sector viruses slash hypervisors, which could do a bad things to your computer. There was never such a virus in reality, only hypothesized.
It's to secure Microsoft's control of your computer.
(It's not to secure your computer -- that will remain a roach motel of unpatched exploits. But it will be a roach motel that runs Windows rather than something else).
My pet theory, which I admit might border a conspiracy theory, is that secure boot was intended to prevent the "Windows loaders" used to run pirate copies of Windows.
> If someone gains physical access to one of my devices, they can do any number of things to compromise it.
They really cannot. Of course, this means you have to properly secure other knobs as well: Setup password, custom certificates (so a compromised Redmond certificate is irrelevant, configure your OS to use measured boot and abort on all changes, ...
This would mean: Secure Boot cannot be disabled; Software cannot be swapped out; DMA devices cannot be added.
If properly implemented, Secure Boot, a TPM and full-disk encryption will create a PC that cannot be internally compromised by regular thread actors. External additions (keyloggers and the like) are still possible of course.
The idea there are NSA spies who are simultaneously so active they'll sneak into my home and open up my PC to install a bootloader backdoor, and yet so passive they won't plug in a $5 hardware implant seems.... unlikely.
> I don’t really understand what threat model secure boot protects against
Installing linux.
Yes yes you can disable it (for now), put your own keys (very unlikely) but if you do windows will not boot any longer, unless you also disable disk encryption before disabling it.
Do like rms and think long term. The feature is there to lock which software can run on the machine, and prevent the machine to be used to rip movies.
These defaults seem like a reasonable, pro-consumer choice. Great to know there's at least one vendor that helps to get around the restrictions Secure Boot creates for the user.
Secure Boot has always been an anti-feature, at least from the user's point of view. It seems really strange to complain your device isn't locked down enough by default: the restrictions can always be enabled manually if that's your kink.
By that logic any security feature is an antifeature. The problem with that logic is that you can't ignore the potential harm that is being protected against.
UEFI and "Secure Boot" has always stuck me as a terrible idea. It adds lots of complexity to the boot process - which means that it adds vulnerabilities. Added complexity almost always leads to more vulnerabilities.
It adds a DOS partition (!!!) to the disk, and prevents me from for example dual booting two versions of Debian on the same machine.
The whole thing has a bad smell of Microsoft around it, which translates to hidden motives (make it hard to not run Microsoft on this hardware) and insecurity (because they don't do "secure". They never did).
If you want "secure boot" - get hardware that support "legacy boot" and boot something else than Microsoft Windows ;)
It is a FAT32 partition; most DOS versions are unable to read it.
> prevents me from for example dual booting two versions of Debian on the same machine.
It doesn't; UEFI doesn't care what is the boot image, only that there is some. You can register as many boot targets as you want. Check efibootmgr in one of your debian instances, if your installer is not capable of doing that.
Great writeup. The result is not particularly surprising. I suspect they did this to reduce customer support messages about things not working and decided just putting fake secure boot in makes things work most. Security would be not a major concern for gaming mobo makers.
Shouldn't this be an non-issue in any sane setup (ie. secureboot + TPM + FDE)? If the TPM is doing its job, it should be measuring the signature of the bootloader, so whether it's signed or not is irrelevant. Even if you could get stuff to boot, it wouldn't do you any good because you can't access the decryption keys. On the off chance that you're using secureboot without TPM + FDE, you'd be screwed anyways, because a bad guy could easily disable secureboot inside bios settings, or use shim loader to bypass it.
Part of the issue with this MSI problem, is that the firmware also measures TPM events that say "Secure Boot is enabled with this configuration" even when it's not. These events are (almost always) used for FDE (via PCR 7) with a TPM.
This means that even if you setup FDE correctly (binding to say PCRs 0, 7, and 11), you would be able to bypass FDE using this MSI bug. For example, BitLocker binds to PCR 7.
You could get around this bug by sealing to PCR 4 (which contains the _hash_ of the bootloader). But then you have to redo FDE sealing every time your bootloader updates.
>On the off chance that you're using secureboot without TPM + FDE, you'd be screwed anyways, because a bad guy could easily disable secureboot inside bios settings, or use shim loader to bypass it.
You can defend against the bad guy disabling SB in the UEFI settings by password locking the UEFI setup. I don't know how common it is but all the mobos I've used for home PCs have such an option. Of course whether mobo manufacturers implement password locking correctly is another matter.
Another line of defence is a chassis intrusion alarm to prevent the attacker from switching to alternate BIOSes and such, but those are normally only found in enterprise cases in my experience, and of course are not completely attacker-proof either.
It's the standard bike lock tradeoff - perfect security is unattainable so you just put more and more roadblocks in the attacker's way to deter them hoping that they give up and go for an easier target. Although, unlike a bike lock, someone attacking your PC is probably doing a targeted attack anyway.
So is there any reason for secure boot to exist, other than to make it harder to boot an operating system other than Windows? I am all for verified boot (like implemented on some smartphones like Pixels), but UEFI secure boot doesn't seem particularly useful to me.
One thing that makes Secure Boot nice is how it (in theory) works _with_ measured boot. You get a measurement into the TPM that contains the public signing key that was used to verify the signature on your bootloader. This means if you update from one signed bootloader to a newer signed bootloader, you don't need to change any disk encryption or sealing.
Of course blocking execution is orthogonal to verifying the boot chain, but unfortunately those issues are conflated in the UEFI spec.
The fundamental problem is that someone somewhere decided that setting up signing keys was too hard, and that because of this the manufacturer should be in charge of setting up the keys. so now instead of you owning your hardware and setting up the keys on first boot, Microsoft owns your hardware and the keys are theirs. And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do.
If instead the decision had been made to have the user set up some keys and authorize the OS, the process would have to be streamlined and easy.
In conclusion, signing your operating system is too hard, unless you are in the happy path where your OS is signed by Microsoft it is far easier to just disable the infernal subsystem as it gets in the way.
> And in a case of self fulfilling prophecy, because they decided that initializing and owning your own keys was not going to be a normal part of the user experience, it is now hard(almost impossible) to do.
This is false.
The issue is that nobody has written user-friendly tooling to manage keys and sign stuff. Not that actually implementing this is hard.
It's part of killing plaintext exe's, Secure boot is anti piracy tech they are killing win32/Dos16 EXE model that enabled mass piracy, it's all about anti-piracy you can read about it here:
Windows 11 and TPM are about locking down the PC and turning it into a mobile device.
What do you think MMO's and steam were for the last 23 years? There's been a war on local exe's and your file system, driver signing in hte windows 2000 and XP days was Microsoft and hardware vendors working out the bugs of moving us to encrpyted input output.
They are selling it as "trusted computing" but its all for enforcing software licenses so you can't access the files. That's what NTFS was for in reality, it was about the return of mainframe computing, that's why windows 10/11 is a client-server OS and why windows 10 has forced updates.
The whole thing is to turn the PC into a console where app developers can update the firmware/bios with new encrpytion keys if the exe's get cracked.
That was the whole point of Secure boot, it was first used in consoles and the same tech in phones.
Apple, google, and the entire industry has wanted to kill piracy and enforce copyright ruthlessy.
Ever notice the rental ad on Youtube? Google would like to turn files into bits of property you can sell via encrpytion and can't accesss.
The big lockdown is coming because they saw the profits of locked down computing devices.
So no Secure boot is about killing Win32 EXE's and moving us to win 3, with Denuo levels of protection on executables.
With Trusted computing microsoft can force update security policy over all EXE's with the new exectuable model and the mmo/steam generaiton enabled all this over the last 23+ years starting from 1997 with ultima online and everquest in 1999.
That's why basic features like multiplayer game hosting inside local apps (like quake 3 and Unreal tournament 2004) disappeared.
The whole point was to move us back to mainframe computing of the 60's with draconian copyright enforcement.
In theory it would make bootkits (ie. malware that installs themselves as the bootloader, thereby being able to compromise/remain undetected for every subsequent step) harder to pull off. It's not part of my threat model though, because if malware made it onto my machine I'd be doing a full wipe. Also, this xkcd is pertinent: https://xkcd.com/1200/
Are you confusing a bootkit (ie. malware that's in the boot loader) with malware that's in the firmware itself? If it's just in the boot loader, that's still stored on the hdd/ssd itself, and therefore can be wiped.
I said "can be made to persist" and I meant, yes, that the malware could be compromising the firmware. And by "can" I implied that not all of it does, but the possibility of it doing it does exist.
Secure boot is indeed designed to protect against bootkits too.
Interesting, and I think a positive option, if an odd default. My guess is that this was a direct result of people saying "But I need to install windows 11!" but not wanting to actually default-activate secure-boot in case it screwed up other systems.
I'd have preferred this to what happened on my MSI MEG X570 Unify motherboard when I recently updated the BIOS and installed a TPM module - grub was prevented from loading up my debian system because secure-boot got activated by default. I had to hunt around and de-activate to continue using the system.
This reminds me of the time where I think Samsung drives would do “hardware encryption” when using bitlocker on windows. And the encryption literally actually did nothing.
You should never trust that anyway. Apple has a similar thing which presumably works using the T2 chip to transparently encrypt everything going to the SSD, but they still use filevault to then encrypt the user data again.
Sounds like a good thing, insofar as it allows you to bypass the Windows requirement that Secure Boot be enabled. This should be good news for people running obscure Linux distros or other operating systems.
Might be better to disable it by default, though. Do other motherboards support this "feature"?
It's not good news for Linux distros. This setting breaks GRUB's expectations of shim being available when Secure Boot is enabled. Because of this, it will decline booting and will show you an error message.
IIRC EVGA and Gigabyte have "Audit mode" option in their firmware, which does only logging.
MacBooks have a much better feature where you can run MacOS in full security mode while having separate bootable partitions which are in permissive mode.
Much better than the all or nothing model of secure boot.
I have one of the affected motherboards, a B350 PC MATE: 7A34vALS. I'm glad. I just updated the CPU to a Ryzen 5 5500 (half the price of the 5600G, no "G", less L3, fine for my use case, and only $100 right now). It has TPM, so now I can upgrade to W11 (save it, don't want to hear the W11, don't care) but I need to turn on Secure Boot, which I haven't had a chance to examine yet. But now, I don't need to. MSI's implementation caters to people like me who don't need enterprise level security just to run an OS.
I believe that change is to enable Secure Boot by default. Changes like this and enabling the CPU-integrated TPM by default have happened all across product lines in the past year or so due to Windows 11 requirements.
I applied an update with that changelog line recently and it definitely now turns Secure Boot on (presumably in this "non-enforcing" state mentioned in the article) by default when it previously didn't.
This change is unrelated. E.g. 7C02v3F (2022-08-12) for B450 TOMAHAWK MAX had this line in the changelog, but 7C02v3C (2022-01-18) version also had this issue.
I have a Z97 board from ASUS that exhibits this behavior. It’s a bit ridiculous because there is no Secure Boot option in BIOS other than disable/enable.
I used to try to add ventoy's CA into the secure boot ca list. But due to one of the hard disks failed(the exact reason I use ventoy to boot an iso).The secure boot configuration just decided to hang every time I open it.
In the end I just disabled the secure boot all along. It's just broken and didn't work.
I have a over 10 years old second hand computer. Works great. But from the comments ... is it nowadays not possible to work without secure boot if I buy a new motherboard?
No, it's completely possible. You go into the BIOS and turn it off. Any BIOS that you can't turn it off is either defective, or it is meant for high security enterprise stuff (you have to pay extra for corporate laptops that only allow secure operation).
Most people who are building their own computer are not going to be an expert in UEFI and secure boot (some may have never even heard of these things). These people are almost guaranteed to need to install their own OS. So if they try, and it "doesn't work", they are going to need tech support or most likely return the motherboard as defective. Thus it makes more sense to make the default permissive.
On the other hand, someone who does want to run secure boot securely is probably an expert, so they can probably figure out how to actually turn it on and harden their setup. As long as you can lock stuff down, having these people jump through a few more hoops seems like a reasonable trade-off.
(Also FWIW, most pre-builts or integrated devices do have real secure boot enabled, since the expectation is that users of these will likely never need to install an OS that won't work with a strict secure boot enforcement policy.)