Responsible stewardship of the UEFI Secure Boot ecosystem
mjg59.dreamwidth.org
mjg59.dreamwidth.org
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.
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.
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.
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.
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 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).
That's the thing, you don't have to disable that. You just have to re-enable that CA if you have a model that has Device Guard enabled by default.
> It's an extra hurdle.
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).
If we take the model the initial blogpost was about it's nicely documented: https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure...
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.
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 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.
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.)
I run Linux on a used ThinkPad I got on eBay and I have no idea what this sentence means.
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.
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.
I think them being NDA / proprietary is a reason we can't improve things, not a justification for it.
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.
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.
>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.
We really must not conflate "predictable behaviour" or "established behaviour" with "acceptable behaviour" in any part of life including corporate crime.
Apply some basic logic to the conversation.
It's either a neutral organization signing certs which you then have to accept by default, or you get fined. Those are the only acceptable scenarios.
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.
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.
Also, the whole scenario you depict is quite unreasonable to expect of a default install - which is exactly what is being talked about.
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.
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.
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.
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.
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).
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.
Do you have a reference for this? I didn't realize this was the case. Is it part of their "pluton" stuff?
No, it's not Pluton, they've been doing this at least for a decade.
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).
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.
Not commenting on the broader issue, but this attitude has to change. Firmware updates cannot be seen as optional anymore.
Popular rephrasing of the H.L. Menckin original.
Failing to see how Lenovo can't implement something like that.
... what?
Yeah, the members of said groups handle that part, so the software installs automatically. No forcing and consent is necessary in most scenarios. :)
If Libreboot wasn’t such a pain to install, it would have saved a lot of grief.
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.
“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 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.
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.) ;-)
Is this more common or less common with a chain of trust built in?
Existence is not a useful metric - rates are.
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.
Have a gloriously wonderful day. =)
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.
Enhance you calm... =)
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?
"Enhance you calm" indeed. Whatever that means.
“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
On a unrelated matter, I find the Yellow Feather Fund’s work with autistic children a worthy cause for donations. https://www.sesameworkshop.org/donate/other-ways-support-us
Have a gloriously wonderful day, =)
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.
"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 =)
Dunno if you need LibreBoot specifically, but if CoreBoot is sufficient, several vendors offer it preinstalled....
("Please stand by, while we are checking your browser... Please turn JavaScript on and reload the page." No thanks.)
Isn't secure boot attempting to protect against 'evil maid' attacks?
After all, the evil maid can come in on Day 1 and insert a bootable USB stick which boots a linux distro customised to look like the normal Windows boot and save your password when you enter it; then on Day 2 boot the computer normally and use that password.
If you want to protect against that, you need password-protected BIOS settings to enable/disable booting third-party code.
(Personally I see adopting the TPM as a fool's errand - I don't think it can ever deliver on its promises)
The evil maid will need less time to replace the computer with another one that looks alike the original one, than to install a Linux distro
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.
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.
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.
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?
Not always, in some situations there was a requirement by MS mandating secure boot NOT to be disable-able: https://softwarefreedom.org/blog/2012/jan/12/microsoft-confi... "Disabling Secure [Boot] MUST NOT be possible on ARM systems."
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.
Their numerous anti-user and anti-privacy practices are unimportant. Nadella's Microsoft is "cool" and that's all that matters.
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).
> Load Linux directly as an EFI executable via the EFISTUB approach.
> the "Using UEFI directly" section [...] https://wiki.archlinux.org/title/EFISTUB
Big question is how do Microsoft get away with this bullying of hardware manufactures, probably the fear of losing business.
What can we do to stop this?
There is nothing that can be done as long as there is a processor duopoly that follows these ms requirements.
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.
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.
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!
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...
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".
"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!"
> 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.
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.
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".
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".
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.
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.
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.
Ok, so why not allow me to remove the Windows bootloader and just have the third party one that I trust more?
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.
As clearly mentioned in the TFA, this is Secure Boot itself and has nothing to do with Device Guard.
Secured core is a class of device security specifically intended to be highly locked down.
From https://docs.microsoft.com/en-us/windows-hardware/design/dev...:
> Secured-core PCs provide protections that are useful against sophisticated attacks and can provide increased assurance when handling mission-critical data in some of the most data-sensitive industries, such as healthcare workers that handle medical records and other personally identifiable information (PII), commercial roles that handle high business impact and highly sensitive data, such as a financial controller with earnings data.
> For general purpose laptops, tablets, 2-in-1’s, mobile workstations, and desktops, Microsoft recommends using Security baselines for optimal configuration. For more info, see Windows security baselines.
is literally on the first paragraph of my comment.
It's a huge stretch to call a single toggle in UEFI an "obstacle" if you're already competent enough to install an OS from scratch. Maybe the focus should be on that, how to provide preinstalled Linux instead.
> each of which must be individually researched and disabled
Or you read the user manual.
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.
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.
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...
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?
Once people start side-loading to get around future bans on E2EE messaging apps, I expect governments will require OS vendors to implement blacklisting of such software even on desktops, using something like Apple's Gatekeeper service[1].
[0] https://www.pcgamesn.com/valorant/windows-11
[1] https://appleinsider.com/articles/20/11/15/big-sur-telling-a...
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.
> 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.)
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 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.
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.
> Instead they declared themselves rulers
This statement logically suggests that Microsoft laid down the law on secure boot and the impetus was entirely theirs and nobody could have done anything differently.
The UEFI forum was made into a public forum for the public version for x86. Before that it was a proprietary boot protocol designed by Intel mostly for itanium but also licensed to Apple for x86 (2010 era Mac minis use efi). Microsoft were not the originators, although I've no doubt they're contributors to this and secure boot.
Where Microsoft _do_ dictate is the Windows logo program, which is distinct from UEFI. This was the discussion originally on Matthew Garrett's blog: will they or won't they leave an 'off' option (practically they had to, to boot older windows and rescue disks).
Furthermore Microsoft's Windows logo requirements, while requiring OEMs to carry their keys on the basis OEMs want Windows logo, didn't exclude the likes of Redhat or Canonical from standing up a CA and getting included. There's some discussion of this on Matthew's older blog posts: https://mjg59.dreamwidth.org/6503.html?thread=194919 although I think there was a better discussion on OEM inclusion I can't find.
In other words we find ourselves where we are because everyone has been content for years to simply use the shim signed by Microsoft. Only Microsoft stood up a CA and underwent the due diligence. And you can't say a free CA can't be stood up, because letsencrypt went from zero to cab root programmes in this time.
The only issue in here that needs some care is forcing vendors to ship all approved CAs, not a minimum selection they care about.
Bootkits are a minor issue now as othe commentators have insinuated because of secure boot.
There are other advantages, too. With secure boot and tpms remote attestation of some systems at least becomes a bit more reasonable. You can also have the same bootkit resistance under Linux if you're prepared to put in a little bit of effort.
Sure if I had my way we'd have prioritized MTE/PAC over secure boot but there you are.
So let me sum up. Yes, what Lenovo is doing is bad, and if Microsoft are really proposing ditching third party signing then they deserve another massive antitrust suit. Looks like Matthew is again pretty much the only voice in the Linux world trying to make something practical work.
I am saying that it should always be the case that you can disable secure boot and it should always be the case that you can manage your platform keys. I also think they should ship the UEFI CA by default and offer the option to opt in to secure core as part of Windows' OOBE if they feel so compelled.
But there is a non profit neutral third party already and no Linux distro (or the Linux foundation) have pushed for CA inclusion that I know of.
UEFI and Secure Boot are here to stay unfortunately. That's not going to change (and that's more of a comment on the design of UEFI than SB).
Secure boot 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.
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.
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.
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.
Revocation updates are in the form of authenticated UEFI variable blobs. They can be applied regardless of OS and don't require a firmware update.
There fixed it.
No extra hoops for any OS. Extra hoops if you wish to change OS, which could increase security>
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 ?
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.
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.
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.
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.
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
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.
Trusting hardware encryption on consumer SSD's has been proven to be a pretty disastrous idea[0], with even Bitlocker disabling hardware encryption by default.
From what I understand, a lot of encryption implementations were really really bad, with massive security vulnerabilities and issues. I suppose if you're an enterprise you have the money to test if the SSD is actually encrypting the data on the NAND, but a consumer would be none the wiser.
[0]: https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-en...
Crucial: MX100, MX200 und MX300
Samsung: 840 EVO und 850 EVO
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.
Instead of giving money to Microsoft or Apple, support OEMs producing hardware with Linux pre-installed like Tuxedo and System 76.
Want to switch default browser? Adding yet one more step to stop you.
Want to boot other operating system? Now you have to go to UEFI setup and change boot settings.
etc.
PC only got out of control, because Compaq was clever on their reverse engineering process, and IBM failed to uphold their ownership.
At this point, the simplest explanation is malice.
WSL focus on Linux, because the Linux kernel ABI is the new POSIX.
However, what makes sense for Microsoft may not be in our best interest.
No one should complain about regressing 30 or 40 years?
I tried not giving money to apple, but it was money wasted tbh. Like seriously, $2k for a barely useable laptop.
This is manifestly not the case. Perhaps in the very early days but not in the last several years.
Although Clevo can sell their own version of the hardware, it is not really the same[2]
[0] Based on my experience. I ordered a laptop a long time ago and they explained they were working with Clevo to get the firmware fixed so that suspending worked reliably. This is before the OpenBoot + EC stuff came about.
[1] https://support.system76.com/articles/open-firmware-systems/
[2] https://twitter.com/jeremy_soller/status/1322954964549824512
[3] Clevo is System76's ODM. Most OEMs (e.g. Dell, HP) work with ODMs to put together the final product the OEM then offers. I posted the public Dell ODM list in another thread. System76 wanted to bring laptops in-house; I don't know the status on that. But System76 and Clevo work together to offer the final laptop based in a Clevo base[4]. And now (like, in the last 4 years) System76 started also adding open source firmware in some places.
[4] https://twitter.com/jeremy_soller/status/1322960532303872000
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.
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.
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.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.
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 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).
I've never had to buy an OSX computer in order to install linux on top of it. The same cannot be said of Windows.
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".
They say security but there is an underlying Elephant in the room concern that keeps rearing it's head.
I don't see how anyone can look at the history of Microsoft and not immediately judge this as being completely anti-competitive in nature.
Where can we find the full requirements for a device to be Secured-core?
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.
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.
It has been documented for a while really:
https://docs.microsoft.com/en-us/windows/security/identity-p...
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...
[1]: https://uefi.org/sites/default/files/resources/UEFI_Plugfest...
If MS's distrusts its own ability to vet other people's code, why trust their ability to vet their own code?
If you want to do the legwork yourself, feel free to roll your own PKI and sign things you trust yourself.
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.
If they can head off a competitor early for little investment, I believe they will do so - are doing so.
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.
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.
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.
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.
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.
like Pottering
https://www.theregister.com/2022/07/07/lennart_poettering_re...
> whenever a signed object is booted by the firmware, the trusted certificate used to verify that object is measured into PCR 7 in the TPM.
Is there a list somewhere of what each PCR is generally used for? I’ve had difficulty finding the information through Google searches.
Lenovo shipping new laptops that only boot Windows by default - https://news.ycombinator.com/item?id=32023868 - July 2022 (388 comments)
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…