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.