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
> 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.
It is trivially easy to boot from a USB pendrive; most computers will do it by default if there's no preinstalled OS, many devices have a hotkey you can press/hold which redirects towards booting from USB, and even Windows itself will outright let you do it from the Settings app. You don't even have to interact with the system firmware setup program.
On the other hand, disabling secure boot (or taking ownership of it) is designed to be as difficult as possible, intentionally. Many vendors will actually have a Scary Boot Prompt or the like which makes you double-acknowledge when you change Secure Boot settings, and even reminds you (on every boot) that you have Secure Boot disabled.
It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't. This puts a glass ceiling on non-MS operating systems regarding how easy their setup flow can be.
> It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't
Unfair? You're talking about systems that come with Windows pre-installed. Of course these systems are going to be configured for booting Windows out of the box.
>> It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't
>Unfair? You're talking about systems that come with Windows pre-installed. Of course these systems are going to be configured for booting Windows out of the box.
I think it more _accurate_ to have said "of course these systems are going to be configured to boot nothing but Windows out of the box", which is ... drum roll please.. anti-competitive. Facially, and blatantly anti-competitive.
You're correct of course. Fair would be you can return the license to microsoft on purchase and claim the entire value of your refund. Microsoft have been engaging in the clearest anti-competitive behaviour for decades and it is grossly unfair on consumers, competitors and the industry as a whole.
We really must not conflate "predictable behaviour" or "established behaviour" with "acceptable behaviour" in any part of life including corporate crime.
.. first read through all these comments here, but I see no mention of MSFT commercially inserting Canonical OS products into desktop windows, with extra features added to Ubuntu to restrict and control the internals.. examples are partition type msft-private and msft-data; secretive systemd components; secretive vmx flag use; boot signing and signed applications; snapd container for libssh with auto-updates required to be on.. and more?
There's a difference between stick in a usb key to fiddle with bios in vendor specific way and then stick a usb key in. It's an extra hurdle.
If your instructions read: "turn off secure boot", MS has already won. Some users will, most won't, and many company IT departments would not allow you to on principle (because it's company hardware and they want it secured because it is their problem if it isn't).
This is an extremely weird argument. So called Live CDs come from an era where CD drives were ubiquitous and even back then installing an OS (provided you did not want to install two OSes at the same time) was as simple as installing any other piece of software. If anything, with all these secure boot shenanigans it requires more skill to install an OS than when a smartphone was not even a thing. This argument advocates for walled-garden IT. This argument used in support of restrictions under the hood arguments for IT stuff to be hard in principle.
Yes, the removal of CD/DVD-drives is as much of an obstacle to installing Linux as having to toggle a setting on a Windows-preinstalled machine that someone bought. You are also free to buy a SKU that doesn't come with a Windows license and Windows preinstallation.
Also please keep in mind that it's not Secure Boot you have to disable, it's a CA you have to re-enable on machines that came with Device Guard pre-enabled.
You miss the entirety of the point. Today you have a USB drive, nothing stops SOHO routers by default starting PXE server with latest distros which would be even easier to use. This is an artificial obstacle.
You keep arguing all over the place that this is an insignificant obstacle, but do not address the very core of the debate: whether only MS keys being installed by default is for security purposes in the first place and whether it does actually increase security. We are not arguing how many hoops to install Linux (or whatever) is too much. we are arguing whether certain OSes should be easier to install at all.
Don't bring it up as an obstacle if it's not an obstacle, that you're instead concerned about Microsoft's keys.
In that case though, it's not "only MS keys" really, it's not enabling one CA. In the end if there's a strong need, Canonical, Red Hat or the likes could start building their own CA and negotiate it to be included, would be very fair and probably wouldn't be affected by this toggle. But they do not seem interested however in the much easier MS UEFI CA-signed Secure Boot, Ubuntu does it fine, but Fedora can't sign DKMS modules and the rest are even worse.
So the thing is, the problem of "trust" is very complex and putting in the work is very expensive. Microsoft has chosen to do this to improve their customers' security, they offer others the opportunity to participate and few are actually willing. That's not their fault really.
In the end they'd get slapped so hard by antitrust if they ever truly removed that toggle and the option to run other software. (Unlike Apple or other mobile vendors, who can do whatever they wish, with no such uproar over what is way worse than the toggle discussed here.)
> Hurdle that doesn't matter at all. If you have the skillset to install an OS, changing a setting in UEFI is nothing.
That assertion is a bit too absolute; I am comfortable installing an OS using the USB installer because I have done it many times. I haven't had to change UEFI settings yet and I'm worried that doing something wrong will lock me out (in case of a botched OS install, I can just start over).
What matters more in this instance is the rhetoric and messaging being used. Microsoft is using "Secure-core" as a measurement and indicator of security posture while at the same time installing a Linux-based system somehow detracts from that objective. It's not just a matter of technical ability. Organizations and people, in general, will be exposed to this, which is simply not true. For enterprise IT, this will also mean that by default, they will need to justify alternatives, creating extra friction for competing solutions.
> Microsoft is using "Secure-core" as a measurement and indicator of security posture while at the same time installing a Linux-based system somehow detracts from that objective
If you read what Secured Core or even Device Guard consists of, Linux actually does detract from it. I use Linux daily on all my machines, I have no sympathy towards Windows at all, but Linux has certainly fallen behind in some aspects - boot integrity and boot anti-tampering is one of those aspects. And that's not all Secured Core provides in the end.
Linux has fallen behind in boot security and anti-tampering because all of the solutions in this area are proprietary and at least initially released under NDA. You're using the effects of this very program to justify itself.
Firstly, it wasn't a justification, it was a description of the current state.
Secondly, no, they aren't all proprietary. If we start from the bottom then Secure Boot is neither proprietary or NDA'd. There are even open-source implementations of Secure Boot. We simply have a significant amount of feet-dragging and misconceptions out there, pointlessly making using just SB alone difficult and not the default, you can see a bunch of it in this thread as well.
I won't even get into measured boot to auto-unlock FDE/LUKS or god forbid LIM, those aren't difficult because of some supposedly NDA'd specifications. Damn, enabling IOMMU isn't that difficult either. Nobody else should be blamed for the poor state of those.
Lastly, some standard being initially released under NDA or being proprietary (which ones do you actually have in mind?) is a terrible justification to not improve things. Or find alternatives just as good.
> some standard being initially released under NDA or being proprietary (which ones do you actually have in mind?) is a terrible justification to not improve things. Or find alternatives just as good.
I think them being NDA / proprietary is a reason we can't improve things, not a justification for it.
In this case it is an option, you can still disable UEFI Secure Boot, re-enable the UEFI CA and enroll your own keys. The only thing that changes is a default in an option you would need to alter in any case if you wanted to control the boot yourself.
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.
Firmware should have a physical switch to enable updating it. Fuck self checked signatures. There, fixed all the BIOS and firmware exploits for you. You're welcome.
Firmware vulnerabilities aren't necessarily used to target the firmware or to try to gain persistence - vulnerabilities in SMM handlers, for instance, can be used for privilege escalation at runtime.
Limit, but it doesn't remove all avenues of attack. Firmware config needs to be writable at runtime (things like cold boot attack protection require state to persist over power cycles, even if you don't think other firmware config should be modifiable without physical presence), and the code that parses that could still contain vulnerabilities. Making firmware mostly read-only would mitigate certain classes of attack, but not all of them.
I'm responding to "There, fixed all the BIOS and firmware exploits for you". It doesn't actually fix all the potential exploits, and it makes it more difficult to apply the updates that would be required to fix them.
That only works for IT-managed devices (and even then, is very expensive in terms of labor). Consumer devices need auto-update to protect them from known vulnerabilities. Auto-update is hard to get right, but your product is defective by design if it doesn't support it.
Sometimes firmware updates make the system worse or even completely bricked. If the machine already working and stable, I've learned it's a risky / bad idea to eagerly apply firmware updates.
Flash media is cheap nowadays, and HP EliteBook series laptops store a couple of previous BIOS versions on board to make rollback possible. Also these higher end laptops can try previous version of their firmware if they fail to boot with the latest one.
Failing to see how Lenovo can't implement something like that.
Bad idea because firmware bugs are a growing attack vector and you are leaving yourself exposed to known, easily-exploited vulnerabilities by not staying up to date.
I mean sure, but no one is forcing users to install software from APT groups. That's a choice people make. The general point is that you should be able to use hardware for general computing. There can be a switch that by default limits to software signed by your original manufacturer but that should toggleable by the end user.
OP probably misunderstood it as Advanced Pacakge Tool, the system Debian uses for package management (ie APT sources) instead of Advanced Persistent Threat which is what the quote is talking about (ie sophisticated hackers, usually state backed/state owned that attack your machine).
>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.
Not in a way that is obvious to me. I'm sure you can work around it but if you just want to boot a live image and run an installer, ubuntu works and not a whole lot of other distributions do (because their installers don't support secure boot). I assume this is because of how much of a PITA it is to get certified.
>I assume this is because of how much of a PITA it is to get certified.
Distros don't have to do anything distro-specific to get signed. Most distros use (Microsoft-signed) shim to chainload to something like grub.
But yes, it might be that the live CDs don't do that; I don't know. My experience with SB on all my machines has been to start with SB disabled and then I enable it afterwards with my own keys. I know the gparted and OpenSUSE live CDs support SB because I've booted off them after enabling SB.
You could boot the Ubuntu live CD (or something smaller like gparted), mount the other distro's live CD, chroot into it, and run the other distro's installer that way. Just be sure that you enable SB support so that the installation actually boots afterwards.
> Distros don't have to do anything distro-specific to get signed. Most distros use (Microsoft-signed) shim to chainload to something like grub.
You still have to get your own version of shim signed if you want your distro to boot "Scary Boot Prompt"-free. I.e. if you just use RedHat's version of shim, that shim will transparently boot RedHat signed kernels, but refuse to boot SuSE's -- unless you whitelist SuSE's key manually into shim. It's not ideal in any way.
I believe for OpenSUSE it uses MokManager to get the user to trust the OpenSUSE CA. But it's been a while since I tried it so I might be misremembering. (MokManager is broken on my mobo so I switched to systemd-boot + my own signing keys, which is better for security anyway.)
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.
>I don’t want an attacker chain loading Linux and KVM beneath my Windows OS.
If your Windows install was protected by Bitlocker, and the decryption key was stored in the TPM, and the TPM was set up to require attestation to unseal the key, then such chainloading wouldn't be an issue. (This is also explained in the article.)
BTW, the default for the firmware interface is that it is not password-protected, so even this particular Lenovo device is vulnerable to the evil maid attack you're describing in its "default secure configuration", because the maid can just toggle that option to enable the UEFI CA, or even disable SB entirely. Unless Lenovo is planning to make the UEFI password a required step in their purchase order process, you can expect that the default configuration is going to be an unprotected UEFI. That's why the way to resolve the threat is not to prevent other bootloaders, but to prevent them from reading the data on disk.
> It is still an issue. A different OS could load and mimic the normal boot procedure to steel any credentials entered.
What credentials? The bitlocker key is in the TPM. It's not something a human can enter.
>Also, the whole scenario you depict is quite unreasonable to expect of a default install - which is exactly what is being talked about.
I'm confused. Are you referring to the scenario of the Windows install with the bitlocker key in the TPM, or the scenario of the evil maid attack? The former is already how Windows works by default, and the latter is precisely the scenario that helloooooooo was talking about, so I'm not sure which one you're calling unreasonable.
Not really; most people unlock Bitlocker via TPM, that's why a shitton of people don't even realize they have it. If the TPM doesn't give up the key, you are asked for the _recovery key_, not a passphrase.
And the fact they have no clue what the "recovery key" is, that is how most people realize they had Bitlocker on...
MS actually keeps a copy of _your_ PC's recovery key on their servers when you install Windows; that's one of the official reasons they have for requiring a MS account when you set Windows up: so that they can store your recovery key for you and give it back to you if ask nicely. (Moral implications of this best left for another discussion). This is for the personal editions of Windows, in the business editions of Windows; your IT (via ActiveDirectory) will store your recovery key for you.
I know. So walk me through it, you turn on the machine. Windows boots, you are greeted with a login/password prompt. The user enters their password and now typically have access to everything of value on that machine.
You don't have anything of value on that machine, at least not yet. The user entered their Windows login creds into the fake prompt, but the Windows partition itself is still encrypted.
Now, if this is a Microsoft account whose login creds you've stolen, and if the user doesn't have 2FA set up on their account / you are in a position to manipulate them into allowing the 2FA, then yes you can get into their Microsoft Account and access the data there. And if the recovery key is easily extractable from there as AshamedCaptain said in their comment, then yes you have access to the encrypted disk too. And of course if they reused those creds on other websites you have those too, yada yada.
But still, we are still talking about default configurations, right? You still haven't addressed my point that this evil maid attack already works on any machine where the UEFI isn't password-protected by default.
... or you can just login on the device itself.
(for which I certainly hope doesn't require todays crappy 2FA to work (unless you have something like a yubikey))
Yes, that is still an issue - for now. Which is arguably why these steps are being made. To close that hole one step at a time.
So just to be clear, the hole you're hoping to be closed is not Lenovo's "Allow UEFI CA" checkbox. The hole you're hoping to be closed is a) the ability to change the CAs at all, and b) the ability to disable SB. In other words you're hoping for hardware that can only boot Windows in perpetuity, nothing else.
It's fine if that's what you're hoping for, but I just want you to be aware of that in case you weren't already.
But I do think it is reasonable for a "windows PC" (one where the device is sold with windows preinstalled) only can boot windows by default. As that is what will benefit the absolute vast majority of users (though to be fair, there is plenty of lower hanging fruits than the boot process for most users).
But it is wholly unreasonable for the owner of the PC not to be able to disable that by themselves (without internet access or anything). If the solution to that is to require a UEFI password to be setup (perhaps windows could set the UEFI-password to the same as the main user if it hadn't already been set) - and resetting the uefi-password would wipe any encryption keys in the TPM that is fine (as long as the option to reset the uefi password exist).
And further, not allowing the owner the control to dual-boot windows and any other OS is also wholly unreasonable (but I'm fine with the owner having to enable it in UEFI first).
Can I hope for it? Would put an end to the "slapping Linux on a Windows box and complaining about how it doesn't work right" nonsense. (Probably in the bad way, and almost certainly with massive damage to the wider x86 hardware market, but still....)
One of the things Apple did kinda right was forcing you to buy Apple hardware to run OSX. It would be deeply ironic of Microsoft to cause the same end effect by locking Linux _out_ of all the Windows computers.
That is highly unlikely. The default configuration with a password includes a verification with the TPM. So the process is like this:
power on -> BitLocker asks for password -> password unlocks the TPM -> TPM does its boot verification -> TPM releases the encryption key -> you can boot into win
If you're on a win home installation the password thing isn't even an option, you just get boot verification and have to retrieve the recovery key from your microsoft account if TPM trips (imo somewhat questionable by MS).
Yes an attacker still could. BitLocker is handled within Microsoft binaries in the windows EFI partition. I believe it is specifically bootmgr.efi.
You can still chain load up windows on KVM at this point, however getting the Windows partition decrypted may be difficult and requires faking up a few TPM measurements.
Lenovo locks down hardware. I tried to upgrade the WiFi card in my Yoga 2 and got an "unauthorized hardware" message from the UEFI and it refused to boot until I removed the hardware.
I would not at all be surprised if they're just over reaching.
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.
Sure.. if you can manage your own keys and still install a normal OS, than you have done 2 things most home PC users will never do… and others simply cannot with a crippled factory BIOS. Yet we are not talking about servers, as features like Backplane administrative subsystems and hot-swapping internal bus parts are not standard on most PCs. Also, the Intel management engine and Computrace decedent features are not always removable, include their own CVE, and companies like Toshiba and Sony would trip the permanent asset flag at the factory forcing end users to adopt features they never asked for.
“chain of trust between firmware and OS” assumes physical security in logistics and co-locations is perfect, and given the number of unsolicited network appliances we would get from vendors in some places I worked... a CA no one ever checks is the least of peoples issues. We avoided HP after the quality dipped for their fragile laptops, and some server firmware would reject generic storage options. ;-)
> Intel management engine and Computrace decedent features are not always removable
Intel ME and Computrace have nothing to do with UEFI secureboot.
> “chain of trust between firmware and OS” assumes physical security in logistics and co-locations is perfect
Secureboot isn't just about physical security. It also (probably even more important) ensures malware can't modify anything in the chain of trust. Meaning malware can't backdoor the bootloader and in turn also can't install a rootkit in the kernel. If you would modify the binary of the bootloader or kernel their signatures would be modified. The firmware (ie. UEFI) won't load the bootloader anymore (because the signature check fails) and the bootloader (which verifies the kernel signature) won't boot the kernel.
Except there are already POC UEFI level rootkits that can't be detected by the host OS. Thus, such systems would appear to function normally to the common users, but offers zero benefit and may actually worsen the situation. Are you sure you are not confusing this with the TPM extensions?
Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place, and historically this process has already proven problematic to secure (Acer, Asus, Lenovo, CISCO etc.) ;-)
> Except there are already POC UEFI level rootkits that can't be detected by the host OS.
I don't see how that changes anything? There are also HDD firmware hacks which can't be detected by the OS. Does that mean we should do away with filesystem security and permissions?
You still have to hack the UEFI to get a rootkit in there. And yes, everything can get hacked. But that's not an excuse not to have security, is it?
> Thus, such systems would appear to function normally to the common users,
Secure boot changes nothing in that scenario. You can also hack the UEFI and install a root kit without the UEFI even supporting secure boot.
> Again, one wrongly assumes a supplier hardware comes into a facility clean in the first place,
If you find supply chain security important, then you should choose your supplier accordingly. That has nothing to do with secure boot.
"then you should choose your supplier accordingly" Yes, choose the refurbished, quietly restocked, and or disgruntled worker malware for your CEO. If you sell out, than don't go halfway dude... but buy a SSD/HDD retail like a sane person. ;)
"I don't see how that changes anything?" Well... Lenovo just patched 70 models for UEFI security issues, so some people see this a little differently. While I respect you opinion, it is irresponsible to frame blatant illegal product tying as a security feature.
"Secure boot changes nothing in that scenario"
We can agree it does nothing for security in most scenarios, and it is really weird some are so emotionally invested in convincing people otherwise.
"we should do away with filesystem security and permissions?" While I appreciate the off-topic rhetoric, one needs to recognize the main issue I see is who holds the signing keys. Would you buy a car someone in the next town needs to unlock for you everyday, well apparently some people are that lame.
I think we will have to agree to disagree on this issue =)
"Is this more common or less common with a chain of trust built in?"
False dilemma, my point was... when someone else holds the signing keys... there is no longer a real chain of trust. Thus, determining whether that someone else is intentionally evil or just grossly incompetent after detected incidents is an irrelevant thought exercise.
It's not a false dilemma. If it provides better protection to the overall set of customers, then it may be a net benefit.
No one had validates every virus signature and each line of code (or reverse engineers) in their virus scanner, yet those provide immense value to everyday users. This is no different - adding a feature that protects many users that are not sophisticated enough to manage their own CA, or that don't care to.
>there is no longer a real chain of trust
I trust a large security focused team to keep machines safe much more than I do the average PC owner or enterprise.
If you personally need the trust of your own CA, simply put on in. Many people here (and on the original blog post) point out how easy it is to do.
>exact arbitrary silliness we have seen countless times before
You continue to make the same mistake: contrast this 70 to how many breaches were prevented by the feature.
People with anti-virus software get viruses, both before and after getting updates. Is it therefore silliness to use anti-virus software? Or is there huge benefit to running it.
Cars with locks get robbed. Is is silliness therefore to have car locks? Or is there still large benefit to having locks?
Many people died after getting the COVID vaccine. Does that mean the vaccine had no benefit?
You repeat this exact error over and over, even after having it pointed out. Why?
“contrast this 70 to how many breaches were prevented by the feature.”
You mean... just like how elephants may be scared by computer mice, and that's why most offices are not infested by pachyderms. Your straw-man arguments will continue to incur ridicule friend, as they are provably irrelevant to the stated facts.
https://en.wikipedia.org/wiki/Simpson's_paradoxhttps://en.wikipedia.org/wiki/Informal_fallacy
“Is it therefore silliness to use anti-virus software?”
Starting another straw-man 2? let us discuss placebos that incur liabilities again… Many antivirus packages quietly collect user telemetry data, provide remote access, and break the host OS. People have documented armored-malware that utilize the antivirus program itself to bust through into kernel privileges ( https://www.zdnet.com/article/this-new-malware-exploits-bugs... ). Note, people primarily run signature scans on servers to protect Windows OS users from known email worms.
“ Is is silliness therefore to have car locks?”
Starting another straw-man 3? If you are a 2012-2022 Honda owner, than the factory digital-locking system is already broken for thousands of users. A physical key to a lock is something you possess, where a factory fob can be broken once the third party is eventually compromised.
https://www.thedrive.com/tech/i-tried-the-honda-keyfob-hack-...
“Does that mean the vaccine had no benefit?”
Starting another straw-man 4? A vaccine dose only protects against known variants, but often reduces the chances of dying due to how the virus variants severity has attenuated thus far. In my country we have above 86% immunization rates, but testing shows roughly 43% of the population were still infected at some point. Knowing people that were affected before the vaccine was available, in my anecdotal opinion the vaccine likely saved a lot of people suffering.
“You repeat this exact error over and over, even after having it pointed out. Why?”
I am polity waiting for a valid argument to teach you something important, but so far only see petulance driven fallacious nonsense. You have failed to convince anyone an off-topic straw-man strategy is valid, and I recommend this video as an introduction on evaluating information: https://www.youtube.com/watch?v=aNSHZG9blQQ
> 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)
> Unless you're willing to go full iphone/xbox with no third-party hardware or OSes
And even then, you still have the entire 1st party OS attack surface to play with. Which is just _huge_ specially considering this evil maid scenario implies you have a large amount of time with full control of the device itself and all its hardware.
These evil maid scenarios are so academical in nature by now, that there is practically no way to defend against them outside academia itself.
Presumably, if you can't touch the bootloader & the device has BitLocker enabled, then you can't even get into the OS unless you either (A) know the user's password, or (B) have an exploit that can be triggered from the lock screen.
In the case of the Xbox, you can replace the mainboard with like a rpi and still achieve it quite easily (I'd say budget ~ 100€). That's harder for a smartphone (I'd say budget ~ 2000€). Either way, the budget is still lower than the price of security flaws to circumvent secure boot.
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.
Just chuck up a screen saying "Configuring update for Windows, do not turn off your PC" and reboot 2 minutes later.
There's now no evidence of compromise except a user saying "My computer rebooted unexpectedly, there was a message about windows update" - hardly something that's going to set alarm bells ringing.
Any failure to get to the expected desktop must be investigated. No exceptions.
If you ignore red flags, yeah, you are going to get owned.
Windows doesn't do that normally, it doesn't reboot after installing updates during the boot. It can only happen if the computer crashes during update install, which again, is rare and a red flag. So it's not like every week you will need to send your computer to investigations during update installs.
But of course, the evil maid can just implant your keyboard.
What if the USB Linux stick loads the NTFS partition and runs the entire Windows OS inside of HyperV? Are users supposed to learn VM escape shellcode to check their PC each time? ("You fat-fingered your shellcode? Well you deserve to be owned!")
The TPM machine check would fail in that case and the TPM would refuse to provide the crypto keys to decrypt the copied NTFS partition. That's the whole purpose of SecureBoot, to detect hardware/software changes (including HyperV).
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.
Disabling secure boot is one thing you should be able to do with hardware you own. Of course that's not a good idea if you want to run a non-Windows OS in a secure manner. Installing your own CA cert should also be possible. That's what we do at work with current UEFI implementations.
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.
AFAIK, the fears with TPM are mostly about remote attestation. That is, a remote system could certify that you are running Windows (and not something else like Linux) on the physical hardware (and not on a VM) before allowing access to some resource; and that "some resource" could in the future even include basic things like Internet access.
That's a pretty terrible system, but I'm more afraid of the remote end of the system than the local one to be honest. We already have DRM and Intel providing features like SGX isn't the problem; the external parties choosing to restrict user freedom are.
I don't think remote hardware attestation will be implemented anywhere but in enterprise environments where it makes sense to do so. Even on Android we see remote attestation being bypassed quite easily in most apps. Some banks and payment providers are harder to trick, but I don't think there's a version of the system that hasn't been bypassed yet.
> Even on Android we see remote attestation being bypassed quite easily in most apps. Some banks and payment providers are harder to trick, but I don't think there's a version of the system that hasn't been bypassed yet.
It's getting harder by the year. I think it has strangled a lot of the Android ROM and modding community really, how your apps can randomly stop working after an update or two or that you can't watch high-quality content.
I think the Android ROM scene is starting to die out in general. Stuff not working outside official ROMs/on rooted devices has always been a problem, especially with DRM. People want the freedom to do what they want with their hardware and DRM people want people to do only what they allow with their hardware, the two parties will always be at odds.
Huge parts of the ROM scene were on Google Plus (yes, people actually used that) rather than on XDA and similar, which didn't help. Google also tends to hire people who do impressive modifications for Android ROMs like the person who wrote magisk, making the custom ROM scene shrink some more. I remember the ROM scene being so much more active before the corruption and death of Cyanogenmod!
> Even on Android we see remote attestation being bypassed quite easily in most apps. Some banks and payment providers are harder to trick, but I don't think there's a version of the system that hasn't been bypassed yet.
You do not need to guarantee that it can't be bypassed. You just need to ensure that it is annoying for the average advanced user to bypass it and that's it -- the damage is done.
And for example I have had to change banks already, and I consider myself a pretty advanced user...
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".
If I had to pay 2x the retail price for Linux compatible hardware, I'd have never gotten into Linux as a teenager with no money and no access to special hardware.
Even 1x the retail price is too much. Like many (perhaps most) people here, I got into Linux as a teenager by dual-booting on hardware I (or rather my parents) already owned. If I had to pay for extra hardware just to try Linux, I would probably still be using MS-DOS and Windows.
What cesarb said already, rings true to me: even if these devices were available at a price comparable to retail, no way in hell I would buy a special "Linux phone/laptop" in addition to my regular one. I just wouldn't have had the financial resources to explore the world of "open" things.
To address your proper comment, any amount of time spent on window-shopping any "open hardware by design" project pricing pages will show exorbitant amounts vs comparable spec consumer/mainstream hardware.
Examples:
* Talos Workstation, any Librem product, MNT Reform: self-explanatory. Absolutely mad price range for someone who is not sure whether they should buy one/need one, even for someone already in full-time employment in the IT field. If that's what you need or want, and you're sure you both need it and can afford it? Great. But not accessible to hobbyists.
* the Framework laptop/System76: the most basic configurations are around $1k/£1k. I don't think it's likely I would be able to obtain a cheaper one second-hand locally.
I am not going to make a survey of all Linux/open laptop vendors out there who sell worldwide (or at least, US and Europe), but I assume it's similar. If you can point to reasonably priced laptops from 2 different vendors or more, with specs suitable to using the laptop as a modern-day daily driver, I will retract this point.
* OpenPandora/DragonBox Pyra: I was extremely interested in this one, but bloody hell, spending 300-500EUR on a piece of hardware that will basically only ever play source ports of games and emulators? I knew straight away that I would only ever lick this thing through the virtual shopfront window, because for what you got, that price range was extremely hard to justify. This was before ARM gaming was a thing in any way.
* OpenMoko: as far as I know, the only attempt at an open hardware smartphone (that got something off the ground) until the PinePhone came along. Reading about it at the time, I recognised that its hardware is outdated, and that the software is irredeemable to anyone not willing to put blood, sweat and tears into it. Meanwhile, I could've picked up a CyanogenMod Android phone and had 80-90% of the benefit, for about the same price, and comparable or much better specs.
I don't blame anyone on the list above for the prices, and I don't think their products are crap. All I'm saying is that for someone on a budget, getting one of those is unviable. Either it's too expensive outright, or when it isn't, the result is not usable as a daily driver because you would give up basic features that you actually need. And when I mean basic, I mean "it cannot use school/work/bank/government/messaging apps made for the current duopoly in this device category", not "uses an older version of USB".
that was a discussion of a previous blog post by the same author (Mathew Garrett). Its on the same subject but this one is much longer and goes into much more detail.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
[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.
>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.
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.
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).
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.
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?
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].
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).
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.
> 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
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.
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.
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.
Searching for that phrase "Microsoft UEFI CA must be removed from Secure Boot DB" returns a link to a Microsoft presentation at UEFI Plugfest 2016 [1]
It doesn't directly say why that requirement was introduced, though one could gather from the context that it's being done for security. But perhaps more interesting is that both this presentation and the MSDN page you linked also talk about enterprises being able to control what runs on the hardware themselves. Your MSDN page has:
>Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots.
... and the presentation has:
>Security Certificates added to my device are documented and justified, with a pre-defined security response plan.
So I wonder if the reason is just "We wanted to make it convenient for enterprises to not have to do a pre-provision step to remove the UEFI CA, so instead we mandated OEMs to not enable it in the first place."
It would be extremely silly if that turned out to be the reason...
There are vulnerable bootloaders signed with the UEFI CA. Disabling less heavily vetted CA on devices that are being sold as basically hardened, makes sense. But yeah, one aspect of it might be making it easier for enterprises, that's a large focus.
Well that's what the revocation list is for, but yes I can imagine choosing the nuclear option of just dropping the CA is attractive because it's less work for everyone involved.
It was a leading question, answer to which only you can know based on your threat model. I did however say what you can do if you don't trust Microsoft, which also makes the question quite irrelevant.
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?
Well, I guess the point of this "collaborateur" deal was that: by making Linux bootloaders and distributions go through the MS vetting, getting most Linux distributions signed by MS, perilous as the situation is, we'd still be getting at least a couple more years of Linux distributions booting hassle-free even on Secure Boot systems. We did get an extra decade at least, as you mention, so I think the "collaborateur" effort was not completely wasted.
The only thing I would demand from these collaborateurs now is _not_ that they apologize, but that they simply make as much noise as possible since it was MS who changed the deal, not them.
Secureboot by itself is needed because otherwise you have no way of making a boot chain from firmware to OS which can be validated on x86. Meaning Linux (servers) also have a use case for it.
I also highly doubt Microsoft sees the Linux desktop as a credible threat to Windows. ChromeOS is an actual threat to Windows. And this does nothing for ChromeOS. It's more likely it's just a poor, uninformed decision from a team at MS.
You don't need Secure Boot or PKI for that. Simple proposal:
1. The system includes a TPM. The TPM measures all relevant pre-bootloader firmwares.
2. On first boot, the system firmware hashes the bootloader and stores the hash. A bootloader upgrade may be initiated by the old bootloader at boot time, and will update the stored hash to the one for the new bootloader.,
3. On subsequent boots, the system will refuse to boot unless the user overrides the boot device, the user resets the stored bootloader hash, or the bootloader hash matches. The boot process then proceeds.
4. The bootloader may choose to continue measuring the system and updating the TPM, or skip the process.
This proposal is platform neutral (will work on every platform with a TPM and system firmware), extremely simple to implement, not user hostile, and will not require PKI nor be hostile to users by default.
Wasn't this the original proposal for what TPMs were supposed to do? I remember that and secure attestation were considered radioactive to basically the whole free software community.
The scheme you are mentioning sounds like a hardened/serious version of those old "boot sector virus protection" things that 90s-era motherboards had. They'd checksum the boot sector and scream at you if it changed. Regardless, this scheme won't really fix the problem we're talking about - installing Linux on top of machines with Windows preinstalled.
Preinstalled systems will already have a Windows bootloader hash measured and locked before you even get at it. If it doesn't, that means you're building your own machine from an off-the-shelf motherboard, so none of this matters[0]. If you want to seamlessly[1] install Linux on a machine that's already running Windows, you need PKI that trusts both - either with Microsoft cross-signing Linux distros' bootloaders, or OEMs including both Microsoft and common Linux distro certs.
There's also a related problem here: if you are first-booting a machine without an OS, you have no chain of trust at all. This is a trust-on-first-use scheme, the problem being that it has nothing to protect against, say, NSA/TAP implants[2]. You're trusting that the machine that downloaded your Ubuntu ISO and flashed it to a USB stick hasn't already been compromised and isn't slipstreaming in more malware onto your stick. Or that your machine with Linux preinstalled wasn't opened up and stealthily modified before you got to boot it. PKI has an advantage here in that it doesn't just validate that the bootloader hasn't changed - it also carries the reputation of the signer, which can be damaged if they sign malware.
[0] Most motherboards for DIY builds don't even bother configuring Secure Boot - and the people buying them will know how to jump through whatever hoops are necessary to get Linux to run if they want it.
[1] though tbf the Asahi Linux people really did a good job of getting the installer to be seamless and easy on M1 Macs.
[2] While a government could compel Microsoft to sign malware, that would also create irrefutable evidence that Microsoft's keys had been compromised. The spooks really don't want to do this because such things could easily be traced back to them.
> The scheme you are mentioning sounds like a hardened/serious version of those old "boot sector virus protection" things that 90s-era motherboards had
Yes! In fact, I wanted to mention boot sector virus protection in my comment.
> Regardless, this scheme won't really fix the problem we're talking about - installing Linux on top of machines with Windows preinstalled. Preinstalled systems will already have a Windows bootloader hash measured and locked before you even get at it.
Part of this scheme is that the user is able to reset the bootloader hash at will, even on preinstalled and hand-me-down machines that were initialised or pre-initialised by somebody else already. So if one receives a machine with Windows preinstalled, then that shouldn't be a big deal as the bootloader hash can be reset in the firmware settings on boot. If the firmware doesn't let you do that, well... That's as bad as current Secure Boot for user hostility, but at least PKI is not injected into the mix to make it worse.
> If you want to seamlessly[1] install Linux on a machine that's already running Windows, you need PKI that trusts both
It's possible to dual-boot with chainloading, or simply update the system to support N hashes rather than just one. 1 kilobyte of storage will fit 32x 256-bit hashes, so that's not a lot of space even in NVRAM-constrained environments.
The only issue I can see with dual-booting and chainloading, is if the change to the boot process messes with some TPM registers and the OS that is already present on the machine is unhappy about that - but it seems like a tractable engineering problem.
> This is a trust-on-first-use scheme, the problem being that it has nothing to protect against, say, NSA/TAP implants[2]
Correct. But that sounds like a Trusting Trust attack on your firmware, against which Secure Boot cannot stand either.
> PKI has an advantage here in that it doesn't just validate that the bootloader hasn't changed - it also carries the reputation of the signer, which can be damaged if they sign malware.
OK, I will admit that is one advantage. Counter-argument I would propose, is that you should be installing the OS with known-clean, preferably read-only bootable media in the first place. That way you can verify the hash and authenticity beforehand in any number of ways, and remove complexity from the boot chain. This used to be the main way to install the OS before the Secure Boot era, as everyone was distributing OS installers on WORM media.
> I remember that and secure attestation were considered radioactive to basically the whole free software community.
Can you blame us? ~~Android's~~Google's SafetyNet is essentially a remote attestation API that a great number of banking apps rely on, and they refuse to launch unless they can see that SafetyNet status is intact. What good is the ability to replace a ROM or gain admin access, if half of the security-sensitive apps on your phone stop working? Remote attestation is here, and it sucks.
Totally agree with you on SafetyNet, and the fact that it's used by so many apps that don't need it feels like a betrayal of trust.
What you mentioned about read-only media is how secure boot should be implemented, too. Or at least it's how Apple does it: all the boot chain verification code lives in mask ROM so the only way to compromise it is to either find a bug (rare and expensive) or compromise the chip vendor (very "loud", spooks don't like this). The only problem with this setup is that Apple does not give two hoots about vendor neutrality[0] and this sort of scheme requires trusted roots to be burned into the chip.
Not being able to reset the boot hash is actually worse than current Secure Boot. The problem being complained about isn't dualbooting. It's that Microsoft is making you jump through additional hoops. There's still the ability to turn off Secure Boot; that's the moral equivalent of "resetting the boot hash" in your proposal. But we don't want to make users do that; we want the machine to just say, "oh this is the trusted Linux build, go on right ahead" without any extra mess or fuss. Linux distros jumped through hoops a decade ago to get a secure boot path signed by Microsoft - not to enable it to run at all, but just to make installation and usage easier.
[0] They do provide an owner-override on Macintosh-fused chips, which is actually implemented in a really cool, user-friendly way. But that's moreso for letting the user build their own kernels rather than a serious attempt at being vendor-neutral.
Presumably in the alternate world where Microsoft hadn't signed over Windows on ARM to Qualcomm, Apple would be signing a Boot Camp bootloader that validates Microsoft keys.
How big do you think Microsoft's threshold is to fuck a competitor over? It sounds like you're saying Microsoft is slow to rouse to malice; I don't think that's how they work.
If they can head off a competitor early for little investment, I believe they will do so - are doing so.
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…
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.