Sounds like the same anti competitive behavior that MS was punished for two decades ago. Making it a requirement to only boot software approved by them excludes a whole range of competitors from using the same hardware. Making that a condition for OEMs to even get a license is the problem here.
Lenovo is otherwise known for supporting Linux on their laptops. And yes I know you can jump through hoops and fiddle with scary (for ordinary users) bios options to "fix" this. The point is that you shouldn't have to and this is a bit too convenient for MS to keep competitors off laptops.
Basically, what is needed here is a neutral certificate authority not controlled by a single company with a reasonable process for independent operating systems to get a certificate.
I recently ran into this trying to boot linux on my old imac. Ubuntu actually works but forget about arch, manjaro, and a whole lot of other distributions. Imacs have no off-switch for secure boot that I know off.
Not disagreeing with the general message, but IMHO if a user is willing to go through the hassle of installing another OS, as easy as it is nowadays, I don't think toggling a bios option is _that_ big of a deal.
As far as I'm concerned as long as it's possible to re-enable the 3rd Party CA (or disable Secure Boot altogether) it's not tragic considering this only applies to a specific kind of machines ("Secured Core PCs") and not to mainstream ones
The real problem is lately we've been seeing malware that lives in UEFI from APT (Edit: Advanced Persistent Threat actor, usually state sponsored) groups. That means it is persistent and will typically disallow updating the UEFI once infected. And almost everyone hates OS updates, and the smallest percentage are willing to update firmware, because it can brick a device, so UEFI isn't going to get updated. This is one of the few things you MUST trust, even if you want to follow zero trust.
>I recently ran into this trying to boot linux on my old imac. Ubuntu actually works but forget about arch, manjaro, and a whole lot of other distributions. Imacs have no off-switch for secure boot that I know off.
Does it also not let you use your own keys? Because if it does, you don't have to turn SB off, just use your key to sign the UKI and a bootloader like systemd-boot. It should work with any distro, especially one that uses dracut to create the initramfs because it's a couple of lines of dracut config to generate a (signed) UKI instead.
My new Microsoft Surface Book let’s me switch to 3rd party CAs or even none at all, with no problem. This sounds like a Lenovo issue.
On top of that, I would prefer if my machine is by default, in a secure configuration when I buy it. Since the laptops come with Windows pre-installed and Microsoft signed bootloaders, it is fundamentally more secure than if the 3rd parties CAs are enables. I don’t want an attacker chain loading Linux and KVM beneath my Windows OS.
Digital-locks like UEFI signing have a singular flaw, in that it only truly offers security to the people holding the signing keys i.e. a firm that did not pay for the computer, shouldn’t be tying unsolicited services to other peoples businesses, and should be classified as an adversarial threat vector.
If Libreboot wasn’t such a pain to install, it would have saved a lot of grief.
> in that it only truly offers security to the people holding the signing keys i.e. a firm that did not pay for the computer
That's not true. Practically all servers and more high end motherboards (even my HP zbook allows it) allow you to install your own CA's. Allowing you to create your own trust chain from firmware to OS.
By itself there is nothing wrong with wanting a chain of trust between firmware and OS.
> Given the association with the secured-core requirements, this is presumably a security decision of some kind. Unfortunately, we have no real idea what this security decision is intended to protect against.
Isn't secure boot attempting to protect against 'evil maid' attacks?
After all, the evil maid can come in on Day 1 and insert a bootable USB stick which boots a linux distro customised to look like the normal Windows boot and save your password when you enter it; then on Day 2 boot the computer normally and use that password.
If you want to protect against that, you need password-protected BIOS settings to enable/disable booting third-party code.
(Personally I see adopting the TPM as a fool's errand - I don't think it can ever deliver on its promises)
The standard response is that after entering the password the user will notice that the boot fails to complete to the expected Windows instance. In a high security environment this boot failure should immediately be flagged and investigated and the machine considered compromised.
Yes, it's likely to stop evil maid attacks. But keylogging is just one attack vector. If you can boot to Linux, you can clone a copy of the user's data, to be decrypted with a cluster off-site.
As shitty as it is, it's nice of Lenovo to at least make it easy to enable the second CA. I wonder if all OEMs will be as "nice", or if any will require you to boot into Windows just to edit the EFI variables to add the second CA.
Edit: Also, I've read a few horror stories of systems no longer displaying anything after the UEFI CA was removed from the trusted CAs, because there was no iGPU and the discrete GPU required an OpROM. No display meant no way to boot into the UEFI firmware to revert that change or even disable SB. How is that not a problem now?
There used to be a requirement by MS mandating secure boot to be disable-able. Though I think they scrapped that requirement later on. No idea if third party CA enabling also has such a requirement.
On the early Surface Pros at least, you had to boot into Windows and run a PowerShell script to enable the MS UEFI CA certificate. These days it looks like they made it a option on the system firmware.
We're now at the final stage of conspiracy theory damage control with respect to the idea that Microsoft is trying to lock down the PC platform and prevent non-Windows operating systems from booting:
1. It's not happening, I don't know what you're talking about, anybody who believes that has been radicalized by Russian propaganda
2. Well, yeah, maybe it is happening here and there, but it's no big deal, and it's certainly not through a coordinated effort on our part
3. Yes, it's happening, it's been happening all this while, and here's why it's a good thing <-- we are here
We all will have to reckon with the fact that general purpose computing is going bye-bye. The interests of OEMs and ISVs in delivering a safe, consumable experience to end users are aligned against allowing unsigned, unapproved software from running. And yes, the OEMs, ISVs, and probably most of the consumer market will believe that this is a good thing. The next big thing is remote attestation: the internet will simply stop working properly on your machine unless it can prove that it is running an approved OS and application stack.
You don't understand! Nadella's Microsoft open-sourced a few applications and created a popular text editor, which makes him basically the second coming of Christ in the eyes of a large portion of HN users.
Their numerous anti-user and anti-privacy practices are unimportant. Nadella's Microsoft is "cool" and that's all that matters.
I agree, and I don't know why anyone would disagree sufficiently strongly to downvote your comment for suggesting that. Microsoft being directly in control over what can boot by default on PCs was and still is a blatant conflict of interest, and transitioning that decisionmaking to an independent body with input/control from more than just Microsoft would alleviate that considerably.
This seems to be MS's response to a rather serious mistake in GRUB2 - a howler, I'd say.
I've never liked GRUB2 much. The configuration seems to freely mix executable code and data, which makes me tremble at the prospect of altering it. And I find it much harder to understand than GRUB Legacy (and that's saying something).
The moment systems like TPM and secureboot were added it stopped being our hardware. We said as much back then, sabotage like described here show that analysis was right.
There is nothing that can be done as long as there is a processor duopoly that follows these ms requirements.
You can buy the Linux editions of your hardware, at least for laptops, to show that there's a real need for Linux support out there, however small it may be in practice. Or you can buy System76 or similar hardware to guarantee actual Linux compatibility rather than the manufacturer saying "it boots so let's ship it".
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!"
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.
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.
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.
Does this reflect the same sort of issues in the browser password protection space, i.e. Since last year chrome by default links to google password protection in short words you have to do extra steps to link google accounts to non-google Chrome browsers.
They say security but there is an underlying Elephant in the room concern that keeps rearing it's head.
TLDR: So essentially, if the Lenovo laptop does not allow to boot on linux (or anything that is not Microsoft sanctioned) by default without a modification of the boot options, this is not because of Lenovo but because, in order to be certified by Microsoft, Lenovo has to comply with a set of rules that are not public and as such, impossible to follow for non-Microsoft entities.
Edit: So, as Arnavion commented right below, my TLDR is incorrect inasmuch the fact that Microsoft requirements are not public only prevent us to understand why this change was made.
>a set of rules that are not public and as such, impossible to follow for non-Microsoft entities.
This is not correct, in that there's nothing for "non-Microsoft entities" to do in this situation regardless of whether the rules are public or not. The only CA that non-Microsoft bootloaders can be signed by is the UEFI CA, and that is not going to change. At least not in the sense that non-MS bootloaders could ask to be signed by the CA that signs Windows (the one that's still trusted by default), because it has obviously always been intentional that Windows was signed by a different CA than the common rabble.
The only piece of information we're missing, and which having the docs become public would reveal, is why this change needed to be made, so that we can then either sulk about it or try to get it reverted or resolved in some way.
Edit: Note that SB has had a revocation list concept built-in since the beginning, and this list is designed to be serviceable by regular OS updates (the OS can just modify the EFI vars, no manual firmware flashing required like it was with BIOS). So it was not a problem even if some bootloaders got signed that shouldn't have. That's why it's weird that such a drastic approach is being taken.
At what point will mjg59 be willing to write the whole thing off as the anti-Linux measure that most open source fans have realised it is for a decade or more?
Why is this being moaned about because of one bad machine _again_.
As much as i love to lay into Microsoft I see little reason to yet, other than speculation and corporate bad practice brought on by massive corporate incompetence, no grand conspiracy…
[+] [-] jillesvangurp|3 years ago|reply
Lenovo is otherwise known for supporting Linux on their laptops. And yes I know you can jump through hoops and fiddle with scary (for ordinary users) bios options to "fix" this. The point is that you shouldn't have to and this is a bit too convenient for MS to keep competitors off laptops.
Basically, what is needed here is a neutral certificate authority not controlled by a single company with a reasonable process for independent operating systems to get a certificate.
I recently ran into this trying to boot linux on my old imac. Ubuntu actually works but forget about arch, manjaro, and a whole lot of other distributions. Imacs have no off-switch for secure boot that I know off.
[+] [-] Kipters|3 years ago|reply
As far as I'm concerned as long as it's possible to re-enable the 3rd Party CA (or disable Secure Boot altogether) it's not tragic considering this only applies to a specific kind of machines ("Secured Core PCs") and not to mainstream ones
[+] [-] downrightmike|3 years ago|reply
[+] [-] Arnavion|3 years ago|reply
Does it also not let you use your own keys? Because if it does, you don't have to turn SB off, just use your key to sign the UKI and a bootloader like systemd-boot. It should work with any distro, especially one that uses dracut to create the initramfs because it's a couple of lines of dracut config to generate a (signed) UKI instead.
[+] [-] helloooooooo|3 years ago|reply
On top of that, I would prefer if my machine is by default, in a secure configuration when I buy it. Since the laptops come with Windows pre-installed and Microsoft signed bootloaders, it is fundamentally more secure than if the 3rd parties CAs are enables. I don’t want an attacker chain loading Linux and KVM beneath my Windows OS.
[+] [-] mjg59|3 years ago|reply
[+] [-] Joel_Mckay|3 years ago|reply
If Libreboot wasn’t such a pain to install, it would have saved a lot of grief.
[+] [-] jsiepkes|3 years ago|reply
That's not true. Practically all servers and more high end motherboards (even my HP zbook allows it) allow you to install your own CA's. Allowing you to create your own trust chain from firmware to OS.
By itself there is nothing wrong with wanting a chain of trust between firmware and OS.
[+] [-] trelane|3 years ago|reply
Dunno if you need LibreBoot specifically, but if CoreBoot is sufficient, several vendors offer it preinstalled....
[+] [-] Arnavion|3 years ago|reply
("Please stand by, while we are checking your browser... Please turn JavaScript on and reload the page." No thanks.)
[+] [-] michaelt|3 years ago|reply
Isn't secure boot attempting to protect against 'evil maid' attacks?
After all, the evil maid can come in on Day 1 and insert a bootable USB stick which boots a linux distro customised to look like the normal Windows boot and save your password when you enter it; then on Day 2 boot the computer normally and use that password.
If you want to protect against that, you need password-protected BIOS settings to enable/disable booting third-party code.
(Personally I see adopting the TPM as a fool's errand - I don't think it can ever deliver on its promises)
[+] [-] phh|3 years ago|reply
The evil maid will need less time to replace the computer with another one that looks alike the original one, than to install a Linux distro
[+] [-] 323|3 years ago|reply
[+] [-] phendrenad2|3 years ago|reply
[+] [-] Arnavion|3 years ago|reply
Edit: Also, I've read a few horror stories of systems no longer displaying anything after the UEFI CA was removed from the trusted CAs, because there was no iGPU and the discrete GPU required an OpROM. No display meant no way to boot into the UEFI firmware to revert that change or even disable SB. How is that not a problem now?
[+] [-] jsiepkes|3 years ago|reply
[+] [-] AshamedCaptain|3 years ago|reply
[+] [-] bitwize|3 years ago|reply
1. It's not happening, I don't know what you're talking about, anybody who believes that has been radicalized by Russian propaganda
2. Well, yeah, maybe it is happening here and there, but it's no big deal, and it's certainly not through a coordinated effort on our part
3. Yes, it's happening, it's been happening all this while, and here's why it's a good thing <-- we are here
We all will have to reckon with the fact that general purpose computing is going bye-bye. The interests of OEMs and ISVs in delivering a safe, consumable experience to end users are aligned against allowing unsigned, unapproved software from running. And yes, the OEMs, ISVs, and probably most of the consumer market will believe that this is a good thing. The next big thing is remote attestation: the internet will simply stop working properly on your machine unless it can prove that it is running an approved OS and application stack.
[+] [-] option_key|3 years ago|reply
Their numerous anti-user and anti-privacy practices are unimportant. Nadella's Microsoft is "cool" and that's all that matters.
[+] [-] aosmith|3 years ago|reply
[+] [-] usr1106|3 years ago|reply
[+] [-] yellowapple|3 years ago|reply
[+] [-] justinclift|3 years ago|reply
[+] [-] denton-scratch|3 years ago|reply
I've never liked GRUB2 much. The configuration seems to freely mix executable code and data, which makes me tremble at the prospect of altering it. And I find it much harder to understand than GRUB Legacy (and that's saying something).
[+] [-] password4321|3 years ago|reply
> Load Linux directly as an EFI executable via the EFISTUB approach.
> the "Using UEFI directly" section [...] https://wiki.archlinux.org/title/EFISTUB
[+] [-] peter_retief|3 years ago|reply
Big question is how do Microsoft get away with this bullying of hardware manufactures, probably the fear of losing business.
What can we do to stop this?
[+] [-] onli|3 years ago|reply
There is nothing that can be done as long as there is a processor duopoly that follows these ms requirements.
[+] [-] jeroenhd|3 years ago|reply
[+] [-] pjmlp|3 years ago|reply
[+] [-] james-redwood|3 years ago|reply
[+] [-] Harvesterify|3 years ago|reply
[+] [-] AshamedCaptain|3 years ago|reply
"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!"
[+] [-] jeroenhd|3 years ago|reply
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.
[+] [-] pjmlp|3 years ago|reply
Instead of giving money to Microsoft or Apple, support OEMs producing hardware with Linux pre-installed like Tuxedo and System 76.
[+] [-] nimbius|3 years ago|reply
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.
[+] [-] bejelentkezni|3 years ago|reply
[+] [-] phendrenad2|3 years ago|reply
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".
[+] [-] userbinator|3 years ago|reply
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.
[+] [-] cptskippy|3 years ago|reply
[+] [-] fredgrott|3 years ago|reply
They say security but there is an underlying Elephant in the room concern that keeps rearing it's head.
[+] [-] xenophonf|3 years ago|reply
I don't see how anyone can look at the history of Microsoft and not immediately judge this as being completely anti-competitive in nature.
[+] [-] ysnp|3 years ago|reply
Where can we find the full requirements for a device to be Secured-core?
[+] [-] skywal_l|3 years ago|reply
Edit: So, as Arnavion commented right below, my TLDR is incorrect inasmuch the fact that Microsoft requirements are not public only prevent us to understand why this change was made.
[+] [-] Arnavion|3 years ago|reply
This is not correct, in that there's nothing for "non-Microsoft entities" to do in this situation regardless of whether the rules are public or not. The only CA that non-Microsoft bootloaders can be signed by is the UEFI CA, and that is not going to change. At least not in the sense that non-MS bootloaders could ask to be signed by the CA that signs Windows (the one that's still trusted by default), because it has obviously always been intentional that Windows was signed by a different CA than the common rabble.
The only piece of information we're missing, and which having the docs become public would reveal, is why this change needed to be made, so that we can then either sulk about it or try to get it reverted or resolved in some way.
Edit: Note that SB has had a revocation list concept built-in since the beginning, and this list is designed to be serviceable by regular OS updates (the OS can just modify the EFI vars, no manual firmware flashing required like it was with BIOS). So it was not a problem even if some bootloaders got signed that shouldn't have. That's why it's weird that such a drastic approach is being taken.
[+] [-] trasz|3 years ago|reply
[+] [-] lmm|3 years ago|reply
[+] [-] CaliforniaKarl|3 years ago|reply
> whenever a signed object is booted by the firmware, the trusted certificate used to verify that object is measured into PCR 7 in the TPM.
Is there a list somewhere of what each PCR is generally used for? I’ve had difficulty finding the information through Google searches.
[+] [-] mjg59|3 years ago|reply
[+] [-] dang|3 years ago|reply
Lenovo shipping new laptops that only boot Windows by default - https://news.ycombinator.com/item?id=32023868 - July 2022 (388 comments)
[+] [-] rob_c|3 years ago|reply
As much as i love to lay into Microsoft I see little reason to yet, other than speculation and corporate bad practice brought on by massive corporate incompetence, no grand conspiracy…