Hacker News Reader

Comment by AshamedCaptain | Hacker News Reader

The worst problem is that people are (even in the other discussion thread here on HN) still claiming that we are scaremongering. Back when all this Secure Boot was announced, we already said that its main purpose seemed to be to make booting of non-MS operating systems more complicated, rather than security enforcement.

"But, you're scaremongering! See, I put this Debian USB pendrive and I can still boot it fine!"

This was because Debian (and many other distros) went, at some point, through MS-enforced hoops in order to get their bootloader signed. Quite a perilous situation in which MS was this "steward" of the entire PC OS ecosystem; whether a Linux distribution booted or not on PCs was practically at the whim of MS. That was at least better than the alternative (no booting -- since MS got away with SecureBoot anyway) and we have to thank people like mjg59 for it.

Now, your Debian pendrive will not boot on this Lenovo PC, even if MS-signed.

"But, you're scaremongering! See, I put this Debian USB pendrive in, hit F1, hit cursor down three times, tab, down five times, space, F12, and I can still boot it fine!"

View on HN

Allowing the Linux bootloader is a security risk for consumer Windows devices. Microsoft foolishly doesn't enable Bitlocker on them, so the excellent rootkit protection secure boot provides gets wiped out entirely the moment you grab a copy of grub with your own chain loader. This is possible because a vulnerable version of Grub got signed at some point that allows loading unsigned code.

Secure boot should always be possible to turn off, and it should always be possible to load your own keys. 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. It defeats the entire point of requiring higher-than-kernel level permissions to alter the boot sequence.

Linux needs better secure boot key management features if it's serious about making secure boot work. Without it, just turn it off. It's a bit of a pain for new Linux users, but so is every other step of the way.

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

Of course not.

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.

>Then there's also the issue of managing certificate revocations.

Revocation updates are in the form of authenticated UEFI variable blobs. They can be applied regardless of OS and don't require a firmware update.

Ship with no certificates, and Trust on First Use the certificate of whatever OS is installed first.

There fixed it.

No extra hoops for any OS. Extra hoops if you wish to change OS, which could increase security>

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.

MS accounts are mandatory for all home editions of Windows, and likely soon to be for everything that's not an enterprise edition.

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.

For the record, Windows itself defaults to Bitlocker on, irregardless of OEM defaults, as long as the hardware has a TPM and modern standby.

Odd then that I've only in 1 out of a few hundred cases ever had to disable it after install in order to not have it run.

Turn SecureBoot off. Secure the UEFI and harddrive itself!

Requirements

State of he art UEFI implementation and usually a harddrive from the professional series. In case of a ThinkPad it should be possible for more than a decade.

How To

   1.) Set an UEFI-Password to protect the UEFI (formerly BIOS) itself
   2.) Set a Harddrive-Password within the UEFI, which requires a harddrive with built-in encryption

This protects the UEFI itself from manipulation, the bootloader, the kernel and the howl system. It is simple, therefore less error prone. Transparent to the operating-system, therefore any operating system is supported. It doesn't affect performance because professional harddrives actually encrypt always all data - they just don't ask for a key. You need to trust into the UEFI implementation and the harddrive manufacturer, which you hopefully do.

Bonus

No Certificate Authority (CA) and certificates involved. This reduces the error surface because it is error prone. You could even add LUKS (or whatever you prefer) on top of it. Because of the transparent built-in encryption you will not have a conflict. Probably a touch too much? But upon your decision.

https://support.lenovo.com/ie/en/solutions/ht002240

> You need to trust into the UEFI implementation and the harddrive manufacturer, which you hopefully do.

Trusting hardware encryption on consumer SSD's has been proven to be a pretty disastrous idea[0], with even Bitlocker disabling hardware encryption by default.

From what I understand, a lot of encryption implementations were really really bad, with massive security vulnerabilities and issues. I suppose if you're an enterprise you have the money to test if the SSD is actually encrypting the data on the NAND, but a consumer would be none the wiser.

[0]: https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-en...

Yes. I just didn't remember the specific models affeced:

    Crucial: MX100, MX200 und MX300
    Samsung: 840 EVO und 850 EVO

