MSI's (in)Secure Boot
dawidpotocki.com
dawidpotocki.com
Most people who are building their own computer are not going to be an expert in UEFI and secure boot (some may have never even heard of these things). These people are almost guaranteed to need to install their own OS. So if they try, and it "doesn't work", they are going to need tech support or most likely return the motherboard as defective. Thus it makes more sense to make the default permissive.
On the other hand, someone who does want to run secure boot securely is probably an expert, so they can probably figure out how to actually turn it on and harden their setup. As long as you can lock stuff down, having these people jump through a few more hoops seems like a reasonable trade-off.
(Also FWIW, most pre-builts or integrated devices do have real secure boot enabled, since the expectation is that users of these will likely never need to install an OS that won't work with a strict secure boot enforcement policy.)
MSI's BIOS falsely reports to Windows that Secure Boot is enabled. This is very different from just shipping with Secure Boot disabled but available. That would be pretty normal (at least of a few years ago) - but shipping with a mode where it is "enabled," and Windows is convinced that it is "enabled," even though it is doing practically nothing - that's an inexcusable situation. Assuming that I interpreted this rather vague statement correctly, of course:
> When we enter the menu, we can see the disappointing default settings. It's doing no verification. It's useless. It's just there to satisfy Windows 11 requirements. OS has no idea that Secure Boot is doing nothing, it just knows that it's "enabled".
As he says, this would totally break UEFI Spec. Secure Boot being available but disabled is OK and common - Secure Boot being available and saying enabled while actually not checking is a violation.
EDIT: Actually... the author may be wrong and, counter-intuitively, it may not break spec. https://news.ycombinator.com/item?id=34407911
Windows 11 requires information from the BIOS that Secure Boot is available, not that it is enabled.
EDIT: I stand corrected. Windows 11 is OK with Secure Boot capable if you are upgrading from Windows 10, but requires enabled for a fresh install, though Secure Boot can be disabled after installation.
> While the requirement to upgrade a Windows 10 device to Windows 11 is only that the PC be Secure Boot capable by having UEFI/BIOS enabled, you may also consider enabling or turning Secure Boot on for better security.
https://support.microsoft.com/en-us/windows/windows-11-and-s...
I think MS deliberately chose to let users upgrade from Win10 without secure boot because too many PCs have it disabled by default, and your average user cannot be expected to go into their UEFI security options to resolve that. The secure boot requirement is mostly intended for vendors AFAIK, requiring them to turn it on by default (and leaving it up to the user to disable it) so Windows 11 can make use of the additional security features out of the box.
I have a brand new desktop and Windows just flat out says you can't install it when I'm sure it just involves changing some settings.
Secure boot is another solution seeking out a problem anyway.
I doubt people installing their OS will run into this. Even still, the firmware contains the ability to prompt the user about secure boot failures, so if you're going to neuter it, at least pick that as the default option so people notice.
Instead, my suspicion is that these policies are in place so non-OS firmware can run, such as firmware update tools for upgrading the BIOS itself or perhaps management chips/HDDs/SSDs/peripheral controllers. If I were to lock down my previous laptop with secure boot, HP's firmware updates would no longer be able to run without enrolling their signature keys.
Well that's... really dumb and shows why OEM's are terrible at security, as there isn't a reason I am aware of on why Secure Boot can't trust two keys simultaneously (one for OS and one for vendor). Heck, Microsoft themselves seems to do it with "Windows + 3rd Party UEFI CA."
It makes sense to use UEFI programs to update the UEFI, but secure boot adds a layer of complexity on top of that which requires taking special notice.
Are you by chance using "consumer" models? My "enterprise" level PCs, starting with models of the intel 6th gen era, up to 12th gen, have been smooth-sailing secure-boot wise. I didn't interact with any older model.
I run Arch (which isn't signed by MS like Ubuntu / Fedora) and sign the bootloader with my own key that I've generated myself. On some computers where I need to dual-boot with Windows, I've signed MS's Windows key (not the third-party one) with my key. Everything has always worked fine, including automatically upgrading the UEFI over the network from the UEFI itself, installing Windows 11, etc.
I never needed to disable Secure Boot (apart from initial Arch install) or sign any HP-specific key. The only thing that "breaks", but that's expected and HP warns you during the update, is that whatever relies on measuring the UEFI image will break. That's typically the case with BitLocker (mentioned specifically) and LUKS.
Just the built-in update process... It doesn't always find the latest version, ie lags behind the website by weeks sometimes. Then when it checks for updates and finds there isn't a new version available, it offers you to downgrade to the previous version but apart from the text being a bit different, the blue button below still says "UPGRADE", so the first time I accidentally started a downgrade. So it started flashing the BIOS, then something like the nic firmware, then came to the Intel ME firmware and suddenly said "uh no, I cannot downgrade that" and just aborted the whole update process. No idea if it would've kept flashing other stuff after the ME, and evidently it didn't break anything, but holy crap that looks like a half-arsed feature.
There's a very good chance they changed their update procedures, but when I last ran the update I needed to run a special .efi file that would handle the flashing.
For what it's worth, I consider the HP Probook line to be excellent in terms of both durability and support. They may not be three millimetres thick like their competition but design wise they're quite alright, the machines are quite sturdy for their weight class. Their repair guide has very detailed step by step instructions on how to replace parts as well as listings of known replacement part product numbers which are great for finding replacement fans.
I think I've received at least seven years of UEFI updates, which is about 6 more than I expected for the price. HP graphics drivers actually got updates and they offer a way to keep track of updates through email without having any crapware installed. The UEFI itself is also one of the best I've used, miles ahead of the Lenovo one. The ability to browse EFI partitions and navigate to an image of your choice is excellent and I can't believe I haven't seen this on other brands.
Enrolling keys, however, required clearing the certificate cache. I could reset it back to factory settings and load the default Microsoft keys, but for their custom updaters I would need to disable secure boot or find the key they used and import it. Hardly a deal breaker, that's just how Secure Boot is supposed to work, but still something to think about when designing an updater process.
On newer models, you also have to "clear the certificate cache" to enroll your own keys. But there's an option on the same page like "reset to factory defaults", which reloads the MS keys and such.
The manual UEFI update is indeed a bit cumbersome, especially since the downloaded archive seems to be some windows executable. And, in my case, I don't remember I could navigate in the partitions, it would just complain that it couldn't find the update if it wasn't in the right directory.
I installed Fedora on a Thinkpad recently and it most definitely did not work OOTB. I had to enable the third party cert in the BIOS. Not sure about other vendors
Hum... I can't recall a single person that brought a personal computer and then installed Windows on it on the last 2 decades.
That happens with corporate computers, sure. But sysadmins know how to enable secureboot.
Interesting bubble. 50% of the programmers I know installed Windows and the rest use prebuilts that came with Windows. Same 50/50 statistics for gamers in my bubble.
People don’t read error messages. By this I don’t mean that no one ever in the history of the universe has, but rather that a high percentage will just contact tech support or RMA the board as broken. I can’t really blame mobo manufacturers from making the choice that minimizes tech support costs from consumers who won’t read and understand an error message.
Any windows version after windows 10 isn't going to work nicely without extra process if you want to do a usb install. Because the ISO file already exceed FAT 32 4GB limit.
And DVD burner? Who still have them these days?
So most people will going to use one of these 3 party tools. And some of them will use an old version tool, fail, going into support queue.
1: This is what the media creation tool essentially does, but automatically: https://learn.microsoft.com/en-us/windows-hardware/manufactu...
You don't need to store the entire ISO file on the drive as a 4GiB+ file, as long as the contents can be extracted onto FAT32 the installer can be booted.
Not only that, a popular tool for creating windows USB installers[1] fails to boot if secureboot is enabled. I looked into it a few years ago and it was because it defaults to NTFS formatting if install.wim is greater than 4GB (because of FAT32 limitations), which is most windows ISOs. Most UEFI implementations don't support NTFS, so it installs a shim loader, which is unsigned and therefore fails to boot with secureboot enabled.
https://github.com/pbatard/uefi-ntfs
Edit: https://old.reddit.com/r/sysadmin/comments/pl2jqg/creating_b... This is the last time I read anything about it from the Rufus dev (which was over a year ago)
• Microsoft refuses to sign GPL3 code for secure boot, because the anti-Tivoization clause is specifically designed to prevent this (the system basically tries to achieve what Tivo did, only supporting boot authorized by people with a given key). • The Rufus developer did work to get the GPL2 ntfs-3g drivers usable in UEFI. • Microsoft appears to have no issues signing that.
1. Every computer I've used supports NTFS in its UEFI. I even thought it was standard. So simplest way to create a bootable USB stick: format it with GPT, create one big enough NTFS partition and copy ISO contents inside. That's it.
2. Converting install.wim to sub-4GB chunks is trivial one command. Create one big FAT32 partition, copy all but install.wim, convert install.wim with `dism` and copy it.
That's it. Much easier and faster than using some tool doing strange things with shim loaders and whatnot.
Linux sticks could be created exactly the same way. UEFI is awesome.
I've never seen a motherboard supporting anything else than FAT for an UEFI partition. What is likely happening is that you're booting using a small EFI System Partition (ESP) formatted in FAT32 which contains a bootloader with an NTFS driver.
It can get confusing because the EFI bootloader generally registers new boot entries for each non-ESP partition, but these are booting the ESP with the selected partition GUID.
I've used that with few Asus motherboards (I prefer this brand) and one dell laptop. They were 2015+, so relatively modern, I guess.
I've seen exactly one model line, that does support NTFS in UEFI: Intel NUCs. It was quite nice, but nobody preparing boot media can rely on the availability, as the only mandatory filesystem is FAT32.
Then you haven't used any Gigabyte, Asus or Intel motherboard for the last 5-7 years, because all the ones I tried include a native NTFS UEFI driver alongside the mandatory FAT32 UEFI driver.
But, as others have pointed out, while it is definitely getting commoditized, you can't rely on NTFS being available in a UEFI firmware.
Great for game cheat developers for example, who often want very deep hooks on the system to bypass anti-cheat tooling and with some modern games requiring secure boot to be enabled, this could provide an interesting alternative strategy.
This means that even if Windows "checks" (via measured boot) that Secure Boot is on, they are still being lied to by the motherboard firmware.
DRTM is a credible (sort of) alternative, but at that point Secure Boot isn’t really necessary — the whole point of DRTM is that you verify the current state of the system, not how it got there.
No, but there is a standard PCR with a standard value indicating that a certain certificate was used to sign what was booted, and Windows is signed with its own certificate rather than the third party UEFI CA one.
Since Windows will force secure boot, this is a very welcome convenience feature.
It is not too hard to see that some kind of software will also try to enforce it. Mechanisms like remote attestation are pretty hostile in my opinion. This is about control for me, not about sensible security.
You can fairly easily "spoof" secure boot being enabled on a non-secure-boot system, since effectively you are exposing a 1 instead of a 0 (and with secure boot off, can hook whatever you need to). Admittedly, having a button in the UEFI menu is more convenient for an end user though.
If you have a TPM attestation of the device state, PCR 7 is sealed around the secure boot state, and that would be more interesting for someone trying to lock someone in. As you say, if your TPM is then being used to attest that the system is unmodified, then that is pretty user hostile.
For a regular normal non-technical user though, having some "sane defaults" arguably makes sense - if we raise the bar on compromising a regular person's computer by a few notches (i.e. you can't just replace the bootloader with a keylogger and chain-load the regular bootloader), it can help with platform security. The problem is that, on top of that platform, end users run all kinds of (what we'd previously call) spyware/adware, which just sends their data off the system. When this "non-technical user protection" starts to get in the way of expert users, that's when it becomes more of a problem for being in control of your own system.
The most locked down systems are the ones that expose the most data. Granted, that is because of the type of the device in many cases, but that is the current reality.
Not for every user. Besides, the protections this would offer would be easily and cheaply circumvented via a raspberry pi and usb peripheral emulation. The is no escaping the analog hole as you stated.
I'm not willing to give up my control as an owner over my device for a reason as flimsy as this. Gamers who want to give up control for a slightly lower percentage of cheaters can get dedicated computing hardware (consoles) instead.
> Not for every user.
Not every feature has to benefit every single user. Otherwise let's just remove WSL because it's in use by <1% of Windows users.
> I'm not willing to give up my control as an owner over my device for a reason as flimsy as this. Gamers who want to give up control for a slightly lower percentage of cheaters can get dedicated computing hardware (consoles) instead.
Okay, then turn off Secure Boot. And just don't play these games. No one's saying all computers must have Secure Boot on and untoggleable.
Secured Core is optional and it's very enterprise-focused, i.e.: businesses gating domain join to Secured Core PCs for extra perimeter control.
I see this claim made over and over, yet we are still to see an actual "act of aggression" (modulo incompetence of an individual vendor - slip ups happen[0]). Every single PC system I ever heard of, allows either enrolling your own keys, or just disabling secure boot; most accept the MS-signed bootloader shim found in common desktop distros; I think this is even mandated in MS' specification that it must be possible for the users to bypass this.
If you haven't had a trojan in the last 20 years, you have been diligent and/or lucky. Scattershot malware (cryptolockers, miners) is incredibly common, one of our customers was hit several times (on systems we weren't managing). More sophisticated attacks are an everyday thing against high-value targets[1][2]. Exploiting computer (in)security is a multi-billion dollar business, platforms far more locked down than PC are being routinely targeted and exploited. Real people, fighting for IRL freedom - journalists, activists, opposition politicians - are in danger.
Please stop spreading the FUD against secure boot, and please back your claims with facts.
[0]: https://mjg59.dreamwidth.org/59931.html https://news.ycombinator.com/item?id=32023868
[1]: https://techcrunch.com/2023/01/14/circleci-hackers-stole-cus...
https://arstechnica.com/information-technology/2015/03/windo...
Did secure boot stop those malware attacks? Somehow despite secure boot being enabled as default for like 10 years I still routinely hear about XYZ getting hit by ransomware so I'm guessing no. Software freedom can help IRL too.
Secure boot is designed to stop a class of APTs, it is by itself ineffective at preventing malware infection.
> Software freedom can help IRL too.
I never argued against software freedom (or freedom in general) - quite the opposite. But I am disturbed whenever free software advocates paint freedom in one-dimensional terms. You can have hardware that is designed to compromise one of your freedoms, but simultaneously reinforce another. And you can often still utilise that hardware to empower the user, without any compromises. However the rhetoric keeps boiling down to "secure = locked down = non-free = evil".
Thank you for the article.
On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies.
The primary vector of malware isn't near boot, it is quite exotic these days. Maybe not rare, but not the primary attack for usual targets. But that is also irrelevant if I could just spoof any attestation. Just give me the option. Shouldn't be too much of a request, no?
One prediction is that there will be classes of devices. Trusted and untrusted. We already see that happening. This is not desirable for security and in the interest of users. That especially includes journalists and activists.
For security it isn't enough to wait for aggression, you also have to look at a larger picture. Some people argued HDCP is to shield against eavesdropping.
And it if is in the interest of security, you would need to propose very foundational security arguments. As it is exposing your security state to third parties is an additional threat itself.
You have the same recourse as you've always had. Vote with your wallet, don't buy the hardware.
I am much more concerned about Intel ME and AMD PSP, where's the outrage about that?
> But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry.
Can you please link me some articles/references? This is relevant to my interests, I would like to actually see something that backs up the counter-argument.
> On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies.
I'm aware I'm stretching things, but the stance "Secure Boot = attack on computing freedom" is quite regularly stretched to argue against many other hardware security features, such as TPM or Secure Enclave. If my laptop is stolen, confidentiality of all my data is only as good as my passphrase. Am I paranoid enough to employ a complex, unique, zxcvbn-proof passphrase? Hell no. I would much rather use four random dictionary words, and let the TPM throttle cracking attempts.
(Yes, I know LUKS offers KDF, with a number of iterations picked to reasonably throttle cracking attempts on today's hardware. I would still rather see the cracking stopped dead after 10 attempts, and this physically requires dedicated hardware.)
It's 2023, Thinkpads have been shipping with TPMs for over a decade, and I still can't easily utilise a TPM to keep the FDE decryption key - is it because the TPM genuinely does not offer tangible improvement over plain LUKS, or is it because it was being actively pushed back against in the free software community, and nobody bothered to integrate the functionality?
Repeat this for GPG/SSH/FIDO keys, I am expected to buy a dongle that I can lose, and plug it into a USB port - but can't sensibly utilise the hardware that has been soldered onto my motherboard, which was designed with that explicit purpose?
Please correct me if I'm wrong, but all I'm seeing is a pattern of: "dedicated security hardware = attack on freedom", with pushbacks at any attempts to utilise such hardware for the benefit of the user.
> The primary vector of malware isn't near boot, it is quite exotic these days.
APTs / evil maid never stopped being a thing. Security isn't about what's unlikely, it's about the entire chain. Maybe your targeted attack requires a key logger to remain dormant/undetected until a particular moment in time, six months from now, and the best way to hide it is by paravirtualising your kernel. We've seen attacks way more sophisticated than that (stuxnet).
> But that is also irrelevant if I could just spoof any attestation.
I agree 100%, attestation is just layers of bullshit. But I still want my device to ring an alarm if an APT is suspected.
Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...
So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited.
> > But that is besides the fact that these acts of aggression
A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-...
Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do.
My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell.
> Vote with your wallet, don't buy the hardware.
> ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that?
With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers).
> I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality?
I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.)
> Security isn't about what's unlikely, it's about the entire chain.
... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).
> If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited.
This is exactly the area where I would double down on the "vote with your wallet" argument. There is enough variety and choice in the Android ecosystem, and if you do really care about running LineageOS / GrapheneOS / PostmarketOS / etc, you probably already know what your options are.
> With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers).
You will always be able to buy hardware and support vendors that are explicitly non-hostile. System76, Frame.work, MNT... More maintstream options also exist, Dell was shipping laptops with Ubuntu as far as in 2006 (I remember it was big news at the time, I don't know how is it like nowadays). Even Apple seems committed to allowing (quietly encouraging?) third-party OS's, so I'm watching the progress on Asahi as well.
> A great thread and arguments provided here, how Microsoft [...] will not sign anything GPLv3 for SecureBoot
Complex licenses result in complex issues. I understand why FSF chose to design that license the way they did, but it's my personal opinion that they've caused more harm to the users of their software with it than they've done good. Software has value when it can be used. If I can't use it (e.g. because my vendor won't ship it), it has no value to me.
I don't understand why Free Software advocates want their users on non-free platforms to suffer. Just a couple days ago someone on HN suggested that GIMP shouldn't have been ported to M1 Macs[0]. Emacs disables already-working features, because support exists only on macOS[1]. The BSDs had to ship with years, almost decades old forks of GCC[2]. I think these moves are an underhanded attack on the users' four software freedoms. I might have no choice of operating system (e.g. because this is what my employer mandates, this is the hardware that I was able to afford, there is other non-free software I must run to earn my living, etc), and FSF/RMS think I should be punished for that.
From my (user's) point of view, neither FSF nor MS care at all about what benefits me - the user, and instead just want to play out some petty political conflict.
[0]: https://news.ycombinator.com/item?id=34392834
[1]: http://xahlee.info/emacs/misc/emacs_macos_emoji.html
[2]: https://man.openbsd.org/gcc-local.1
> But if I followed through, then still the weakest point is/becomes the keyboard.
Nope, keyboard has no more importance than any other part of the device. Once an adversary has physical access, all bets are off. Nuke it from the orbit, restore from backups, and rotate all credentials.
I have had a good example of a late realization where choosing the right iirc car/phone in advance would have been needed to avoid incompatibility, but I forgot what it was.
About the laptops: I looked at Tuxedo first, I liked the big battery but disliked the rest. As I continued reading, I found out they are reusing OEM laptop chassis, so their only contribution is branding an a distro customization (probably to integrate it better with hardware). I suppose it's what most others do too. After this realization I began looking at mainstream manufacturers and "compromised" on a good model without an OS pre-installed or proprietary plugs.
Would I want to compromise on price or features to set a clear signal? At least MS didn't get paid for the license :)
About FSF: oh that Emacs story is terrible. Outside of this idiotic disablement, I can understand both sides. "I cater to users, but at the same time I don't want to spend my time enriching an Apple/MS ecosystem for free". Ranted about by wm4 of mpv[1]. This doesn't apply to willing maintainers :)
[1]: https://web.archive.org/web/20200709194653/https://github.co...
Another point about GPL licensing was brought up in no pretty words by digdeeper[2]. Someplaces twisting words and the intended logic, but it is an argument close to OpenBSDs:
> GPLv3 is (in our opinion) not actually free, and we are not able import anything encumbered by it. GCC 2.4.1 and Binutils 2.17 are the last GPLv2 releases.
[2]: https://web.archive.org/web/20210122132451/https://digdeeper...
My own conclusion: if you want a revolution, an opposition to the closed source (enterprise world) then you show it with a GPL license. To make sure the fruits of your labor are not exploited and only the FOSS part of the software world grows richer. You see where the rhetoric is going. The good examples are coreutils and GNU libc. The bad examples: only few giant companies care to follow the license terms. Many avoid GPL, many exploit it ignoring the terms.
TLDR: If you want improve some part of computing in the world, BSD or MIT. If you want to have a FOSS project, a variant of GPL (imho).
About politics: I wonder how many are actually still developers and not some... non-developing profession? Although FSFE (Europe; with no affiliation to FSF) exists, I was surprised to learn they only have lawyer and related positions to offer. No development happening apparently.
Well it means it's not an important factor for those people. 99.99% of the market is served by a device that runs WhatsApp, TikTok, Google Maps, and the local banking app. For most people, "freedom" is the freedom to have the free time to talk to their parents who are half a world away from them; NOT the freedom to mess up their bootloader.
I stand by my claim: if you care about these issues, you know what to buy.
> My own conclusion: if you want a revolution, an opposition to the closed source (enterprise world) then you show it with a GPL license.
I don't want any revolution, I want Free Software to be objectively better - because using bad software just sucks. Free Software should be able to go toe-to-toe with proprietary software, heck even be just better - it has the clear advantage of accumulating volunteer contributions and so on. And yet rather than building a better product that can win with the alternatives by its own merit, we're caught up in bullshit political games.
That's exactly the problem with FSF, they're long done actually improving their software, and are just using their position to leverage themselves politically, while making choices that actively hurt their user base. Their technology is stagnating and becoming more and more irrelevant as alternatives are catching up or surpassing them (clang/llvm), most remaining value is in broad (in)compatibility (glibc, bash, coreutils), which hurts other FS projects too (*BSD, Alpine). I've been using Emacs for 20 years and feel more and more trapped with it - no other editor/IDE comes close, despite FSF's efforts to undermine the project. As a potential contributor, I'm scared away by their practices of turning down improvements on political grounds. As a user, I feel trapped in their staged shitshow.
You know the tree by its fruit.
As a potential contributor I suggest you to be present on their mailing list (filter for OSX and other keywords if you wish) to have a voice when needed.
> Their technology is stagnating and becoming more and more irrelevant as alternatives are catching up or surpassing them (clang/llvm)
I would say clang+LLVM is a poor example, because for C/C++ they're directly comparable in final performance (state of the art). The Clang suite is newer and I'd argue benefits from this and the lack of legacy. Then Apple has it as their compiler of choice and this entails a lot of dedicated work force.
Instead I'd say GNU/FSF have stagnated in their methods of collaboration. I've looked at their GCC website. It probably looked not too different in 1999. That's not a bad thing but mailing lists... I understand the love for e-mail but not the mailing lists. I think if the wonder called Rust didn't embrace the new ways of thinking, communication and tooling, it would not have developed into what it is today and as fast as it has.
Finally GNU/FSF may have served their purpose. They spawned the idea of radically free and open source software. A decade later (1990s-2000s) the thousands of neat programs were being made for Win32 and very few developers chose to open source their creations even when the software was perpetually free. "I dont want others to see my code" sometimes out of fear of being judged, remember those arguments? Think of the developer effort wasted in discontinued programs that are no longer available/working and either have no successors or their successors had to be remade from scratch. Thankfully nowadays the mentality has changed and it's rare to see a free/shareware program that still remains closed to the public.
Do you think secure boot stops cryptolockers? By what means?
You took my sentence out of its specific context (GP was arguing that they hadn't had any malware in 20 years), and put it in another, where quite obviously my argument is painted much weaker.
Almost all major Linux distributions (i.e. the ones with an easy install disc image you write to a USB stick) use a signed bootloader, and shim or mok or another way to validate the boot chain - the installer will boot fine, and after install, the OS will boot fine, under secure boot.
Windows since 8.0 (?) has also shipped signed - installer and resulting install will both work.
Unless you're dealing with an edge case (i.e. you want to install a non-secure boot capable Linux OS, or BSD or something less common, which isn't using a signed loader), an end user should never really encounter secure boot issues in theory. That's not to say there shouldn't be an "off" switch; but that these days there are very few scenarios where an end user doing their own OS install will hit a secure boot failure.
The failure rate of motherboards is only ~3%, imagine adding an extra 1% on top...
(I know you're trying to make a point with the 1%, but _any_ reduction in support tickets by adjusting the secure boot default (which is essentially free) is going to be worth it to the manufacturer. )
And it’s there to disable if you don’t want it.
What's funny is that "Allow Execute" and "Query User" options are breaking UEFI specification
They're giving the user freedom, which the specification is against. IMHO they chose the right path. Willful disobedience applies to software too. My opinion of MSI just got a little better.
MSI did not add any of these features, they are available in EDK II. https://github.com/tianocore/edk2/blob/9ce09870e721efacc41fa...
It's been a sad state of affairs.
So it's not that some evil maid could replace the boot chain and update the firmware settings to make it behave as if nothing happened.
Just for those folks who use and want it.
And maybe also introduce a TOFU model i.e. "allow execute" but ask when the hash changes, so booting the same unsigned binary is OK but updates aren't silently allowed and require a quick confirmation (possibly with a timer for unattended reboots). Won't help against physical attacker but should help against a malware that manages to get root and tries to install itself into the boot chain.
Meanwhile, there is a really weird segment of "security people" that focus a whole lot about attestation and signatures and "secure boot" and the like but very little about what actually ends up breaking systems. Call it the Sony syndrome where you ship 15 layers of chainloaded bootloaders and security systems but don't bother updating the years old WebKit. Apple has it too, always money around for implementing another mitigation scheme in XNU but if you ask why nobody updated the outdated open-source PDF library embedded in their Objective C messaging program it's crickets.
Well, it's another level of sophistication, requiring some more investment?
Replacing a bootloader or a kernel (or initrd) and disabling Secure Boot is easy for just about anyone with 5-10 minutes access to a machine. A modified keyboard is less so.
IMHO if you're truly worthy enough to be targeted by such attacks, "secure" boot isn't going to stop them.
Given that often physical access allows secure boot to be turned off, it’s clearly not made to protect against a physical attacker.
Now, what’s left is a bit of a mixture of a political issue and developer laziness that makes secure boot a binary toggle of on=boots only microsoft-sanctioned OSes and off.
Ideally there was a safe way for a user to get their own boot loader and OSes signed to allow them to safely boot their own OS while still being sure that it was the user‘s intention to boot that thing.
Ironically, walled-garden Apple went exactly there with their secure boot implementation on their Apple Silicon macs (source: https://social.treehouse.systems/@marcan/109679905123512668)
It helps if you remember the context in which Secure Boot was created. Back then, boot sector viruses and similar malware were common. The way they operated was by hooking the operating system while it was being loaded. The operating system (or software running on top of it, like anti-virus and other anti-malware stuff) could protect itself against something which loaded after the kernel and device drivers, but not against something which loaded before the operating system kernel itself.
That is: the main threat model Secure Boot protects against is boot sector viruses and similar. Even if some malware gets write access to the full raw disk, it still cannot inject itself before the kernel in the startup sequence.
At the time the Secure Boot was conceived, boot sector viruses were extinct by about a decade. What was new, was the VM* set of instructions, and the scare that there could be a new kind of boot sector viruses slash hypervisors, which could do a bad things to your computer. There was never such a virus in reality, only hypothesized.
Not really, Petya was in 2016.
(It's not to secure your computer -- that will remain a roach motel of unpatched exploits. But it will be a roach motel that runs Windows rather than something else).
Installing linux.
Yes yes you can disable it (for now), put your own keys (very unlikely) but if you do windows will not boot any longer, unless you also disable disk encryption before disabling it.
Do like rms and think long term. The feature is there to lock which software can run on the machine, and prevent the machine to be used to rip movies.
They really cannot. Of course, this means you have to properly secure other knobs as well: Setup password, custom certificates (so a compromised Redmond certificate is irrelevant, configure your OS to use measured boot and abort on all changes, ...
This would mean: Secure Boot cannot be disabled; Software cannot be swapped out; DMA devices cannot be added.
If properly implemented, Secure Boot, a TPM and full-disk encryption will create a PC that cannot be internally compromised by regular thread actors. External additions (keyloggers and the like) are still possible of course.
Secure Boot has always been an anti-feature, at least from the user's point of view. It seems really strange to complain your device isn't locked down enough by default: the restrictions can always be enabled manually if that's your kink.
It adds a DOS partition (!!!) to the disk, and prevents me from for example dual booting two versions of Debian on the same machine.
The whole thing has a bad smell of Microsoft around it, which translates to hidden motives (make it hard to not run Microsoft on this hardware) and insecurity (because they don't do "secure". They never did).
If you want "secure boot" - get hardware that support "legacy boot" and boot something else than Microsoft Windows ;)
It is a FAT32 partition; most DOS versions are unable to read it.
> prevents me from for example dual booting two versions of Debian on the same machine.
It doesn't; UEFI doesn't care what is the boot image, only that there is some. You can register as many boot targets as you want. Check efibootmgr in one of your debian instances, if your installer is not capable of doing that.
It absolutely does not.
Pretty much. The mainframe security model used by desktop OSes is fundamentally broken.
Are you confusing a bootkit (ie. malware that's in the boot loader) with malware that's in the firmware itself? If it's just in the boot loader, that's still stored on the hdd/ssd itself, and therefore can be wiped.
Secure boot is indeed designed to protect against bootkits too.
https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
https://www.notcpa.org/about.html
Windows 11 and TPM are about locking down the PC and turning it into a mobile device.
What do you think MMO's and steam were for the last 23 years? There's been a war on local exe's and your file system, driver signing in hte windows 2000 and XP days was Microsoft and hardware vendors working out the bugs of moving us to encrpyted input output.
They are selling it as "trusted computing" but its all for enforcing software licenses so you can't access the files. That's what NTFS was for in reality, it was about the return of mainframe computing, that's why windows 10/11 is a client-server OS and why windows 10 has forced updates.
The whole thing is to turn the PC into a console where app developers can update the firmware/bios with new encrpytion keys if the exe's get cracked.
That was the whole point of Secure boot, it was first used in consoles and the same tech in phones.
Apple, google, and the entire industry has wanted to kill piracy and enforce copyright ruthlessy.
Ever notice the rental ad on Youtube? Google would like to turn files into bits of property you can sell via encrpytion and can't accesss.
The big lockdown is coming because they saw the profits of locked down computing devices.
So no Secure boot is about killing Win32 EXE's and moving us to win 3, with Denuo levels of protection on executables.
With Trusted computing microsoft can force update security policy over all EXE's with the new exectuable model and the mmo/steam generaiton enabled all this over the last 23+ years starting from 1997 with ultima online and everquest in 1999.
That's why basic features like multiplayer game hosting inside local apps (like quake 3 and Unreal tournament 2004) disappeared.
The whole point was to move us back to mainframe computing of the 60's with draconian copyright enforcement.
Of course blocking execution is orthogonal to verifying the boot chain, but unfortunately those issues are conflated in the UEFI spec.
If instead the decision had been made to have the user set up some keys and authorize the OS, the process would have to be streamlined and easy.
In conclusion, signing your operating system is too hard, unless you are in the happy path where your OS is signed by Microsoft it is far easier to just disable the infernal subsystem as it gets in the way.
This is false.
The issue is that nobody has written user-friendly tooling to manage keys and sign stuff. Not that actually implementing this is hard.
You can defend against the bad guy disabling SB in the UEFI settings by password locking the UEFI setup. I don't know how common it is but all the mobos I've used for home PCs have such an option. Of course whether mobo manufacturers implement password locking correctly is another matter.
Another line of defence is a chassis intrusion alarm to prevent the attacker from switching to alternate BIOSes and such, but those are normally only found in enterprise cases in my experience, and of course are not completely attacker-proof either.
It's the standard bike lock tradeoff - perfect security is unattainable so you just put more and more roadblocks in the attacker's way to deter them hoping that they give up and go for an easier target. Although, unlike a bike lock, someone attacking your PC is probably doing a targeted attack anyway.
On some desktops, you can't. There is a physical jumper that resets all the settings, and this includes removing the password.
This means that even if you setup FDE correctly (binding to say PCRs 0, 7, and 11), you would be able to bypass FDE using this MSI bug. For example, BitLocker binds to PCR 7.
You could get around this bug by sealing to PCR 4 (which contains the _hash_ of the bootloader). But then you have to redo FDE sealing every time your bootloader updates.
A sane setup might not be using TPM because, e.g.: they don't need it.
I don't use TPM for FDE, just a passphrase. Using TPM means that if my motherboard dies, I can no longer access my disk. Far from ideal.
> a bad guy could easily disable secureboot inside bios settings
Can this be usually reconfigured without the firmware passphrase?
> use shim loader to bypass it.
They'd need to get it signed with the key trusted by the local firmware.
I'd have preferred this to what happened on my MSI MEG X570 Unify motherboard when I recently updated the BIOS and installed a TPM module - grub was prevented from loading up my debian system because secure-boot got activated by default. I had to hunt around and de-activate to continue using the system.
Might be better to disable it by default, though. Do other motherboards support this "feature"?
Much better than the all or nothing model of secure boot.
IIRC EVGA and Gigabyte have "Audit mode" option in their firmware, which does only logging.
Thanks, MSI.
For a motherboard I updated a week ago (B350 PC Mate) I did notice the following item in the changelog:
> - Change the default setting of Secure Boot.
So it was mentioned in the changelog, just very vaguely.
I applied an update with that changelog line recently and it definitely now turns Secure Boot on (presumably in this "non-enforcing" state mentioned in the article) by default when it previously didn't.
In the end I just disabled the secure boot all along. It's just broken and didn't work.