And even then if they have the option, the entire process is designed to make the user feel as uncomfortable as possible while doing it. Disabling perfectly unrelated features (e.g. fast boot), going through Scary Boot Prompts, etc. are NOT acceptable requirements for booting a non-MS OS.
It's not the first time a vendor disables the MS UEFI CA signature by default (e.g. Microsoft itself has done it on ARM _and_ x86 Surfaces).
For the record, Google has also been doing the same for a lot of time now (Scary Boot Prompts if you try to run Linux on bare metal, but all is fine if you run containerized Linux on top of Google's OS). They don't get a free pass from me, either.
> Disabling perfectly unrelated features (e.g. fast boot), going through Scary Boot Prompts, etc. are NOT acceptable requirements for booting a non-MS OS.
There is Windows fast boot and UEFI fast boot, which are two diffent things. Sometimes vendors support only Windows fast boot, and at least then it is perfectly acceptable to force removal of that option.
Also, for example the purpose of secure boot is to prevent modification and changes on boot options and underlying files, which makes it also to be fine to force disabling, until you set new keys for your new OS.
A regular Ubuntu update on my XPS 13, an officially supported combination, broke my wifi. Since then it has also somehow broke itself in some other fun way such that there are now package conflicts and it's unable to update itself anymore as a result.
And that's ignoring all the general usability issues like the subpar battery life, the dreadfully terrible state of video playback, the touch screen constantly causing gnome to glitch internal state and get confused, etc...
On my Debian desktop I had a webcam completely take out the USB stack. Like all ports just dead, had to yank the power to reboot. I also had a btrfs array just go read-only for seemingly no reason after restoring from standby, and it wouldn't tell me why. After a reboot all was suddenly fine. Also it took an awfully long time to get that machine working after having been powered off for 3 months. If you go too long without updating, it seems all the package migrations just bitrot and break.
But yeah, year of Linux on the desktop. Any day now.
I saw some of those problems with Ubuntu 20.04 on my recent XPS13. I shifted to 20.10 which resolved almost all of them, and once 22.04 came out there are no more issues. Admittedly, I did a fresh install vs an upgrade.
I run dual monitors on docking station with lots of peripherals.
> I honestly do not comprehend why so many folks base things on it.
In this case it's literally the OS offered by Dell for the XPS 13. It's as official an option as you will ever see, so the fact that such a pairing is still a broken disaster is pretty significant.
I could switch to a different distro, and I might. But distro hunting is exhausting. And it itself represents a never ending treadmill of churn. Like right now it seems like Fedora is a good option, and so are things like PopOS or Manjaro. But rewind the clock 5 to 10 years and some of those didn't even exist, or were not nearly as good of choices for "regular consumer usage." Whose to say I'm not just going to be stuck with yet another "oh, that distro used to be good but now it sucks, switch to foobar instead" in another few years? I'm more likely going to just switch it back to Windows if I'm going to get over the "back everything up & reinstall from scratch" hurdle. I at least know with Windows that I won't have to do a reinstall dance on this machine pretty much ever again. Having Linux for the better development options is nice, but with how good VMs are (and with things like WSL), running it bare metal kinda isn't all that necessary.
> Debian 11 was released less than a year ago, in August 2021.
Keep in mind though that it was branched and package versions frozen ~6 months before that.
I like debian and use it on some things, but for a personal computer I always found it frustrating that the software was already half a year out of date on release day. Software getting released today wont be in Debian stable until 2023.
I have no problems with Debian, but I think their release deltas should be cut in half. Firefox is deprecated on Debian, and that is their officially supported browser.
I know that the whole point is stability, I just think that for home desktop users it's not a great experience.
Fully agree and I had similar experiences with framework. I think the majority of folks posting here are not typical users and find it natural to jump in the terminal, edit some setting, restart a service and tinker without realizing the effort involved and that that normal users don't -- can't -- do this.
My family is happily using only Linux since 10 years, I since 15 years ago. But there are a lot of "but", without my support (I'm a sysadmin) they could not, but half of the issues are not Linux only, so they needed support even if they were using Windows. The real question should be "why even non technical users should use Linux?" You should not give a supercar to drive to a novice driver, it could be dangerous for him and for others. Every OS has its use, maybe I'm snob, but if you're not able to manage Linux rough edges use MacOS or Windows, Linux natural environment was and should be datacenter. I won't trade server features, robustness for having a Linux desktop at all cost.
If you think Linux Desktop is in decent shape, your hardware choices must line up with those of your platform maintainers. Good for you -- but your experience will be very far from universal.
Some Ubuntu LTS highlights:
Ubuntu 14: By default, Dell display backlights toggle on/off 30 times a second
Ubuntu 16: By default, BIOS boots broken due to boot files landing in too high of a sector
Ubuntu 18: By default, Solid State boot drives break because /dev/sda was hardcoded
Ubuntu 20: By default, Bluetooth and fans broken. Never fixed. Sleep broken but fixed.
Ubuntu 22: By default, NVidia graphics get 100% screen saturation after install.
"Then don't use Ubuntu"
Ubuntu isn't my daily driver. It isn't even a majority of my installs. I'm using it as a benchmark for conservative linux choices because smaller distros tend to be worse, not better. I know this because I daily drive a less popular distro, and I also distro hop for fun, and these all tend to be worse, not better. Besides, many hardware and software vendors target Ubuntu, and "works on Ubuntu but nowhere else" is a very common problem. Across the board, the Linus Tech Tips linux experience is the rule, not the exception. Many desktop linux users just have selective community-enforced amnesia.
Look, I am super thankful for the maintainers. I have gotten so much more value from them then they have asked in payment, but Linux is nowhere near Windows in the "just works" department. That is to be expected, given the price, but the rhetoric has gotten out of line with reality. Desktop linux still has a lot of rough edges and new rough edges appear at a rate that is not converging to 0.
I've been using Ubuntu since 8.10 as my only OS. A HP nc8430 until 12.04, then a HP ZBook 15 since 14.04. Both laptops came with Windows (XP and 7.)
I had my share of problems but none as bad as the ones you wrote. Currently there are two problems
1. Poweroff is reboot, so I press the shutdown button when the BIOS starts. It has been like that for ages through more than one LTS but I shutdown very few times per year.
2. The fn brightness control keys don't work so I made two hotkeys to run a X11 brightness control program that steps up or down the backlighting by 5 points, 0 to 100. This is probably on NVidia's driver.
Everything else is fine and that's great considering that probably HP never tested these laptops with Ubuntu.
Two nuisances is still better than the alternatives: the very same hardware with Windows or an Apple machine with OSX (I can't stand the UI.)
Don't you need very specific hardware to get Mac OS to work too? I think it is useful when comparing OS environments to make sure you are comparing on the hardware that is optimal for each OS. And you can get Linux optimal hardware from a lot more sources than Mac OS optimal hardware.
The biggest issue is that on the Mac side, it is really easy to get the OS and the optimal hardware together, and know that it "just works". For Linux, we have several small vendors, and a couple larger ones, that have Linux-advertised hardware, but most of the Linux optimal hardware doesn't advertise itself as Linux (Android phones/tablets, Chrome OS, etc).
Same is true for windows, but due to prevalence of windows and the effort of MS (certified for windows program), most hardware tries to make itself work on windows. It also makes sense given that Windows still has 78.5% share in the market.
So, it is not that linux does not work with a lot of consumer hardware. It's that most consumer hardware cannot be bothered to work with linux and invests itself in working with windows.
There is also a factor in-kernel vs out-of-kernel drivers.
Nope. I can understand how you might prefer that I had been writing about workarounds, but I was not writing about workarounds. I was writing about the incorrect and alienating rhetoric coming from the Linux community.
There is such a firmware setting, hence "by default". That doesn't make it acceptable - the default security settings on a general purpose PC should not prevent booting alternative operating systems that don't compromise the security model.
So they are protecting your ordinary everyday users, while still giving any of us who need to boot from a USB stick or another partition the ability to do that with a simple BIOS setting.
It doesn't seem much different from the F12 menu that lets you select an alternate boot device.
How exactly does this mean they "prevent booting alternative operating systems"?
> No "ordinary" user was ever compromised by accidentally installing Linux making his computing less safe. This is complete fantasy.
That's incorrect. There is malware out there that can only work if you don't have Secure Boot enabled. The setting OP didn't disable, Device Guard, prevents the abuse of 3rd party signed bootloaders, another attack vector basically.
This is a step up for most people that ever stay on Windows and doesn't affect the slightest someone who wants to install Linux, they still have to boot from an external device or wish to change a few UEFI settings.
> Of course this is a mechanism to further advertise locking down general computing and nothing else. It is not new and security is a bad excuse.
Framing Secure Boot as some kind of Secure Boogeyman is not conducive, brings the discussion into tinfoil scenarios without any potential practical outcome (nobody is going to remove SB or DG).
As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone.
Note, this is about not booting from signed and verified bootloaders, using the 3rd party Microsoft CA, which need to go through quite some hoops already to get verified, not some unverified and/or unsigned loader.
Debian, Fedora, ... use already trusted and signed bootchains, but they are excluded by choice without any benefit of security whatsoever.
IMO this smell again like classic Microsoft EEE...
> Framing Secure Boot as some kind of Secure Boogeyman is not conducive, brings the discussion into tinfoil scenarios without any potential practical outcome (nobody is going to remove SB or DG)
So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) in order to boot _any_ non-MS OS scenario, and you are still claiming that this is scaremongering ?
At which point it stops being a "tinfoil" discussion ?
> As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone.
Microsoft _already_ promised that there would be a way so that non-MS OS manufacturers would be able to sign their software so that it would NOT REQUIRE fiddling with the system firmware in order to boot them, even with Secure Boot enabled. This is what the UEFI CA was for. You just insert a SUSE USB pendrive, use the firmware boot manager (or even Windows own' "boot from USB device" option in the Settings panel!) and that's it.
Your system is no more compromised by this CA than by allowing MS OSes in the first place. This CA is MS, too. They vet everything they sign. They blacklist stuff that could have been used to compromise devices. They have forced GRUB among many other distributions to align to their whims in order to be signed.
Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware. You have to fiddle with the system firmware, battle with a lot of Scary Boot Prompts that will drive many users away (even advanced ones!), and with the easiest option likely being to disable Secure Boot altogether which per your own words will reduce the security level of users.
Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings, no matter if the device came with no OS or even a Linux distro to begin with.
I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ? Give me a break.
> So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) part in order to boot _any_ non-OS scenario, and you are still claiming that this is scaremongering ?
Yes, because the same way you have to enable booting from an USB stick.
> At which point it stops being a "tinfoil" discussion ?
See my last sentence in my previous comment.
> Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings,
Making a fresh install of Windows is equal in complexity, but it is preinstalled more often certainly.
> Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware.
That's not a case with Secure Boot alone, it's a case with Device Guard. Device Guard you can disable. It's a toggle like all the rest, no promises broken.
> I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ?
> Yes, because the same way you have to enable booting from an USB stick.
NO. It's not the same way. On most if not all devices I can boot from a USB stick literally from the Windows settings panel itself (search for Advanced Startup)! No need to even see how the system firmware looks like. Even on hardware as "locked down" as x86 MS tablets, I can hold Volume Down key during boot to boot from a USB stick. Again, enabled by default , and no need to even look at the system firmware !
From that point on, _if the UEFI CA signature is installed_, the distro's setup experience takes over, which is already under the control of the distro itself.
> Making a fresh install of Windows is equal in complexity, but it is preinstalled more often certainly.
"Equal in complexity" to what ? Most distros and even Windows install can be done with your eyes closed and hitting the enter key repeatedly, specially if you are just overwriting whatever was on the computer before. Installing OSes are typically designed to be as easy as possible. We've had decades of improvements here, both for Windows and non-Windows.
Changing settings and disabling secure boot on the system firmware is NOT designed to be as easy as possible. In fact, many times it is explicitly designed to be as scary as possible, precisely for security reasons! (with the intentional addition of Scary Boot Prompts). But worst of it, this part of the experience is NOT controlled by the OS vendor ! That by itself is already suficient to have a completely unfair situation. No matter how much effort you spend on making your OS install flow as smooth as possible, your user still has to fight the system firmware... but only if you're a non-MS OS!
> That's not a case with Secure Boot alone, it's a case with Device Guard. Device Guard you can disable. It's a toggle like all the rest, no promises broken.
The promise is that there would not need to be a toggle to switch. That's what's been broken!
So what do you want exactly? For hardware to ship with signatures for every known variant of Linux, BSD, QNX, RedoxOS, Solaris, and OS/2 Warp? I'm honestly asking: what is the alternative you're proposing?
If you're just saying "it's not easy enough", well, that's a matter of opinion.
What I am describing above is just the current method. The one which is currently implemented in most x86 UEFI hardware save for apparently this one Lenovo laptop and some other "miscarriaged" hardware.
You do not even need to imagine "what I am proposing" because I am not proposing anything whatsoever: the MS UEFI CA signs non-MS operating systems.
This is not about the presence of Secure Boot, but about distrusting 3rd party CA's. For example, my Dell XPS, with default Secure Boot settings, will boot official Fedora builds. This will not.
A signed rootkit created by abusing either an existing signed bootloader or shim. Of course it will change some TPM measurements, but those only matter after BitLocker has been enabled.
The same vector is applicable for Microsofts loader, so not really one that only the externals are susceptible and again no benefit in security.
Microsoft doesn't signs arbitrary bootloaders, normally just the shim from RH that needs to have a list of earlier signed 2nd stage bootloader (versions) with now known security issues and reject them.
Then this doesn't matter, because you haven't set a password on your firmware and the attacker can just turn on the "Trust the Microsoft 3rd Party UEFI CA" option
The average user has Bitlocker enabled and sealed to PCR 7, because that's been the default for years. A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them. If you're looking for the set of people who have hardware that defaults to this configuration, and who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them.
> The average user has Bitlocker enabled and sealed to PCR 7, because that's been the default for years.
No, very few models sold auto-encrypt because most have *the very least* one untrusted DMA-capable bus. They might even have Device Guard enabled, but that's often insufficient. Not to mention other reasons why devices might be considered noncompliant, like lack of HSTI (though that's more common with desktop motherboards, of which some might even have all other features Device Guard consists of).
At this point in time, I'd consider auto-encryption rare. Maybe in five years and a few refresh cycles.
> A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them.
No, because previous point.
> who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them.
Me finding someone getting actually targeted? Indeed unlikely.
Me finding someone with some especially nasty variant of Emotet? Not at all unlikely.
Device Guard enabled devices certainly make life harder for attackers, even if BitLocker is not (auto-)enabled.
> No, very few models sold auto-encrypt because most have the very least one untrusted DMA-capable bus.
This is a malicious thing to say considering the context (the same problem would affect MS OSes too), and for all practically purposes: since Windows 8 _all laptops_ that I have been able to buy had Bitlocker enabled out of the box (to my annoyance), not to mention that it was practically standard IT police for any large Windows shop.
> since Windows 8 _all laptops_ that I have been able to buy had Bitlocker enabled out of the box, not to mention that it was practically standard IT police for any large Windows shop.
Please, the current context is "average user" not an "average enterprise". In the latter case I agree with your assessment.
It's not like I don't buy my laptops at the same places average users do. Can you show me one model of a laptop in sale today with Windows 11 that does not enable Bitlocker by default ?
Systems have been shipping for years without any untrusted DMA-capable buses (source: I audited a bunch of this in a large enterprise). Anyone who's currently shipping systems with the 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so.
> Systems have been shipping for years without any untrusted DMA-capable buses (source: I audited a bunch of this in a large enterprise)
That's your mistake here, you saw it in a large enterprise, the context is "average user".
> 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so.
Some of the buses that haven't been whitelisted are only internal, so technically not snakeoil, just won't let you auto-enable encryption.
Honestly onus is on you to prove that current hardware that disables the 3rd Party UEFI CA doesn't also enable TPM-backed Bitlocker by default, because all examples I've seen do.
I can certainy imagine someone trying out linux and accidentally nuking their windows partitions in doing so or having GRUB replace their bootloader and figuring out ??? to boot back to windows.
Giving the user more hops to jump through, when they want to try alternate (signed!) operating systems? Like, you have nice encrypted disk here, are you willing to lose it, when you flip the setting?
Funny thing here is that the feature OP stumbled upon, Device Guard, does prevent quite a few different malware preinstallation methods. Including the infamous Lenovo one.
This is ridiculous. Lenovo controls all the preinstalled software as well as the drivers that are shipped with the device. Any of them could install a Superfish-like thing at any point.
They may control those parts, but Device Guard won't let you install most rootkits. Starting from Secure Boot and Virtualization Based Security ending with Trusted Boot, the system should be capable of rejecting unsigned privileged components and remain secure. Then an AV is probably capable of detecting and removing actual malware.
Superfish was not a kernel rootkit by any measure of the word. You just have to install a new CA then a NDIS filter, neither of these is either a rare or even blocked operation since they are required for preinstalled software such as drivers or even an AV. There would be absolutely no difference on whether you used Secure Boot or not.
But worst of all: Superfish was actually _signed_ itself. MS has improved the level of vetting they do now, specially for kernel drivers, but how come anyone can still claim with a serious face that a signature requirement from one CA specifically improves security against malware _from that CA_ (or their associates) ?
> Superfish was not a kernel rootkit by any measure of the word.
I didn't say it was, you kinda ignored the context. The person who I replied to was asking how can they trust their Windows is genuine, I replied to them that the feature causing a stir here does protect against some types of malware.
It's a fair assumption that the next thing akin to Superfish would try to implant itself deeper, if given the chance, Device Guard does eliminate some of those ways.
> for preinstalled software such as drivers
If that driver is actually malicious then Early-Launch Antimalware alongside the kernel being protected, can get rid of it.
> There would be absolutely no difference on whether you used Secure Boot or not.
I wasn't talking exclusively about Secure Boot.
> But worst of all: Superfish was actually _signed_ itself.
Sure, now there's a toggle that won't trust some signatures that aren't as heavily vetted (amongst many other things). How is that "ridiculous" or "won't make a difference". Are you just looking for a reason to argue?
> [Device Guard] does prevent quite a few different malware preinstallation methods. Including the infamous Lenovo one.
Which is the infamous Lenovo malware "preinstallation method" ?
How would a signature system would have prevented malware that was literally signed by Lenovo _and_ MS from being preinstalled on a Lenovo OEM image shipped with Lenovo hardware ?
Yes, and I didn't call it a "kernel rootkit" as you said I did.
> How would a signature system would have prevented a malware that was literally signed by Lenovo _and_ MS from being preinstalled on a Lenovo OEM image ?
Because AFAIK Device Guard sets limitations to what WPBT can do. Not to mention it's likely that additional kernel and boot integrity helps against all types of malware.
I do want to use secure boot and TPM2 (I do, currently). Just not with windows. Why should be secure boot windows exclusive feature? Until now, it wasn't.
> device guard and secure boot are different things, related, but different.
The problem is that it can have potentially catastrophic impact. If the user enabled Bitlocker, and didn't save recovery key (it will happen for mainstream users), he can lose his windows drive when he tries linux.
As I wrote above, another extra-hop for those who would like to go off the beaten windows path.
So they steal different certificate from the same subject instead? (Both CAs are Microsoft's, and only Microsoft is signing).
The default for years was to boot from external storage, when the internal is not bootable. To change it, you would have to change boot priorities or manually use the built-in boot selector.
That's a message from the Windows installer. Normally you would have to remove the optical disc after the files are copied or change the boot order/devices when the first stage of the installation ends and the computer is rebooted. With this trick, you don't have to do anything.
It is legacy boot, not UEFI. And I vaguely remember that this message came from the boot loader on the CD, of all places. It was a convenience for the user, who forgot the CD in the drive.
A former work computer of mine (a Lenovo, too!) wouldn't boot one day. After some time trying to figure out the issue I discovered I'd left a (non-bootable) USB drive attached to the machine. Removed the drive and it booted fine.
Having said all that, this comment is all anecdotal, much like yours.
I think they should. My home PC, which is used for gaming, is not likely subject to an evildoer with a kali linux USB stick. So I should be able to boot it from MY USB sticks without any hassle. It should be a BIOS boot menu option.
If people in corporate environments want to disable this, they can set a BIOS password to keep others out of the boot menu.
If an attacker is in a position to jam a random fob into your laptop then they can just enter the firmware and change the config to enable it. If you're going to posit an attack scenario then please describe the entire sequence of events and where the attack would be prevented by this configuration.
I see it as quite feasible that an attacker could insert a fob or organise for a fob to be inserted without also having opportunity to reboot the computer.
That fob could then compromise the system when the computer was rebooted. The Lenovo bios setting being discussed would prevent that.
BTW Can you clarify if you think the feature from Lenovo is a good or a bad thing given your claim that it's very easy to disable?
The boot variables won't point at the device, and so the firmware will never bother to scan the device. The bios setting therefore provides no additional security in this scenario.
It happens at airports, coffee shops, etc. Anywhere there are people working in public places. Jam a fob in, force a reboot, ransomware now loaded (for one example)
Force a reboot, jam a fob in, hit F1, cursor down three times, tab, down five times, space, F12, ransomware now loaded, except:
System doesn't boot because PCR 7 is now different, just like it would be if you didn't have to do those additional (rapid) keypresses. This is not the threat model you're looking for.
Attacker leaves a USB stick somewhere on a parking lot, and curious employee plugs it in to see what's there, and reboots machine (or USB stick makes it reboot).
Wouldn't even call it "in depth", disallowing an alternative boot should be one of the first things any decent IT staff should do on any company machines, and therefore so should direct-to-consumer pre-installed tech like this.
99% of computer users are just consumers, nobody should have to think about security when they first get a new system beyond setting a password.
Then he did it wrong, because the point of the article is that systems signed with exactly this key are not trusted anymore. Only different key is trusted, and that key is used to sign Windows only and nothing else.
One could argue that distrusting platforms signed with MS's 3rd party certificate offers marginal additional security but that doesn't contradict the original point made about defence in depth.
> Whether it offers marginal additional security has yet to be demonstrated.
You're further limiting the number of images that can boot. This is a point you've made yourself so I don't really see how you need a further demonstration.
What you can argue is whether that marginal additional security is negligible enough be pragmatically worthless. And I'd probably agree with you there. However that doesn't dismiss the point that it does add a marginal additional security from the perspective of "defence in depth"[1]
I'm not convinced it does in any meaningful way. Maybe (again) marginally it might but it's trivial to disable and most Linux users are probably used to jumping into the uEFI to enable booting from install medias anyway (I know I am).
I'd argue your statement here requires a greater burden of proof than the one you're arguing against.
> You're further limiting the number of images that can boot.
That does not mean it improves security. If the images it allows to boot are less secure than those it prevents, it lessens security.
> I'm not convinced it does in any meaningful way.
It does booting Linux harder exactly to these users that it claims to protect.
So yes, it "protects" them from trying competing product.
> disable and most Linux users are probably used to jumping into the uEFI to enable booting from install medias anyway (I know I am).
Power users can do it; less experienced users consider that difficult, especially if they are not familiar with the concept. This all contributes to the image that Linux is difficult to install and use. Linux forums are full of discussions on this topic.
While it is just an artificial hindrance.
Would be it OK for Windows users to fiddle with UEFI settings before they can use Windows? If not, why is it OK for Linux users? Windows gets a clear advantage here.
> That does not mean it improves security. If the images it allows to boot are less secure than those it prevents, it lessens security.
I appreciate what you're saying but your logic doesn't really work:
- The only image allowed is Windows. Anything else is disallowed. Those images might be malicious (eg someone somehow stole MS 3rd party cert) or they might not. But not allowing them is more secure than allowing them because you're reducing your risk.
- Furthermore, saying some images allowed are less secure (ie Windows) than the ones that aren't (eg CentOS) doesn't mean this "feature" (if you can call it that) doesn't still add some additional security. Because (and at risk of repeating the above), this still blocks some additional images that might be a security risk. Hence it reducing your risk and hence it providing additional security from the perspective of defence in depth.
- The point of "defence in depth" is not to have a single security countermeasure that acts as a silver bullet against attacks. It's to provide a layered approach where cumulatively they protect you. This "feature" certainly fits that criteria.
This is why I said the question shouldn't be "does it provide additional security?" but rather "is that additional security significant enough to warrant the other impacts (such as those you've outlined?"
If you were to make that point instead, then I might agree with you. But to say it doesn't provide any additional security really misses the point of how security is evaluated.
> > I'm not convinced it does in any meaningful way.
> It does booting Linux harder exactly to these users that it claims to protect.
That's not a counterargument, it's a contradiction. I don't really see the point of a "oh yes it does" / "oh no it doesn't" pantomime style argument. If you are able to cite how the short activity of unchecking an additional UEFI option is significant enough to turn people off from the already complicated process of installing Linux then I'd be interested to see it. Otherwise we might just have to agree to disagree.
> Power users can do it; less experienced users consider that difficult, especially if they are not familiar with the concept. This all contributes to the image that Linux is difficult to install and use. Linux forums are full of discussions on this topic.
But how many of those people are buying ThinkPads to install Linux who are not power users? I'd wager if you were to draw a Venn diagram, those groups would barely, if at all, intersect. And more often than not, you have to alter UEFA parameters to boot from removable devices regardless of your setting in secure boot.
> Would be it OK for Windows users to fiddle with UEFI settings before they can use Windows? If not, why is it OK for Linux users? Windows gets a clear advantage here.
This I do 100% agree with. I never liked secure boot to begin with because of exactly this reason. Still dislike it now and certainly don't agree with what Lenovo are doing with regards to the original topic. But that is an entirely separate point to the one made previously about defence in depth.
Here I think lies the issue of our discussion. You're arguing against a technical point with an emotional claim of morality. While I completely agree with your point about morality, it's doesn't address the technical point you're trying to argue against.
> - The only image allowed is Windows. Anything else is disallowed. Those images might be malicious (eg someone somehow stole MS 3rd party cert) or they might not. But not allowing them is more secure than allowing them because you're reducing your risk.
> - Furthermore, saying some images allowed are less secure (ie Windows) than the ones that aren't (eg CentOS) doesn't mean this "feature" (if you can call it that) doesn't still add some additional security. Because (and at risk of repeating the above), this still blocks some additional images that might be a security risk. Hence it reducing your risk and hence it providing additional security from the perspective of defence in depth.
However, that is not increase in security. It is to increase the lockdown. And increasing lockdown is a poor proxy for quantification of security of specific images. It is easier, with that I can agree.
By the same token, locking out Windows images and allowing CentOS images also increases the security, but then the argument would not be about security anymore, but change to convenience of majority.
> If you are able to cite how the short activity of unchecking an additional UEFI option is significant enough to turn people off from the already complicated process of installing Linux then I'd be interested to see it. Otherwise we might just have to agree to disagree.
You had exactly that in the TFA. It invalidates PCR7, thus invalidating the TPM secrets. If the user uses Bitlocker and didn't save the recovery key, he just lost all his existing data by flipping that option.
It is another significant hoop the users have to jump; and it just happens to more complicate Linux usage. Those incompetent Linuxers, cannot make anything user-friendly...
> But how many of those people are buying ThinkPads to install Linux who are not power users?
Many normal users are not thinking about Linux when they purchase their gear; they will want to try it later, once they used the hardware for a while. If this wasn't a case and users would do research ahead of purchase, the majority of hardware problems under Linux would not exist.
> You're arguing against a technical point with an emotional claim of morality. While I completely agree with your point about morality, it's doesn't address the technical point you're trying to argue against.
My point is that it is not a technical issue. It is political issue masquerading as technical one. So a party A designs a system that favors products of party A and it just happens to thow a curveball at everyone else. Color me surprised. Real technical problem would not favor a specific party.
> However, that is not increase in security. It is to increase the lockdown.
In this instance it is both
> And increasing lockdown is a poor proxy for quantification of security of specific images.
You do realize that locking stuff down is one of the core tenants for securing systems?
> By the same token, locking out Windows images and allowing CentOS images also increases the security
If your system is shipped to run Linux then yes, locking out Windows images would increase the security.
> but then the argument would not be about security anymore, but change to convenience of majority.
You're flip flopping all over the place with different topics. If you want to talk about convenience then I agree that locking systems down affects user convenience. It's a well known adage that security is usually a trade off between convenience and protection. But you weren't talking about convenience, you were talking about security. Which is why I've been talking strictly about security.
With the greatest of respect, you're coming off a lot like you don't really know this subject matter considering how poorly you're sticking to topic and how you're misunderstanding even many of the basic principles of security.
> It is another significant hoop the users have to jump; and it just happens to more complicate Linux usage.
I agree it's another hoop but you haven't yet demonstrated how it's significant despite me asking you to substantiate that claim a few times already. It feels to me like you're just throwing in adjectives for dramatic / emotional effect rather than having a rational conversation here.
> Those incompetent Linuxers, cannot make anything user-friendly...
Why should you care what other people think about Linuxers. Just use the platform you want to use instead of seeing this as some kind of holy war where you need to convert Windows users into Linux users.
> Many normal users are not thinking about Linux when they purchase their gear; they will want to try it later, once they used the hardware for a while. If this wasn't a case and users would do research ahead of purchase, the majority of hardware problems under Linux would not exist.
I've been using Linux since the 90s (and as my primary OS since XP was released and BeOS deprecated). I've never once shopped around for Linux compatible hardware and never once ended up with a machine that couldn't run Linux because of it. Peoples complaints about Linux compatibility are, in my experience, largely over told.
> My point is that it is not a technical issue. It is political issue masquerading as technical one. So a party A designs a system that favors products of party A and it just happens to thow a curveball at everyone else. Color me surprised. Real technical problem would not favor a specific party.
I think you're talking this far too personally. The simple solution here is you can just buy someone else's equipment instead. Getting angry on a forum isn't going to change anything (tbh neither is boycotting Lenovo but at lead doing that can give you some level of control).
Changing the setting and booting an OS signed with the 3rd party signing key will result in a different PCR 7 measurement, which will result in the TPM refusing to release any secrets that would be required for the system to boot.
Anyone enabling BitLocker or any FDE really, should know to back up their recovery key so that they can access their data, should automatic unlocking fail.
Well yeah, but you asked about ordinary everyday users. And the best I can come up with is that it's marginally harder to load a foreign OS and access an unencrypted drive. You can't just plug in a USB stick and power cycle the thing.
Though I'm not sure if it's worth it, especially not if changing the bios is just a matter of seconds anyway (ordinary users probably won't put a password on it).
Oh yeah absolutely. Any docs advising people to set a password for security should also advise people to set the "Trust the Microsoft 3rd Party UEFI CA" parameter appropriately.
> [...] the firmware defaults to not trusting bootloaders or drivers signed with the Microsoft 3rd Party UEFI CA key.
The whole point of secure boot was that there is a known set of "good actors" who are trusted by default, so that you can boot 1. Windows 2. common Linux distros - without any fuss, and 3. Any other system - with a few extra steps to prove you know what you're doing.
They've de-ranked the set #2 and threw it in the bag with #3, which doesn't really do much at all to improve security, but it does inconvenience and disincentivise the users from using a Linux distro on this hardware.
It's most likely an honest mistake, a sign of incompetence, or a dick move. Write them an angry letter and carry on.
It's interesting as Thinkpads have always been a reliable laptop for linux users - I'm typing this on linux on a t470 (my previous t410 had given up the ghost), but I bought my first thinkpad back in 2000ish, with a pcmcia wireless card.
> They've de-ranked the set #2 and threw it in the bag with #3, which doesn't really do much at all to improve security, but it does inconvenience and disincentivise the users from using a Linux distro on this hardware.
Well no, it's not Lenovo really, it's Microsoft and its Device Guard / Secured Core that has done so. You can disable that just as easily as you can boot from an USB stick.
Some additional context: when the system boots, the secure boot key that was used is recorded into PCR 7[1] in the TPM. This means that booting an OS signed with the Windows signing key will result in a different PCR 7 value to booting an OS signed with the 3rd party signing key. If you care about which signing key was used, you can provide a secret to the TPM and ask the TPM to only release (or make use of) that secret if PCR 7 has a specific value. This means it's possible to configure an OS such that it will only be able to access its secrets if PCR 7 has the expected value. An attacker who intercepted the laptop before it was delivered to its owner could obviously subvert this by sealing the secret to the incorrect PCR 7 value, but such an attacker could also just reconfigure the firmware to trust the 3rd party CA before the owner received it. There isn't a clear description of what threat model this design is intended to protect against, or why alternative approaches weren't used to achieve the same goal.
[1] Modern TPMs have 24 PCRs that can be used to measure different parts of the boot process, but the general expectation is that only 0-7 will be used by the firmware. On UEFI systems, PCR 7 contains information about what the platform's secure boot policy is, and which keys were used to verify the boot process. Booting something signed with a different key will result in PCR 7 having a different value, which is something that can be detected by tying encryption keys to specific PCR values.
No contest, but if you are actually a person who is paranoid about this but still requires to have access to Windows software (in an enterprise setting), you would actually check the UEFI and reinstall Windows. If you're actually being attacked by state-sponsored actors the risk management is so different that I don't think it can be discussed here fairly (mainly because it's a case-by-case matter).
Secure Boot ensures that it's impossible to run a rootkit, even if the user accidentally installs one. Instead of booting into corrupted Windows, the system would fail to boot.
It's definitely harder, but not impossible. The Realtek signing driver was stolen multiple times already, and I personally know that certificate management practices (in Asia in general) is abysmal.
I generally agree with that, but I don't think that holds for Lenovo. Wasn't it Lenovo that compromised the security of Windows by installing a keys-included general purpose root certificate?
I'm a Linux fanboy. I don't mind having to change a thing in bios once. I care more about the standby sleep instead of S3 and other shenanigans messing my daily experience.
Tell that to anyone who can barely get past the Ubuntu installer. Every step making installing alternative OSes harder is newsworthy, for the simple reason that every bit more difficult installation means literally fewer users capable of getting through it.
But I think that's... valid? Like, if you're a person able to install (and use) a typical linux distro, on a totally open and free-range PC, then you're near-definitely also a person who knows how to use the BIOS. You were probably already in there switching the default boot device. That is, of course, assuming there is a BIOS option to disable it, which hasn't been confirmed or denied.
The reality is: installing a replacement OS post-sale is never, ever going to be the way to grow linux marketshare, if that's what you care about (it shouldn't be, but some people live-and-breathe year of the linux desktop so whatever, you do you). Its a lot more important that it ship with the hardware, and extreme attention to detail has gone into making sure it works well with that hardware. Certainly, some vendors already do this. Moreover, I'd also argue its even more important that that hardware be modern and desirable; the only vendor I've seen pull this off is Dell (genuinely sorry, because I love what Framework/System76 are doing, but their machines look like branded OEM Clevos, because they probably are, or were in the recent past. I support them; I own a Framework; but only because I want them to do better, not because what they're doing today is enough).
What I'm saying is that installing an alternative OS should be as simple as plug in the USB stick, reboot, select "bloody well install this", enter your username and password, done. OEMs, with pressure from Microsoft, are making this harder every year. Of course OEM install is the gold standard, but I suspect we're ~[MS budget]/[all Linux businesses combined budget] years away from that. In the meantime, let's move on from 90s UX[1] and actually make the process easy on users.
[1] UEFI GUIs are an improvement, but they still have 95% of the same usability issues of text-based BIOS: 1000+ settings with no hint what each of them means, XTLAs only understandable by hardware+kernel experts, unfamiliar interaction patterns like not having a big friendly button to just save and reboot, and so on.
a better solution would be to force vendors to have both OS preinstalled, and allow users to choose the default at boot, like the EU did with browsers some time ago.
First of all, this is not true. Anybody can install a distro like Linux Mint or Ubuntu, it doesn't require any tech knowledge. Many Linux distros are perfectly fine for the average user. Second, requiring complicated BIOS changes constitutes an artificial hurdle for any Linux distro to be easily installed by an average user. So even if you were right, the measure would also ensure that future versions of Linux that are decidedly more beginner-friendly would be prevented from being installed, creating an artificial, anti-competitive barrier.
In a nutshell, this is bad no matter how you look at it.
> Anybody can install a distro like Linux Mint or Ubuntu, it doesn't require any tech knowledge.
What you think as "not tech knowledge" is a serious skill that is severely lacking in billions of people.
The user needs the install medium, they need to get it, download it, create it, get a USB or blank CD/DVD, etc. They need to either have the courage (or curiosity or aloofness or determination) to modify their computer on such a drastic level, they need to understand abstract concepts, follow a written manual that uses those concepts, they need to recognize those abstract concepts as they are implemented on the computer they are currently tinkering with, and so on, and so on.
> In a nutshell, this is bad no matter how you look at it.
True, but it's bad because the whole "personal computing" thing is bad. This detail is largely irrelevant.
WYM, it's for tech savvy geeks, and also tech curious teens and also parents who refuse to upgrade a machine that's not capable of running newer Windows versions and also for...
I was 12 when I first installed linux and barely knew what I was doing. I easily would have given up if I couldn't figure out that my machine had a secret hidden bios setting. I learned a ton from that experience, that easily could have been missed if I'd happened to own one of these anti-competitive machines.
Installing a user-friendly linux distro has gotten quite simple too, requiring only a couple simple steps using some clean tools. Modifying hidden BIOS settings is a significantly more complicated leap than the plug-and-play imaging tools available today.
Ubuntu is certainly for the average user. I just installed 22.04 on my mum's ancient laptop after she's been complaining for years about it being too slow to use. No tech support so far, and she says it's blazing fast compared to the old Win10 installation. She's used Windows since the 3.11 days, so finding the "start" menu and a browser must've been a cinch. GNOME is probably less of a UI shock than Win10 was.
Asking her to install Ubuntu herself, though, would be another matter entirely. Installing any OS (including Windows, since it's about as complex as Ubuntu these days) is way beyond the skill level needed to actually use it.
Only on hacker news would people be so far removed from real life that they would say 'Ubuntu is for the average user'
And as you said, most people would not be able to install it let alone the fact they likely have no idea what it is, so in relation to this post about consumer lenovo laptops, it's irrelevant and doesn't matter to the vast vast majority of people.
> Linux is not an OS for the average user, it's for tech savvy geeks and an extremely small subset of those people too.
I recently installed Linux Mint and Windows 10. Linux was faster and easier to install, and has a friendlier UI. Have you seen the Windows start menu recently? It's cluttered with crap: I couldn't figure out how to do basic things with it, even searching was hard. You might do everything through the command line, but that's not the only way, the GUI does work.
Software's a different story, though a lot of things are online these days.
Nope. Hitting Enter or F1 brings you into Windows diagnostics rather than BIOS, at least on the Thinkpad X13 Gen 2 Ryzen Pro subnotebook w/ useless Windows installed a customer sent me for a project, and that is now contributing to a growing number of 3 bricked (brand-new!) latitude/precision and thinkpad notebook trash I'm accumulating at home. With the current state of non-existant quality in PC notebook hardware, I'm not going to buy anything except Apple hardware. Right now I'm back to using a 2016 XPS, with my 2019 Thinkpad collecting dust (and blocking its crap trackpad due to it); it's not that there are news regarding x64 performance since over ten years anyway.
A bit off-topic, but Windows changes boot order for Windows first every time you boot for Windows. This is so annoying when you are regularly booting to different OS.
The fix for this used to be that you'd just install the systems on different physical drives. Changing their boot order in Bios during install so Windows is going on the primary/boot disk. You then swap them back and update grub on your Linux side. When you use grub to boot windows it temporarily re-maps the drives before booting so that windows thinks it's the only OS on the primary drive and is happy without touching your grub setup on the 'real' primary drive.
On the other hand, having dualboot with Linux on my ThinkPad T490s managed to break my bitlocker on the windows partition every time Linux updated. Not sure why, as I really needed Windows for work I had to revert and didn't have enough time to really investigate.
Entering the recovery key is enough but the problem is my work uses software to rotate the recovery key and the last time the stored key didn't work. Probably it was just rotated but not updated in the system yet. So I had to restore fully and I removed Linux.
You might have used the same EFI partition for both, which is always unsafe.
In the future, better make own EFI partition for every OS unless you manually define directory hierarchy.
I did indeed. I thought it was OK to do that. I noticed they both made their own directory in the EFI partition. And it was what Ubuntu's installer did by default when it detected windows.
Good to know, thanks! To be honest in this day & age of virtualisation I hardly ever dual-boot anymore.
Haven't been following PCs for a while, is this now something that an OS can do? I've always assumed that boot order is a BIOS setting that's only accessible from the BIOS setup text mode thing.
Windows modifies UEFI settings on runtime. There is an API for that. Even setting password for BIOS/UEFI won’t prevent that as machine has been booted already.
Yes, under EFI the OS can set the boot order; you can do it yourself with the "efibootmgr" command on Linux. This is used for instance by fwupd to install firmware updates (it temporarily changes the boot order to boot into a firmware update loader).
It's the same company that prevents you from using whatever HDD you like or swapping out a wifi card in your laptop, a company with a constant itch to preinstall spyware/adware, etc. Limiting your choice in other ways is clearly not out of question.
If you want to explore Linux and don't know what BIOS is, it's probably better to be in a VM than trying to achieve dual-boot or totally wiping your Windows install.
Why should you care about your system firmware when you're running a modern Linux distro? I gave Ubuntu to people who had no idea what a BIOS was almost 18 years ago, and I promise things are better now.
If your can use Windows or Mac OS then you can use Linux. What does BIOS have to do with it?
My non-technical wife has installed and is using Ubuntu. With this mentioned BIOS/UEFI block it would be much more tricky for her to get started.
That's the issue here.
It'd be one thing if it were a setting to disable some feature that Linux doesn't yet support. It's another that the setting is literally "refuse to boot anything not provably made by Microsoft".
Though keep in mind that'll limit your boot drive to 2.2TB in size. Not too much of an issue now for most people, but something to keep in mind during upgrades.
I've dealt with many laptops and its not as easy as you make out. In particular I've had to open laptops to set jumpers so I'm allowed to even make changes to the boot settings.
Agreed. I’ve done this process and it didn’t even occur to me that this was done nefarious practice. It’s to prevent some typical user from getting his machine pwned.
And this isn’t Evil Microsoft dictating what vendors can do. I can install Linux on my Surface device.
You're preaching to the choir. HN mob has its pitchforks sharpened and torches out for anything PC/Microsoft related, regardless of rime or reason.
If the PC laptop would boot by default, off of any random USB plugged into the laptop, then HN mob would (rightfully) cry that this is a major PC security issues and that's how grandma could be pwned and get scammed, unlike a super-secure M1 MacBook which won't boot any other foreign OS by default without major hoop jumping.
If the PC laptop doesn't boot by default off of any random USB drive (just like a Mac), requiring the user to go into the BIOS and change this setting first, then it must be malice from Microsoft and the PC OEMs to restrict user freedom and destroy Linux's 2,43% PC market share.
> then it must be malice from Microsoft and the PC OEMs to restrict user freedom and destroy Linux's 2,43% PC market share.
It is ridiculous that people still downplaying Linux's PC market share when the latest version of Windows ships NOT ONE but TWO Linux emulators/virtualizers BOTH designed to allow you to run Linux binaries (desktop & Android) under Windows in the most user-friendly way possible.
Obviously this is because no one Windows customer cares about Linux or Linux software.
AT THE SAME TIME they take steps (and everyday larger steps) to prevent booting the same Linux on bare hardware, making their virtualization options more attractive for both the regular user and the advanced user.
At this point we're way past the "assume incompetence" point.
>It is ridiculous that people still downplaying Linux's PC market share when the latest version of Windows ships NOT ONE but TWO Linux emulators/virtualizers BOTH designed to allow you to run Linux binaries (desktop & Android) under Windows in the most user-friendly way possible.
Mate, you're contradicting yourself here more than you are contradicting me. WSL and Linux as a main desktop OS are two completely different things, and nobody is downplaying Linux's desktop market share, which is <3% no matter how you try to spin it, those are the statistics.
You are arguing that MS couldn't care less about desktop Linux market share. I point that they have actually done steps to try to capture that market share. One (the only?) new feature in WSL in Windows 11 is the ability to run _graphical_ _Linux desktop_ applications. In addition, another new feature in Windows 11 is the ability to run Android applications.
How can anyone argue with this that MS couldn't care less about Linux's market share ?
With these changes, MS "accidentally" makes running non-MS OSes harder, and this includes both Android and desktop Linux, OSes for which they have as per the above shown an interest in capturing their market share. "Accidentally", the fact they become harder to run natively also makes their new virtualization features more attractive for users.
> then it must be malice from Microsoft and the PC OEMs to restrict user freedom and destroy Linux's 2,43% PC market share.
I can only parse it in two ways:
* Sarcastic version: Linux's 2,43% market share is ridiculously small and therefore it is ridiculous to consider that Microsoft must be trying to destroy that market share.
* Non-sarcastic parsing: Microsoft is malicious and actively trying to destroy Linux's 2,43% PC market share.
You're missing the key point which is that signing for other popular OS's exists and this solution simply ignores them. Not booting anything thats plugged in, sure. But this is not booting anything not windows.
And invalidate everything in your security processor, which will possibly brick your windows installation and nuke your files if you had bitlocker keys inside that security processor.
One weird trick to ruin your day, surely.
Edit: Looks like Windows has changed since I left it, please disregard this comment, thank you. The comment is left intact for context correctness.
You can’t be storing irreplaceable keys in the TPM chip, they fail all the time. Either you don’t really need the files on the disk or you need backup keys. And note, you can’t even turn on Bitlocker without being forced to save those backup keys.
> If you want security here you're paying attention to the values measured into the TPM, and thanks to Microsoft's own specification for measurements made into PCR 7, switching from booting Windows to booting something signed with the 3rd party signing key will change the measurements and invalidate any sealed secrets.
Yeah but this is pretty bad in itself (really long number) when you're traveling. And needing the recovery key so often will lead to people writing it down and keeping it with the laptop so they're not locked out next time. Which invalidates the whole point of FDE.
The last time I had this the key didn't even work, my work rotates it regularly so something must have been out of sync.. Every Linux update seemed to break bitlocker this way so I stopped dualbooting.
But this has nothing to do with being able to boot Windows. The license key isn't in there. The TPM is used by apps to store secure data, which you wouldn't necessarily expect to even survive a reboot.
First, this is a feature of TPM (PCR 7 checks), even before Pluton existed. This literally existed in 2008 (and FSF was so scared of it because in theory it can be used for DRM, which is a valid opinion). You're spewing misinformation.
Also, for some people, they will trade-off the possibility of data loss as long as the data can be reliably destroyed if the data falls into the wrong hands. Maybe not for you, but it's there for enterprise.
Hit Enter or F1 at the red Lenovo boot screen, go into the BIOS settings and find the setting and change it.
Until someone confirms that there is no such BIOS setting, there is no story here.