> for consumer Windows devices. Microsoft foolishly doesn't enable Bitlocker on them
Actually, Microsoft enables Bitlocker on many if not most consumer devices. For example, I have not been able to find a laptop without Bitlocker enabled by default since the Windows 8.1 era. Even home editions of Windows enable bitlocker by default, even if they don't call it Bitlocker (they call it "Full device encryption" or the like). On desktops the situation is the opposite -- until recently, most desktops didn't even ship with a TPM at all.
Nowadays TPMs are a requirement for Windows 11, so devices with Bitlocker disabled by default are going to be a minority.
> I don't see the point of keeping it enabled on Linux if all of its protection can be disabled by editing a file on /boot.
That's not true -- if a distribution is shipping a signed bootloader binary, then there should be no way to use that distribution's bootloader to run an unsigned binary. In fact, it would be considered a security vulnerability and the corresponding bootloader binaries would be blacklisted by Microsoft. It has happened in the past: https://www.suse.com/support/kb/doc/?id=000019892 . The default behavior of most distribution's GRUB2 (and specially whenever it is pre-enrolled into a signed shim) is that when you boot under Secure Boot it will check the signature on any UEFI executable, GRUB module, or Linux kernel you try to boot, and refuse to boot if it is not in the (UEFI firmware/shim) whitelist.
> Linux needs better secure boot key management features if it's serious about making secure boot work.
Linux already has multiple secure boot key management facilities. And then there's shim.
But in any case, the problem is that Microsoft itself should be required to face these problems; under no circumstance should it be that by default MS gets their signatures to work for free but everyone else needs to have extra UI to manage them.
> I have not been able to find a laptop without Bitlocker enabled by default since the Windows 8.1 era
We use HP Pro/Elite Desk/Book at work. They arrive with Windows 10 Pro and with BitLocker disabled. They have had a TPM and everything for many years, now. Latest such PC I've seen was manufactured in February 2022 (Elitebook 840 G8).
> But in any case, the problem is that Microsoft itself should be required to face these problems; under no circumstance should it be that by default MS gets their signatures to work for free but everyone else needs to have extra UI to manage them.
The thing is that if the PC comes with Windows pre-installed, then the certificates should be enrolled. But if not, maybe there shouldn't be any certificate? I guess my point is that it's unreasonable to expect a manufacturer to ship a computer with a bunch of certificates. I'd even say that it wouldn't be that secure.
> I guess my point is that it's unreasonable to expect a manufacturer to ship a computer with a bunch of certificates. I'd even say that it wouldn't be that secure.
How exactly do you think a root trust should be established? Should it just boot up and start grabbing whatever certificates it thinks might be authentic over the network?
But the issue is that if there's a "root" certificate installed, then we're more or less in the current situation, where MS has that root certificate and anyone else who wants to have a bootloader must get it signed by MS.
Sure, there could be some kind of "neutral" entity in charge of this, but the issue remains.
Then there's also the issue of managing certificate revocations. Don't know how that works, currently. Maybe via firmware updates? But then, older computers are SoL.
Instead, what I think should be done, is to improve the workflow and documentation for installing one's own certificates. It's what I do on my own PC to run Arch (whose bootloader is not signed by MS) and I also signed MS's certificates so I can dual-boot. But the whole process is somewhat involved, it's not a simple "click a few buttons and you're done" kind of deal.
I am precisely typing this from an store-bought HP Elite laptop from 2017 (!) and it definitely came with Bitlocker enabled. In fact, HP explicitly says that all their laptops with modern standby (which again is most of them, and explicitly the Elitebook 840) come with Bitlocker on !! https://support.hp.com/us-en/document/c06458046
You could have said Acer or some other lesser-known brand and I would have not been able to counter, but HP? Are you sure "work" didn't configure Bitlocker to be disabled ?
> Are you sure "work" didn't configure Bitlocker to be disabled ?
Absolutely. I took the PC out of the box myself ("I am work") and I know we don't have our supplier do anything to the PCs before they send them to us, because we remaster them first thing.
My PC didn't go through that process because it's not one of the models everyone else uses and I don't use Windows.
---
edit: there's talk on a page referenced by your link about "Device Encryption" (as opposed to Drive encryption) which is activated when the PC is joined to a domain. This did actually happen, but out of the box the drive was not encrypted. The reason I know is because I went to enable regular Bitlocker but then stopped because I didn't have a separate drive on hand to save the recovery key.
> there's talk on a page referenced by your link about "Device Encryption" (as opposed to Drive encryption) which is activated when the PC is joined to a domain.
Device encryption, disk encryption, and Bitlocker are actually the same thing. The reason is that Windows Home doesn't have "Bitlocker" which means it can't do external (aka non-boot) disk encryption, so they call the resulting feature "Device encryption", but it's still Bitlocker.
My only guess is that you didn't login with a Microsoft account, since it is a requirement and "you don't use Windows". But obviously, the majority of people do login with a Microsoft account, and judging from HP's own support page plus the amount of people I can google claiming to have lost their recovery keys on the same laptop model you have ... I'm quite sure it is enabled by default.
> My only guess is that you didn't login with a Microsoft account
That's correct, I created a local-only account since the PC wasn't connected to any network.
However, I would have expected a feature "enabled by default" to not be tied to a specific type of account. I suppose that it would have to save the key somewhere, which works less well with local accounts.
Many business class PCs shipping with Pro versions of Windows do not have bitlocker enabled by default. We have a few hundred laptops and desktops in the validation lab I work in and very few of them shipped with bitlocker enabled.
Name a laptop model and we'll check. But do check the other thread too, I think you'd be surprised. I was surprised too -- it is practically guaranteed that on a laptop with a TPM and modern standby, Bitlocker will be enabled by default. In fact, a Windows install will default to on, ignoring the OEM setting.
I can't speak to anything newer than comet lake, but between my various HP elite books, elite desks, Dell optiplexes, latitudes, and Lenovo thinkpads, very few of them have shipped with bitlocker enabled by default.
As I mention on the other thread, I could believe Asus or Acer or some other cheap laptop disabling it because of gaming performance or whatever, but not the big brands.
I am quite familiar with HP itself, and in fact as I linked on the other thread they publicly claim that _all_ their laptops have Bitlocker enabled by default. Lenovo is the laptop of TFA, so they are definitely doing Bitlocker on their enterprisey laptops. My Dell Inspiron 5510 came with Bitlocker on out of the box, and perusing the Dell support site having articles about Bitlocker recovery as early as the WD15 docking station era, I am sure they are enabling it by default too.
I don't know what to tell you. Only going off my own experience. Maybe things have changed since Kaby Lake. Most of my systems are Kaby Lake or older. I only have the one comet lake Dell and at this point can't actually recall how it shipped since I've reinstalled the OS several times at this point.
Actually, Microsoft enables Bitlocker on many if not most consumer devices. For example, I have not been able to find a laptop without Bitlocker enabled by default since the Windows 8.1 era. Even home editions of Windows enable bitlocker by default, even if they don't call it Bitlocker (they call it "Full device encryption" or the like). On desktops the situation is the opposite -- until recently, most desktops didn't even ship with a TPM at all.
Nowadays TPMs are a requirement for Windows 11, so devices with Bitlocker disabled by default are going to be a minority.
> I don't see the point of keeping it enabled on Linux if all of its protection can be disabled by editing a file on /boot.
That's not true -- if a distribution is shipping a signed bootloader binary, then there should be no way to use that distribution's bootloader to run an unsigned binary. In fact, it would be considered a security vulnerability and the corresponding bootloader binaries would be blacklisted by Microsoft. It has happened in the past: https://www.suse.com/support/kb/doc/?id=000019892 . The default behavior of most distribution's GRUB2 (and specially whenever it is pre-enrolled into a signed shim) is that when you boot under Secure Boot it will check the signature on any UEFI executable, GRUB module, or Linux kernel you try to boot, and refuse to boot if it is not in the (UEFI firmware/shim) whitelist.
> Linux needs better secure boot key management features if it's serious about making secure boot work.
Linux already has multiple secure boot key management facilities. And then there's shim.
But in any case, the problem is that Microsoft itself should be required to face these problems; under no circumstance should it be that by default MS gets their signatures to work for free but everyone else needs to have extra UI to manage them.