Curcial fixed it later with an firmware update. I think people got mad on Samsung because they didn't fixed it? Not affected where Intel, Micron, Samsung's own more expensive PRO-Series (interesting?) and others. We also rely on hardware based encryption on iPhones and Androids? Finally we need to trust the CPU and the random number generator, TPM, Pluton and that the keyboard or whatever is not manipulated. By the way - I don't trust Microsoft's Pluton! And interestingly Dell and Lenovo decided to turn it off by default.

> By the way - I don't trust Microsoft's Pluton!

I have to admit that I have hope for Pluton: it seems like it's going to increase the security of computing, which would obviously be beneficial to all of us. What they're talking about isn't exactly a new concept (I believe Apple call their the Secure Enclave) but it's one of those "Why didn't we have this already things?" where PC's just feel a bit behind.

The devices we're talking about here all have Bitlocker enabled by default.

I didn't know that, that's very nice. I appreciate that Microsoft is finally moving forward with offering encryption by default.

You might wanna read the article. It argues the very point you are making.

As someone that started with 8 and 16 bit computers, I am fine with single purpose computers.

Instead of giving money to Microsoft or Apple, support OEMs producing hardware with Linux pre-installed like Tuxedo and System 76.

That is not the point. The point is by employing dark patterns, Microsoft makes it progressively more difficult for normal users to switch away from Microsoft.

Want to switch default browser? Adding yet one more step to stop you.

Want to boot other operating system? Now you have to go to UEFI setup and change boot settings.

etc.

It is the point, it is like arguing to switch away from Spectrum, C64, Atari, Amiga, Acorn,.... back in the day.

PC only got out of control, because Compaq was clever on their reverse engineering process, and IBM failed to uphold their ownership.

Want to run Linux? Why go through the hassle of some Linux OEM when you can just keep Windows and run WSL?

This is exactly my problem with all of this. Microsoft makes a way to run Linux desktop programs on Windows, meaning that they DO care about the market share that _desktop_ Linux represents. At the same time, they make steps to make running actual desktop Linux OSes as inconvenient as possible, which incidentally makes WSL appear more and more convenient every time.

At this point, the simplest explanation is malice.

Well yes. Strategically, it makes all kinds of sense for them to force people who want to run Linux into their walled garden. Sure, you can run Linux, as long as it's safely contained inside Windows, an approved version, and preferably running something that requires Windows above you (e.g. DirectX inside WSL being a thin shim).

However, what makes sense for Microsoft may not be in our best interest.

It always was. There wasn't a day in the history of Microsoft that they were aiming for a level playingfield.

What they care about is the market share of the developers that buy Apple devices to develop UNIX applications, and couldn't care less about Linux itself, and are now not happy with the direction macOS is going.

WSL focus on Linux, because the Linux kernel ABI is the new POSIX.

This is correct of course but we can't ignore that Windows computer are ubiquitous nowadays. Alternatives like Tuxedo or System76 are either pricier or are missing options such as keyboard layouts, delivery to non US/CAN/AUS and European countries, world wide support (in your language). Also, people just know Windows. Those issues might go away in time but there's non-zero friction to acquiring Linux hardware imo.

As a former system-76 owner: it just sucks they are such low quality. All plastic, worse thermals then a 2018 mac book. Couldn't even decode a 720p youtube video without burning up. System 76 just rebrands some shitty chinese laptops and you notice.

I tried not giving money to apple, but it was money wasted tbh. Like seriously, $2k for a barely useable laptop.

> System 76 just rebrands some shitty chinese laptops and you notice.

This is manifestly not the case. Perhaps in the very early days but not in the last several years.

I thought they are still using rebranded Clevo laptops in their current product line? Not that it's inherently a bad thing, just curious to know.

