9 ms·

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 goin

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

toyg 4y ago
Totally agree. MSI picked the right default for a PC component sold individually.
gjsman-1000 4y ago
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 https://news.ycombinator.com/item?id=34407911
- jeroenhd 4y ago
  Windows 11 requires secure boot to be enabled, at least during install. Perhaps it has something to do with that?
  - gjsman-1000 4y ago
    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-secure-boot-a8ff1202-c0d9-42f5-940f-843abef64fad https://support.microsoft.com/en-us/windows/windows-11-and-s...
    - jeroenhd 4y ago
      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.
- Gigachad 4y ago
  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.
jeroenhd 4y ago
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.
- gjsman-1000 4y ago
  > 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."
  - jeroenhd 4y ago
    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.
    - vladvasiliu 4y ago
      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.
gruez 4y ago
>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/ https://rufus.ie/en/
- scrlk 4y ago
  Rufus 3.17 (released Oct 2021) onwards is secure boot signed. See: https://github.com/pbatard/rufus/releases/tag/v3.17 https://github.com/pbatard/rufus/releases/tag/v3.17
  - Sakos 4y ago
    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 https://github.com/pbatard/uefi-ntfs Edit: https://old.reddit.com/r/sysadmin/comments/pl2jqg/creating_bootable_usb_drives_with_rufus_requires/hcb9tw6/ 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)
    - mook 4y 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.
arsome 4y ago
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.
- gjsman-1000 4y ago
  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.
  - helloooooooo 4y ago
    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.
  - joerichey 4y ago
    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.
    - mjg59 4y ago
      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.
g_p 4y ago
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.
- jabbany 4y ago
  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. )
smileybarry 4y ago
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.

toyg 4y ago

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

gjsman-1000 4y ago

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 https://news.ycombinator.com/item?id=34407911

jeroenhd 4y ago
Windows 11 requires secure boot to be enabled, at least during install. Perhaps it has something to do with that?
- gjsman-1000 4y ago
  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-secure-boot-a8ff1202-c0d9-42f5-940f-843abef64fad https://support.microsoft.com/en-us/windows/windows-11-and-s...
  - jeroenhd 4y ago
    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.
Gigachad 4y ago
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.

jeroenhd 4y ago

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.

gjsman-1000 4y ago
> 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."
- jeroenhd 4y ago
  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.
  - vladvasiliu 4y ago
    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.

gruez 4y ago

>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/ https://rufus.ie/en/

scrlk 4y ago
Rufus 3.17 (released Oct 2021) onwards is secure boot signed. See: https://github.com/pbatard/rufus/releases/tag/v3.17 https://github.com/pbatard/rufus/releases/tag/v3.17
- Sakos 4y ago
  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 https://github.com/pbatard/uefi-ntfs Edit: https://old.reddit.com/r/sysadmin/comments/pl2jqg/creating_bootable_usb_drives_with_rufus_requires/hcb9tw6/ 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)
  - mook 4y 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.

arsome 4y ago

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.

gjsman-1000 4y ago
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.
- helloooooooo 4y ago
  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.
- joerichey 4y ago
  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.
  - mjg59 4y ago
    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.

g_p 4y ago

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.

jabbany 4y ago
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. )

smileybarry 4y ago

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.