Hacker News Reader

Comment by jabbany | Hacker News Reader

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.)

View on HN

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.

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.

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.

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.

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.

Nice, so MS gets better TPM-based assurance than anyone else.

Well, shim also measures whatever certs it uses, so it's not a complete loss.

But if anything other than shim, but signed by the same key, is used, then there’s no way to detect that, right?

Correct.

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.

It is in no way different than all other motherboards laptops. They all allow you to disable secure-boot.

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.

> 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.

> > that’s one hell of a user benefit

> Not for every user.

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.

… for now. Boiling the frog slowly and all that.

> 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.

[0]: https://mjg59.dreamwidth.org/59931.html https://news.ycombinator.com/item?id=32023868

[1]: https://techcrunch.com/2023/01/14/circleci-hackers-stole-cus...

[2]: https://xeiaso.net/blog/spearphishing

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.

https://arstechnica.com/information-technology/2015/03/windo...

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.

Of course Secure Boot wouldn’t magically stop all malware, it’s one security measure to stop bootkits and kernel tampering.

> Did secure boot stop those malware attacks?

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".

Thank you for the article.

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.

> Can you please link me some articles/references?

Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...

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

A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-...

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).

Thanks for more insight into this issue.

> 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.

[0]: https://news.ycombinator.com/item?id=34392834

[1]: http://xahlee.info/emacs/misc/emacs_macos_emoji.html

[2]: https://man.openbsd.org/gcc-local.1

> 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 :)

[1]: https://web.archive.org/web/20200709194653/https://github.co...

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.

[2]: https://web.archive.org/web/20210122132451/https://digdeeper...

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.

You know the tree by its fruit.

> 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.

> Scattershot malware (cryptolockers, miners) is incredibly common, one of our customers was hit several times (on systems we weren't managing).

Do you think secure boot stops cryptolockers? By what means?

> 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.

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.

>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.

[1] https://rufus.ie/en/

Rufus 3.17 (released Oct 2021) onwards is secure boot signed. See: https://github.com/pbatard/rufus/releases/tag/v3.17

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.

https://github.com/pbatard/uefi-ntfs

Edit: https://old.reddit.com/r/sysadmin/comments/pl2jqg/creating_b... This is the last time I read anything about it from the Rufus dev (which was over a year ago)

Because it was interesting, here's a summary:

• 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.

This is ridiculous. I hope the EU steps in and deals with microsoft's monopoly on default secure boot keys.

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'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.

> 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'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'm done with boot sticks after ventoy. bought a big one and just dump multiple isos into it.

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.

> 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.

> 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 just Lenovo to be honest.

Yeah, unfortunately Lenovo has moved on from secure boot to super-secure Windows-only boot.

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. :(

Aren't you sure what your talking about is not the key validation for the key used by the kernel to dynamically sign compiled DKMS modules ?

It's part of Secured Core spec to reject the 3rd party root. Same with other vendors implementing it.

> Most people are going to install Windows and Windows works out of the box with secure boot enabled.

Hum... I can't recall a single person that brought a personal computer and then installed Windows on it on the last 2 decades.

That happens with corporate computers, sure. But sysadmins know how to enable secureboot.

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 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.

> 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.

> 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.

> 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.

It will because Microsoft’s own Media Creation Tool splits the .WIM installation image accordingly since Windows 10 came out.[1]

1: This is what the media creation tool essentially does, but automatically: https://learn.microsoft.com/en-us/windows-hardware/manufactu...

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.

This doesn't actually make any sense to me.

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.

EDIT: Actually... the author may be wrong and, counter-intuitively, it may not break spec. https://news.ycombinator.com/item?id=34407911

Windows 11 requires secure boot to be enabled, at least during install. Perhaps it has something to do with that?

No, it does not, as far as I am aware.

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.

https://support.microsoft.com/en-us/windows/windows-11-and-s...

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.

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.

I've never managed to successfully change that setting back on my Surface Book 2. So that may be more correct than it seems at first.

The system is enabled, it just isn’t doing anything.

Secure boot is another solution seeking out a problem anyway.

It's not enabled. The only thing Secure Boot does is verify the OS integrity. If it isn't verifying it, it's not on. It's just reporting as on.

https://github.com/tianocore/edk2/blob/9ce09870e721efacc41fa...

Totally agree. MSI picked the right default for a PC component sold individually.

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.

And it’s there to disable if you don’t want it.

Reply on news.ycombinator.com