They work with Clevo to develop them[3], and make the hardware work with Linux[0], preferably in firmware (so you don't generally need the System76 driver). They also set them up with CoreBoot and open source EC[1].

Although Clevo can sell their own version of the hardware, it is not really the same[2]

[0] Based on my experience. I ordered a laptop a long time ago and they explained they were working with Clevo to get the firmware fixed so that suspending worked reliably. This is before the OpenBoot + EC stuff came about.

[1] https://support.system76.com/articles/open-firmware-systems/

[2] https://twitter.com/jeremy_soller/status/1322954964549824512

[3] Clevo is System76's ODM. Most OEMs (e.g. Dell, HP) work with ODMs to put together the final product the OEM then offers. I posted the public Dell ODM list in another thread. System76 wanted to bring laptops in-house; I don't know the status on that. But System76 and Clevo work together to offer the final laptop based in a Clevo base[4]. And now (like, in the last 4 years) System76 started also adding open source firmware in some places.

[4] https://twitter.com/jeremy_soller/status/1322960532303872000

So basically helping making macOS more relevant than GNU/Linux on the desktop.

>As someone that started with 8 and 16 bit computers, I am fine with single purpose computers.

I'm also okay with single-purpose computers. Like the computer in the thermostat that controls the boiler, or the timer for the sprinklers. An OS-locked computer is still a general-purpose device, and describing it as "single purpose" muddies the waters.

> Instead of giving money to Microsoft or Apple, support OEMs producing hardware with Linux pre-installed like Tuxedo and System 76.

Why is this an "XOR" instead of "AND"? I prefer purchasing from OEMs that provide pre-installed Linux, AND I find it morally repugnant when manufacturers assert ownership over a device after having sold it.

> As someone that started with 8 and 16 bit computers, I am fine with single purpose computers.

No one should complain about regressing 30 or 40 years?

Given that most people using GNU/Linux praise using it as if it was UNIX V6, that shouldn't be an issue.

The wider problem is that, as long as Microsoft is superdominant in the PC market, Linux OEMs will still be affected by Microsoft's decrees, because they don't (yet?) have the influence of Apple to get fully custom hardware.

How could they when places like FOSDEM are full of people carrying Apple laptops.

while i absolutely agree with this sentiment, i feel like "Microsoft" as a boogeyman has become far more toothless since secureboot first took flight in 2006. the same people who clamored and wailed about secureboot on windows laptops snored through most of Apples worst laptop freedom offenses.

in 2022 there isnt an single manufacturer that doesnt offer (albeit sometimes sporadically) a Linux laptop. system76 and others exist to deliver the linux laptop and desktop, and Google flat-out refused to do any EFI on chromebook because, surprise, it wasnt really necessary. The average chromebook in 2022 has a cogent enough arm processor to handle daily compute on a wide variety of distros with ease.

Battlestation vendors like Asus will likely seek the rubber stamp for their laptop products that ship with windows, but for liquid cooled battle station geeks the same motherboards will ship with open EFI to run whatever keys you want to, or dont.

> Google flat-out refused to do any EFI on chromebook because, surprise, it wasnt really necessary. The average chromebook in 2022 has a cogent enough arm processor to handle daily compute on a wide variety of distros with ease.

Google is in no way a model to follow. They actually make it more complicated to install _native_ Linux than x86 PC manufacturers, what with their "developer mode", often ridiculous, physical hardware manipulation requirements to enable it, and non-removable Scary Boot Prompts unless you completely overwrite the full system firmware. In other words: Google is actually worse right now than MS would be on x86 even if they MS extended this Secured Core crap to all other PC manufacturers. It doesn't matter much that they use open-source firmware if they lock it down worse than the rest.

And "containerized Linux" like Crouton misses the point and anyway MS is doing it too! (so much for those who say MS does not care about the Linux desktop market share).

> those who clamored and wailed about secureboot on windows laptops snored through most of Apples worst laptop freedom offenses.

I've never had to buy an OSX computer in order to install linux on top of it. The same cannot be said of Windows.

Debian's images are not Secure Boot signed. You made that up.

Debian has shipped with a signed bootloader since version 10, released over 3 years ago.

I think they said the Debian boot loader was, not the whole OS image.

It's not even scaremongering at this point, it's just expired. Every 5 years or so something like this comes up, and it's used as another data point in the slippery slope that you all are so sure is happening. And yet, if I buy any random PC off the shelf in 2022, there's still a huge chance that it'll boot from a Linux ISO without having to jump through any hoops.

I think what's happening is, at some point in the past someone decided that there was a conspiracy to lock out Linux, and while that future hasn't come to pass, the total number of Linux-compatible devices keeps expanding, and therefore we keep getting examples of vendors locking things down too hard. These appear to be examples of the trend, but they're an increasingly small percentage of the total pool of Linux-compatible devices. It's the same thing that happened with Android. You can still root most phones, despite some being locked down. Things have reached an equilibrium. As I said in another post "there are more forces than Microsoft at work here".

The worst problem is that people are (even in the other discussion thread here on HN) still claiming that we are scaremongering.

Remember what some people on here (and elsewhere) work for. They either truly believe advancing the authoritarian corporatocracy is a good thing, have been brainwashed into doing so, or are just happy to have a job. These are the true enemies of your freedom.

Some of us saw this coming endgame ever since the "Trusted Computing" movement started, and how they slowly drowned out their opposition with propaganda. "Security" has become the go-to excuse for having their way with their power. The infamous Franklin quote has certainly taken on a new meaning.

I need an explicit list of public keys corresponding to the hardware roots of trust. From the article and prior reading it seems to be the hardware vendor's. Or are these in turn signed by Intel, AMD, ARM, ...?

i.e. which public key is actually burnt in the processor's eFuses?

A cryptographic break can always happen, and in such a cryptographically apocalyptic event i'd prefer to be able to author, sign and boot a minimal bootloader myself.

Have people ever gathered such listings?

EDIT: a secondary reason for maintaining such lists: key compromise can always happen, knowing when you need to replace your processor / computer because of a fundamental compromise would be mandatory. Also when buying hardware being able to observe historically compromised keys by vendor could give an indication of their security discipline.

I dont think it's a concerted effort to support corportocracy think it's just the just world fallacy.

It happens in all sorts of other domains too - the tendency to believe that things, by default, are the way they are for good and just reasons is strong in most people.

It happens in all sorts of other domains too - the tendency to believe that things, by default, are the way they are for good and just reasons is strong in most people.

For example, that’s why there are still ashtrays in new airplanes by default.

Does Google use Secure Boot on it's Chromebooks? Are you able to install whatever you want on them?

The OP is careful and measured. This comment is the opposite.

I actually paraphrased a lot of parts from the OP. I guess (guess because you don't mention the reasons why this is "not careful nor measured") you are one of these people who think that as long as there is some key combination that allows a Linux distribution to boot, there is no reason whatsoever to complain ?

Well, sorry, but no. I will sound the alarm way before the only way to install Linux (or any other OS) is to disassemble the laptop and hit some physical switch that will cause a Scary Boot Prompt to be permanently shown on my device, reminding me that I'm booting an "unsupported OS" and that "someone could be doing this to steal my personal data", and requiring me to acknowledge it by waiting 30 seconds before it proceeds to boot my actual OS. Every Single Time I boot the device. I will complain loudly way before we reach that on PCs.

Cause that's exactly what I had to do to run Linux on a Chromebook. And Google also seems to think that because they allow me to run some Linux distros under a heavily curtained container inside their OS, "all's good". Google does not get a free pass from me, why should MS?

And hardware will not allow that “unsupported” OS to access routable network.

Well, crud. With remote attestation, that could become a reality.

First it will be required for playing online games[0], then governments will require ISPs to enforce it for anyone who goes online.

Once people start side-loading to get around future bans on E2EE messaging apps, I expect governments will require OS vendors to implement blacklisting of such software even on desktops, using something like Apple's Gatekeeper service[1].

[0] https://www.pcgamesn.com/valorant/windows-11

[1] https://appleinsider.com/articles/20/11/15/big-sur-telling-a...

If you want a picture of the future, imagine a secure boot stamping on a human face — forever.

Agree. There's separate issues at play: the mechanism, what value it adds or subtracts and how it can be used. The critical component is allowing end users to control their own devices.

Fair disclosure, I've been involved in products supporting secure boot, have run my own laptop with my own keys such that only my signed stuff runs. I also have one of those Talos 2 boards and it also supports its own secure boot, even though all of the software all the way down to the firmware is open source.

So far Microsoft have actually been pretty reasonable: they enabled the shim in the first place. No Linux distros including heavyweights like Redhat or Canonical stepped up to undergo the requirements for default inclusion in the UEFI forum.

It always strikes me as a logical fallacy to argue against having a secure boot but then be pro end to end encryption. 'Secure boot is being used to oppress us therefore secure boot is bad' is as extreme a view as 'some awful human beings share csam so end-to-end bad'.

Ultimately in both cases the problem is societal and not technical. We need consumer rights protections so we don't end up renting our devices, and we need policing and community work to eradicate csam. Frothing at the mouth misinformed 'activism' comes across very badly to people outside the tech world we necessarily need to engage to make constructive policies for the future.

Your arguments strike me as inconsistent. You say we need consumer rights protections so we don't end up renting our devices, but then you criticize the comment that speaks up about a consumer rights problem.

> There's separate issues at play: the mechanism, what value it adds or subtracts and how it can be used.

The thing is, it's absurd to separate these issues. Look at it from the perspective of most users: Secure Boot is a solution to a minuscule problem. The vast majority of exploits happen in their browsers, office suits or due to social engineering (phishing, ransomware, adware).

So from the start, to sway the trade-off in favor to Secure Boot, the trouble it generates must be minuscule as well. And that is not the case: From the beginning Secure Boot has been a threat to free OS choice on PCs. Microsoft did not start by proposing a non-profit steward that will find good rules how code signing can be implemented and what rules you have to follow to be let in. That would have been "pretty reasonable". Instead they declared themselves rulers and it required a massive effort of the free software community to find ways to fulfill the requirements Microsoft unilaterally declared.

Being able to find a working process with Microsoft has generated some fragile trust, but all of that is in peril with news like Lenovo removing the Microsoft Corporation UEFI CA from their default installation.

If you would really care about letting the mechanism stand on its own without it being intermingled with politics (and I read that you care about that from the cited line) there is only one solution: Take the private keys to the Secure Boot certificates away from Microsoft and hand them over to neutral party. (And of course that will not happen, and thus the political and technical side remain deeply intertwined.)

> Secure Boot is a solution to a minuscule problem. The vast majority of exploits happen in their browsers, office suits or due to social engineering (phishing, ransomware, adware).

It's a minuscule problem right now because of SB. Why spend time and effort if it's likely you'll encounter a protected system.

If you give adversaries the possibility of implanting something deep into the boot chain, you've lost the entire battle. Obviously things that get exposed to untrusted content get exploited first, but no good attacker would leave it at that, especially if they want to create persistent malware and botnets. Exactly due to *Secure Boot* we aren't suffering from mass-spread malware like the ones that existed.

> massive effort of the free software community to find ways to fulfill the requirements Microsoft unilaterally declared.

Not really massive, mostly like absolute bare minimum, if you've read them. But okay.

> Take the private keys to the Secure Boot certificates away from Microsoft and hand them over to neutral party. (And of course that will not happen, and thus the political and technical side remain deeply intertwined.)

We could totally have a third root CA as well, if mandated or needed, but I haven't heard anyone pushing for it. Apple doesn't care and most Linux distros barely support existing Secure Boot which requires much less effort than running your own CA does.

> It's a minuscule problem right now because of SB. Why spend time and effort if it's likely you'll encounter a protected system.

It was a minuscule problem even before SB and even today still is without SB. For most people who are exploited up to the point were malware _can write directly to the boot hard disk_, "boot chain safety" is at that point the least of the user's problems. Their data is already uploaded to a Russian server, ransomware installed, their webcam turns on without the warning LED, and all their OS security including the root account has been compromised up to the point that the attacker can start erasing off-site backups without the owner even noticing (no need and no point to compromise the boot chain).

The only scenarios were boot chain integrity would apply are evil maid scenarios where the attacker can write to the boot disk externally, i.e. _not from the user's OS itself_, and these are way outside the worries of the immense majority of users. Correctly, IMHO.

> Not really massive, mostly like absolute bare minimum [effort], if you've read them. But okay.

> most Linux distros barely support existing Secure Boot which requires much less effort than running your own CA does.

This is a just cheap criticism (even insulting) without even providing any reasoning whatsoever. And I say that as someone who has criticized Linux distributions from trying to play under the arbitrary MS rules.

Most if not all Linux distros do their own CA already. They sign packages, after all.

> It was a minuscule problem even before SB and even today still is without SB.

This is just a cheap way to handwave the problem away without even providing any reasoning whatsoever.

It wouldn't be this minuscule if that attack venue wouldn't have been made so much less worthwhile. We have real life examples of these types of attacks, how are you seriously trying to claim that it wouldn't have gotten widespread? In what universe would malware makers agree not to abuse something so high-reward if allowed?

> For most people who are exploited up to the point were malware _can write directly to the boot hard disk_, "boot chain safety" is at that point the least of the user's problems.

It's not that absolute. It's certainly bad when things have gotten that far, but it doesn't mean it isn't a good idea to protect against deeper infection. "Oh they got infected, let's just abandon it all" is just so overly reductionist and is really of no substance.

> The only scenarios were boot chain integrity would apply are evil maid scenarios where the attacker can write to the boot disk externally

Blatantly false.

> This is a just cheap criticism without even providing any reasoning whatsoever.

It's not a criticism even, it's an astute observation.

> Most if not all Linux distros do their own CA already. They sign packages, after all.

That's an even worse look for them, then, bunch of those distributions not shipping at least a signed shim (MOK enrollment excluded for now) and a signed installer.

For now I'll also skip over the fact that your average distro's package signing is way below the standards a trusted commercial CA has to follow.

Specifically I'm critical of the original post labelling any 'it is actually ok' message on secure boot as 'scaremongering'.

> Instead they declared themselves rulers

This statement logically suggests that Microsoft laid down the law on secure boot and the impetus was entirely theirs and nobody could have done anything differently.

The UEFI forum was made into a public forum for the public version for x86. Before that it was a proprietary boot protocol designed by Intel mostly for itanium but also licensed to Apple for x86 (2010 era Mac minis use efi). Microsoft were not the originators, although I've no doubt they're contributors to this and secure boot.

Where Microsoft _do_ dictate is the Windows logo program, which is distinct from UEFI. This was the discussion originally on Matthew Garrett's blog: will they or won't they leave an 'off' option (practically they had to, to boot older windows and rescue disks).

Furthermore Microsoft's Windows logo requirements, while requiring OEMs to carry their keys on the basis OEMs want Windows logo, didn't exclude the likes of Redhat or Canonical from standing up a CA and getting included. There's some discussion of this on Matthew's older blog posts: https://mjg59.dreamwidth.org/6503.html?thread=194919 although I think there was a better discussion on OEM inclusion I can't find.

In other words we find ourselves where we are because everyone has been content for years to simply use the shim signed by Microsoft. Only Microsoft stood up a CA and underwent the due diligence. And you can't say a free CA can't be stood up, because letsencrypt went from zero to cab root programmes in this time.

The only issue in here that needs some care is forcing vendors to ship all approved CAs, not a minimum selection they care about.

Bootkits are a minor issue now as othe commentators have insinuated because of secure boot.

There are other advantages, too. With secure boot and tpms remote attestation of some systems at least becomes a bit more reasonable. You can also have the same bootkit resistance under Linux if you're prepared to put in a little bit of effort.

Sure if I had my way we'd have prioritized MTE/PAC over secure boot but there you are.

So let me sum up. Yes, what Lenovo is doing is bad, and if Microsoft are really proposing ditching third party signing then they deserve another massive antitrust suit. Looks like Matthew is again pretty much the only voice in the Linux world trying to make something practical work.

I am saying that it should always be the case that you can disable secure boot and it should always be the case that you can manage your platform keys. I also think they should ship the UEFI CA by default and offer the option to opt in to secure core as part of Windows' OOBE if they feel so compelled.

But there is a non profit neutral third party already and no Linux distro (or the Linux foundation) have pushed for CA inclusion that I know of.

UEFI and Secure Boot are here to stay unfortunately. That's not going to change (and that's more of a comment on the design of UEFI than SB).

Secure boot is opressive when you don't have the keys. So is encryption.

If someone else has the keys, you're not the owner, you're a renter.

My problem with the position of the "MS is bad" crowd here is that the security reasons are outright dismissed. It's even in the article:

> The second is that this is predicated on the idea that removing the third-party bootloaders and drivers removes all the vulnerabilities. In fact, there's been rather a lot of vulnerabilities in the Windows bootloader. A broad enough vulnerability in the Windows bootloader is arguably a lot worse than a vulnerability in a third-party loader, since it won't change the PCR 7 measurements and the system will boot happily. Removing trust in the third-party CA does nothing to protect against this.

Why is it 'all'? Why not 'some' vulnerabilities? Because then it's rather obvious that having one less bootloader allowed by default means less potential for vulnerabilities. And then the whole point breaks down.

> Because then it's rather obvious that having one less bootloader allowed by default means less potential for vulnerabilities.

Even if this was true, the fact that this defaults to having the MS signature enabled by default (and the other signatures have to enabled manually) should already make any security-oriented person shiver extensively, considering MS's vulnerability record. At least, it is clearly an (anti-)trust issue, which is already grounds to dismiss the entire idea.

Second, the fact that it may reduce the attack surface by an infinitesimal amount, and not even in paper (since the attack surface is still theoretically the same), is really an argument for it? By the same logic, I can always argue for having 40+-character length passwords and other rather dubious practices, which by definition also improve security -- and these ones at least do so on paper. It's just that security people already know that this infinitesimal improvement just does not warrant the other can of worms that such an approach opens, i.e. it is not worth the trade-off.

And third, there are better ways to reduce the attack surface to an even lower level; ways that do not put a single vendor in control of the security of the entire ecosystem. Claiming "this is one way, we should do it!" is textbook politician's fallacy.

I will note that this crap hasn't worked for Apple when arguing why they should remain an steward of the entire Apple software ecosystem , and it shouldn't work for MS, either.

Bootloader attacks are neither common, nor does it seem likely that "secure boot" keeps out a really determined attacker. Why spend so much effort on such a relatively useless feature unless there is another reason for it?

> Why spend so much effort on such a relatively useless feature unless there is another reason for it?

Because it's not only Secure Boot really. It's just one part of a larger set of firmware hardening methods called Device Guard (since 2016), which is also a part of Secured Core. (which was mentioned in the article).

> Bootloader attacks are neither common, nor does it seem likely that "secure boot" keeps out a really determined attacker.

Because an increasing amount of PC's have Secure Boot enabled and few attacks really are conducted by a "really determined attacker".

> Because an increasing amount of PC's have Secure Boot enabled and few attacks really are conducted by a "really determined attacker".

But these few attacks are the only ones against which "secure boot" might help, and it probably doesn't. Bootloader attacks were extremely rare to nonexistent even before "secure boot".

> Bootloader attacks were extremely rare to nonexistent even before "secure boot".

Playing devil's advocate: boot sector viruses were common back then. Secure Boot completely avoids both them and their UEFI equivalent, which is probably why we don't see them anymore.

It's not really devil's advocate. It's no longer trivial and is increasingly less so, for random malware that has acquired high privileges to compromise the entire boot sequence.

Boot sector viruses were already hardly common before Secure Boot. Practically since anything that is not MS-DOS-based, it is not that easy to write to the hard disk boot sector from a running operating system, and if you can do so, then it is much easier to write your payload somewhere else in the host OS (with all the OS functionality at your disposal) rather than the boot sector.

> Boot sector viruses were already hardly common before Secure Boot. [...] t is not that easy to write to the hard disk boot sector from a running operating system,

I wonder why... could it be that even then the risk was understood and there were attempts to mitigate? I hope you remember the option in BIOS called "Master Boot Record Protection".

Your "it's uncommon now, so it must not be a problem" argument is tedious at best. Precautions were taken, the worst case has been avoided and that's not an argument supporting not having any precautions.

> then it is much easier to write your payload somewhere else in the host OS (with all the OS functionality at your disposal) rather than the boot sector.

Sure, as long as you can launch before the AV or perpetually keep it at bay without making noise. Getting your malware to run sooner or even as part of the system gives you a very valuable advantage. It's ridiculous to even imply that it wouldn't have become a big problem.

> I hope you remember the option in BIOS called "Master Boot Record Protection".

Well you obviously don't remember it. This option was from the DOS era and would have done absolutely nothing for a protected mode OS like Windows since 9x much less NT.

> Precautions were taken, the worst case has been avoided and that's not an argument supporting not having any precautions.

The main precaution here is that operating systems stopped allowing unprivileged executables from writing to the boot sector. That's what made sector boot viruses disappear. That is my point, and anything else is élucubrations on your part. Sector boot viruses were most definitely not a common thing when SB appeared.

> Sure, as long as you can launch before the AV or perpetually keep it at bay without making noise.

What? Do you think the AV is going to let you write arbitrarily to the hard disk but apparently not do any other destructive/ malware action ? I don't know what type of operating system you are running, but most likely it will prevent writing to the boot sector to all unprivileged processes, AV or not. To overwrite the boot loader you literally would need to beat OS level security AND any potential AV, while for most malware payloads users worry bout you only need to beat the AV since the OS couldn't care less.

> it's rather obvious that having one less bootloader allowed by default means less potential for vulnerabilities.

Ok, so why not allow me to remove the Windows bootloader and just have the third party one that I trust more?

Because Microsoft doesn't trust it more, and they know better what's good for you.

You still are scaremongering.

Secured core is a class of device security specifically intended to be highly locked down.

From https://docs.microsoft.com/en-us/windows-hardware/design/dev...:

> Secured-core PCs provide protections that are useful against sophisticated attacks and can provide increased assurance when handling mission-critical data in some of the most data-sensitive industries, such as healthcare workers that handle medical records and other personally identifiable information (PII), commercial roles that handle high business impact and highly sensitive data, such as a financial controller with earnings data.

> For general purpose laptops, tablets, 2-in-1’s, mobile workstations, and desktops, Microsoft recommends using Security baselines for optimal configuration. For more info, see Windows security baselines.

But it is untrue that these devices are particularly secure, especially compared to the average linux distribution. This is Microsoft marketing and nothing else. On the contrary, the case for security is not to use MS systems because one of the largest threats for industry is industrial espionage and a lot of Microsoft components and data retention cannot be audited.

Boot sector attacks have become quite rare and a sensible threat analysis is the basis of good security. Otherwise you could sell any crap as security. Unplugging your keyboard stops a lot of attacks actually...

I don't see why Microsoft working to make an extremely locked-down class of devices should be taken as evidence that Microsoft isn't working to lock down devices, or that they wouldn't have an incentive to lock down devices.

That's not what the person they replied to said though. Providing the means to harden a device do not mean you can't boot non-MS operating systems. It does show intent to harden devices yes, but not what was replied to.

Placing additional obstacles to installing your choice of OS, even if each one is individually justified, leads to an veritable steeplechase of obstacles in doing so. By placing more and more restrictions on the default, each of which must be individually researched and disabled, fewer people are able to exercise their choice. There doesn't need to be a definitive deathblow if you can bleed away the opportunity to choose.

> Placing additional obstacles to installing your choice of OS, even if each one is individually justified, leads to an veritable steeplechase of obstacles in doing so.

It's a huge stretch to call a single toggle in UEFI an "obstacle" if you're already competent enough to install an OS from scratch. Maybe the focus should be on that, how to provide preinstalled Linux instead.

> each of which must be individually researched and disabled

Or you read the user manual.

Hurdles like these are why "competent enough to install an OS" is considered a bar in the first place. I agree that it is good when OEMs offer Linux preinstalled, but that doesn't absolve Microsoft from adding obstacles in cases where OEMs do not.

Reading the user manual is a form of research that must be done. When software doesn't allow an action, and doesn't immediately explain what can be done to override the restriction, that's a form of additional research.

> we already said that its main purpose seemed to be to make booting of non-MS operating systems more complicated

is literally on the first paragraph of my comment.

Only when MS allows booting "vetted" non-MS OSes _with the same amount of effort_ as it takes to boot MS OSes (like what they do already in other devices) there is any minimal chance of believing this is for security, and not for pure market control.

If they wanted to have a setting to control whether to block non-MS OSes to boot, they could have put THAT as the hard-to-find option, rather than the opposite. They would not have needed to make an entire class of separate hardware whose only difference is apparently that by default it boots MS OSes only, and who knows how is being pushed behind the scenes.

> "But, you're scaremongering! See, I put this Debian USB pendrive in, hit F1, hit cursor down three times, tab, down five times, space, F12, and I can still boot it fine!"

Because yes, one extra option in UEFI settings is the end of Linux on the Desktop. People definitely do not change anything else in UEFI settings ever as Linux users and it's significantly more complex than before. /s

But that's not true, is it? Changing DG or SB toggle is no more difficult than setting the system's clock or boot order. These things are also described in the manual. People installing any OS fresh are likely to have the skillset necessary to do so.

> Back when all this Secure Boot was announced, we already said that its main purpose seemed to be to make booting of non-MS operating systems more complicated, rather than security enforcement.

This is not Secure Boot per se, it is Device Guard. It's quite misleading to call it Secure Boot. If you read up on what Device Guard tries to achieve you should be able to see how it as a whole does provide noteworthy security improvements.

> Now, your Debian pendrive will not boot on this Lenovo PC, even if MS-signed.

*Please* do go on how you're not scaremongering here or in the previous thread. That sentence is literally false.

> This is not Secure Boot per se, it is Device Guard. It's quite misleading to call it Secure Boot. If you read up on what Device Guard tries to achieve on Secured Core PC

As clearly mentioned in the TFA, this is Secure Boot itself and has nothing to do with Device Guard.

Yeah and it is incorrect. Disabling that CA is a part of Device Guard requirements since 2016. Obviously Secure Boot enforces its configuration, but it's specified and set as such due to Device Guard.

Reply on news.ycombinator.com