[romaniv]

I still hope that one of these days people in general will realize that executable signing and SecureBoot are specifically designed for controlling what a normal person can run, rather than for anything resembling real security. The premises of either of those "mitigations" make absolutely no sense for personal computers.

[arcfour]

I strongly disagree on the Secure Boot front. It's necessary for FDE to have any sort of practical security, it reduces malicious/vulnerable driver abuse (making it nontrivial), bootkits are a security nightmare and would otherwise be much more common in malware typical users encounter, and ultimately the user can control their secure boot setup and enroll their own keys if they wish.

Does that mean that Microsoft doesn't also use it as a form of control? Of course not. But conflating "Secure Boot can be used for platform control" with "Secure Boot provides no security" is a non-sequitur.

[whatevaa]

Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop. Calling it useless because it doesn't match your threat model... I hate todays security people, can't threat model for shit.

[AnthonyMouse]

> Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop.

Both of these are super easy to solve without secure boot: The device uses FDE and the key is provided over the network during boot, in the laptop case after the user provides a password. Doing it this way is significantly more secure than using a TPM because the network can stop providing the key as soon as the device is stolen and then the key was never in non-volatile storage anywhere on the device and can't be extracted from a powered off device even with physical access and specialized equipment.

[mschuster91]

> The device uses FDE and they key is provided over the network during boot, in the laptop case after the user provides a password.

Sounds nice on paper, has issues in practice:

1. no internet (e.g. something like Iran)? Your device is effectively bricked.

2. heavily monitored internet (e.g. China, USA)? It's probably easy enough for the government to snoop your connection metadata and seize the physical server.

3. no security at all against hardware implants / base firmware modification. Secure Boot can cryptographically prove to the OS that your BIOS, your ACPI tables and your bootloader didn't get manipulated.

[AnthonyMouse]

> no internet (e.g. something like Iran)? Your device is effectively bricked.

If your threat model is Iran and you want the device to boot with no internet then you memorize the long passphrase.

> heavily monitored internet (e.g. China, USA)? It's probably easy enough for the government to snoop your connection metadata and seize the physical server.

The server doesn't have to be in their jurisdiction. It can also use FDE itself and then the key for that is stored offline in an undisclosed location.

> no security at all against hardware implants / base firmware modification. Secure Boot can cryptographically prove to the OS that your BIOS, your ACPI tables and your bootloader didn't get manipulated.

If your BIOS or bootloader is compromised then so is your OS.

[mschuster91]

> If your threat model is Iran

Well... they wouldn't be the first ones to black out the Internet either. And I'm not just talking about threats specific to oneself here because that is a much different threat model, but the effects of being collateral damage as well. Say, your country's leader says something that makes the US President cry - who's to say he doesn't order SpaceX to disable Starlink for your country? Or that Russia decides to invade yet another country and disables internet satellites [1]?

And it doesn't have to be politically related either, say that a natural disaster in your area takes out everything smarter than a toaster for days if not weeks [2].

> If your BIOS or bootloader is compromised then so is your OS.

well, that's the point of the TPM design and Secure Boot: that is not true any more. The OS can verify everything being executed prior to its startup back to a trusted root. You'd need 0-day exploits - while these are available including unpatchable hardware issues (iOS checkm8 [3]), they are incredibly rare and expensive.

[1] https://en.wikipedia.org/wiki/Viasat_hack

[2] https://www.telekom.com/de/blog/netz/artikel/lost-place-und-...

[3] https://theapplewiki.com/wiki/Checkm8_Exploit

[amatecha]

they said network, not internet :)

[tremon]

> the device uses FDE and the key is provided over the network during boot

An example of such an implementation, since well before TPMs were commonplace: https://www.recompile.se/mandos

[arcfour]

I (the commenter you responded to) am a security engineer by trade and I'm arguing that SB is useful. I'm not sure if the parent commenter is or isn't a security person but my interactions with other people in the security field have given me the impression that most of them think it's good, too.

So I'm a little confused about the "can't threat model for shit part," I think these sorts of attacks are definitely within most security folks threat models, haha

[account42]

Security professionals wanting to have security solutions they can sell to people doesn't mean that those people actually need or benefit from those solutions. Security professionals tend to vastly overestimate the relevant threat models relevant for regular people and have no concern for anything other than so-called security.

[serf]

>It's necessary for FDE to have any sort of practical security

why? do you mean because evil maid attacks exist? anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.

>bootkits are a security nightmare and would otherwise be much more common in malware

why weren't they more common before?

serious question. Back in the 90s viruses were huge business, BIOS was about as unprotected as it would ever possibly be, and lots of chips came with extra unused memory. We still barely ever saw those kind of malware.

[arcfour]

> anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.

Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run. With SB at least in theory you have a way to validate the entire boot chain.

> why weren't they more common before?

Because security of the rest of the system was not at the point where they made sense. CIH could wipe system firmware and physically brick your PC - why write a bootkit then? Malware then was also less financially motivated.

When malware moved from notoriety-driven to financially-driven in the 2000s, bootkits did become more common with things like Mebroot & TDL/Alureon. More recently, still before Secure Boot was widespread, we had things like the Classic Shell/Audacity trojan which overwrote your MBR: https://www.youtube.com/watch?v=DD9CvHVU7B4 and Petya ransomware. With SB this is an attack vector that has been largely rendered useless.

It's also a lot more difficult to write a malicious bootloader than it is to write a usermode app that runs itself at startup and pings a C2 or whatever.

[AnthonyMouse]

> Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run.

Except that it's on the encrypted partition and the attacker doesn't have the key to unlock it since that's on the removable media with the boot loader.

They could write garbage to it, but then it's just going to crash, and if all they want is to destroy the data they could just use a hammer.

[arcfour]

The attacker does this when the drive is already unlocked & the OS is running.

Backdooring your kernel is much, much more difficult to recover from than a typical user-mode malware infection.

[AnthonyMouse]

> The attacker does this when the drive is already unlocked & the OS is running.

But then you're screwed regardless. They could extract the FDE key from memory, re-encrypt the unlocked drive with a new one, disable secureboot and replace the kernel with one that doesn't care about it, copy all the data to another machine of the same model with compromised firmware, etc.

[cyberax]

> serious question. Back in the 90s viruses were huge business,

No, they were not. They were toys written for fun and/or mischief. The virus authors did not receive any monetary reward from writing them, so they were not even a _business_. So they were the work of individuals, not large teams.

The turning point was Bitcoin. Suddenly it provided all those nice new business models that can be scaled up: mining, stealing cryptowallets, ransomware, etc.

[jyrkesh]

Malware was absolutely used to sell botnet access in the 90s, millions of Windows machines were used for DDoS and as anonymous proxies

[otterley]

The '90s was a bit too soon for that. Most people using the Internet then were still on dialup, to the extent they were connected at all. There weren't that many DDoSes yet. Even the Trin00 DDoS in 1999 only involved 114 machines.

[cyberax]

DDoS for sale were not a big thing until Bitcoin. You couldn't transfer meaningful amounts anonymously.

And no, lol. There were no million machine botnets in 90-s. You could DDoS the entire countries with a few dozen computers, Slammer did that accidentally with Korea.

[jrm4]

Secure Boot provides no useful security for an individual user on the machine they own, and as such should be disabled by default.

If you want to enable it for enterprise/business situations, thats fine, but one should be clear about that. Otherwise you get the exact Microsoft situation you mentioned and also no one knows about it.

[arcfour]

So everyday users should be vulnerable to bootkits and kernel-mode malware...why, exactly? That is useful security. The fact that people do not pursue this type of malware very frequently is an effect of SB proliferation. If it were not the default then these attacks would be more popular.

[account42]

Every day users care most about the files in their home directory (or cloud services these days). The OS kernel and ring 0 isn't any more important to them than that.

[jrm4]

Ooh, I like this argument a lot. Right now I'm thinking a good analogy is, you live in a gated community, but the locks on your house and your ring camera are fine -- but your overly annoying gate system makes it hard for people or deliveries to get to you etc.

[romaniv]

This is a tiresome argument that is based on a pile of unstated and rather shaky assumptions, ignores the very concept of opportunity costs and does not consider alternative solutions to the problems you seem to consider so important.

Fir starters, UEFI Secure Boot is actually rater bad at protecting users from bootkits or kernel-mode malware or anything, really. You can search this very website to get a giant list of bypasses and news about leaked vendor keys. Not to mention the fact that CrowdStrike Falcon incident had clearly demonstrated that Microsoft is more than happy to sign utterly insecure garbage.

Also, the issues with boot malware and kernel verification could be solved in many other ways, many of which are much more sensible or elegant. For example, by storing the bootloader and its keys on a physically separate read-only medium.

The issues with UEFI Secure Boot are actually the main point of the system, just like the issues with Windows executable signing are the whole point of that system.

[fsflover]

Instead of proprietary SecureBoot controlled by megacorps, you can use TPM with Heads based entirely on FLOSS with a hardware key like Librem Key. Works for me and protects from the Evil Maid attack.

[arcfour]

You can also use SB with your own keys (or even just hashes)...just because Microsoft is the default included with most commercially sold PCs—since most people use Windows on their PCs—doesn't mean SB is controlled by them. You can remove their signing cert entirely if you want. I have done this and used my own.

Plus they signed the shim loader for Linux anyways so they almost immediately gave up any "control" they might have had through SB.

[jasomill]

Won't removing the Microsoft key prevent UEFI option ROMs from PCIe cards from loading when Secure Boot is enabled?

Is it even possible to install firmware containing an oprom resigned with a custom key onto, say, a modern Nvidia GPU, without the entire firmware bundle being signed by Nvidia's own key?

[kelseyfrog]

Anything that restricts user freedom is entirely bad, even if it's at the expense of security.

[arcfour]

But...it doesn't restrict user freedom. If the user wishes to do so, they can disable SB.

[CodesInChaos]

And will then be locked out from an increasing amount of Applications, Media, and eventually even Websites.

[arcfour]

I run Linux with Secure Boot and I don't feel locked out of any media, applications, or websites.

My mom uses Secure Boot with Windows and doesn't know or care that it's enabled at all.

[heavyset_go]

The OP is describing the status quo on mobile phones and tablets. On mobile Secure Boot, and systems like it, are used to lock out the user. If the boot path integrity is altered, some apps won't work or will provide degraded experiences.

What's happening the article is what has already happened on mobile: it requires vendor signing to run anything on mobile OS and the vendor locks out 3rd party drivers from their OS entirely.

It's yet another step towards desktop computing converging with mobile when it comes to software/firmware/boot/etc integrity attestation, app distribution and signing, and the ability to use your own bootloader and system drivers. When Secure Boot was first rolled out on laptops, it was used by Microsoft to lock the user out of the boot process before it was adapted to let users register their own keys, it can always be used for its original purpose, and how it's currently used on mobile, again.

[kelseyfrog]

They shouldn't _have_ to do anything. The point is that no demands should be placed upon users.

Same problem with age gating. It's fine, as long as zero additional demands are placed upon users.

[robotresearcher]

Freedom from the consequences of malware is more valuable than the low cost of turning SecureBoot off if you don’t want it.

We shouldn’t need the hassle of locks on our home and car doors, but we understand they are probably worthwhile for most people.

[thisislife2]

Do you lock your house or car and permanently handover the keys to some stranger, who you then have to depend on always to lock or unlock it for you?

[aeternum]

What's the improved security argument for terminating VeraCrypt's account though? SB does have clear benefits but what is unclear is the motivation for the account termination.

What's the likelihood that this account ban provides zero security benefit to users and was instead a requirement from the gov because Veracrypt was too hard to crack/bypass.

[UrMomsRobotLovr]

Are the demands that users become experts in provider their own security against more advanced actors not significantly worse? The control part is unfortunate but the defaults should make it so users can focus on sharing pictures of cats without fear or need for advanced cyber security knowledge.

[bigfatkitten]

Users who care enough to do so can enrol their own keys using the extremely well documented process to do that.

Users who don’t care about the runtime integrity of their machine can just turn it off.

Both options are so easy that you could’ve learned how to do them on your machine in the time that you spent posting misinformation in this thread.

[brookst]

So like banks requiring you to have a PIN on your ATM card, even if you don’t want one… that’s bad? Seatbelt laws are bad?

[astrobe_]

I don't know about executable signing, but in the embedded world SecureBoot is also used to serve the customer; id est provide guarantees to the customer that the firmware of the device they receive has not been tampered with at some point in the supply chain.

[tosti]

Computers should abide by their owners. Any computer not doing that is broken.

[ghighi7878]

Its a simple solution in law to enable. Force manufacturers to allow owners of computer to put any signing key in the BIOS.

We need this law. Once we have this law, consumers csn get maximum benefit of secure boot withiut losing contorl

[miki123211]

But that's how it already works.

If you install Windows first, Microsoft takes control (but it graciously allows Linux distros to use their key). If you install Linux first, you take control.

It's perfectly possible for you to maintain your own fully-secure trust chain, including a TPM setup which E.G. lets you keep a 4-digit pin while keeping your system secure against brute force attacks. You can't do that with the 1990s "encryption is all you need" style of system security.

[ray_v]

It's funny, but I just encountered this for the first time the other day - feels like I had to do a lot of digging to find out how to do this so that I could add my LUKS key to my TPM... really felt like it took some doing on the HP all-in-one that I was trying to put debian on... maybe because it was debian being debian

[ghighi7878]

Not really. There are many laptops where you cannot rrally get rid of Microsoft key and also cannot put your own key.

[201984]

Most embedded processors sadly don't have a BIOS, and the signing key is permanently burned into the processor via eFUSEs.

[astrobe_]

Yes, BIOS is really a PC-thing, AFAIK. Embedded processors have "bootloaders" which often serve a similar purpose of performing the minimal viable hardware initializations in order to load the OS kernel.

[PunchyHamster]

> Its a simple solution in law to enable. Force manufacturers to allow owners of computer to put any signing key in the BIOS.

...it's already allowed. The problem is that this isn't the default, but opt in that you need quite a lot of knowledge to set up

[ghighi7878]

I have set it up on worst laptops. There are laptops like hp x360 which doesn't allow modification at all.

[cferry]

I make the analogy with a company, because on that front, ownership seems to matter a lot in the Western world. It's like it had to have unfaithful management appointed by another company they're a customer of, as a condition to use their products. Worse, said provider is also a provider for every other business, and their products are not interoperable. How long before courts jump in to prevent this and give back control to the business owner?

[wat10000]

This gets tricky. If I click on a link intending to view a picture of a cat, but instead it installs ransomware, is that abiding by its owner or not? It did what I told it to do, but not at all what I wanted.

[ghighi7878]

We dont need to get philosophical here. You(the admin) can require you (the user) to input a password to signify to you(the admin) to install a ransomware when a link is clicked. That way no control is lost.

[wat10000]

What if the cat pictures are an app too? The computer can't require a password specifically for ransomware, just for software in general. The UI flow for cat pictures apps and ransomware will be identical.

[Zak]

A computer that can run arbitrary programs can necessarily run malicious ones. Useful operations are often dangerous, and a completely safe computer isn't very useful.

Some sandboxing and a little friction to reduce mistakes is usually wise, but a general-purpose computer that can't be broken through sufficiently determined misuse by its owner is broken as designed.

[tosti]

If you connect your computer to the Internet, it can get hacked. If you leave it logged in unattended or don't use authentication, someone else can use it without your permission.

This isn't rocket science and it has nothing to do with artificially locking down a computer to serve the vendor instead of the owner.

Edit: I'd like to add that no amount of extra warranty from the vendors are going to cover the risk of a malware infection.

[account42]

The ransomware can encrypt the files in your home directory just as well with secure boot enabled.

This is just another example of how secure boot provides zero additional security for the threat modes normal users face.

[tosti]

https://xkcd.com/1200/

[201984]

And what if that customer wants to run their own firmware, ie after the manufacturer goes out of business? "Security" in this case conveniently prevente that.

[astrobe_]

Well, that's a different market. What I say is that there are markets in which customers wants to be sure that the firmware is from "us".

And those markets are certainly not IoT gizmos, which I suspect induce some knee-jerk reactions and I understand that cause I'm a consumer too.

But big/serious customers actually look at the wealthiness of the company they buy from, and would certainly consider running their own firmware on someone else's product; they buy off-the-shelf products because it's not their domain of expertise (software development and/or whatever the device does), most of the times.

[hhh]

you click the box to turn off secure boot

[201984]

And how do you do that on some locked down embedded device? Say, a thermostat for instance.

[bakugo]

...and then some essential software you need to run detects that and refuses to run. See where the problem is here?

[bigfatkitten]

It does no such thing if you enrol your own keys using the extremely well documented process to do that.

[greycol]

It's fair to think of secure boot in only the PC context but the model very much extends to phones. It seems ridiculous to me that to use a coupon for a big mac I have to compromise on what features my phone can run (either by turning on secure boot and limiting myself to stock os or limiting myself to the features and pricing of the 1 or 2 phones that allow re-locking).

[201984]

Where is this "extremely well documented process" to enroll new signing keys on an embedded device? I don't see one for any of these embedded processors with secure boot.

https://pip-assets.raspberrypi.com/categories/1214-rp2350/do...

https://documentation.espressif.com/esp32_technical_referenc...

https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm

[gjsman-1000]

Tradeoffs. Which is more likely here?

1. A customer wants to run their own firmware, or

2. Someone malicious close to the customer, an angry ex, tampers with their device, and uses the lack of Secure Boot to modify the OS to hide all trace of a tracker's existence, or

3. A malicious piece of firmware uses the lack of Secure Boot to modify the boot partition to ensure the malware loads before the OS, thereby permanently disabling all ability for the system to repair itself from within itself

Apple uses #2 and #3 in their own arguments. If your Mac gets hacked, that's bad. If your iPhone gets hacked, that's your life, and your precise location, at all times.

[samlinnfer]

1. P(someone wants to run their own firmware)

2. P(someone wants to run their own firmware) * P(this person is malicious) * P(this person implants this firmware on someone else’s computer)

3. The firmware doesn’t install itself

Yeah I think 2 and 3 is vastly less likely and strictly lower than 1.

[mikestew]

As an embedded programmer in my former life, the number of customers that had the capability of running their own firmware, let alone the number that actually would, rapidly approaches zero. Like it or not, what customers bought was an appliance, not a general purpose computer.

(Even if, in some cases, it as just a custom-built SBC running BusyBox, customers still aren't going to go digging through a custom network stack).

[account42]

The customers don't have to install the firmware themselves, they can have a friend do it or pay a repair shop. You know, just like they can with non-computerized tools that they don't fully understand.

[itsdesmond]

This guy thinks that if you rephrase an argument but put some symbols around it you’ve refuted it statistically.

P(robably not)

[samlinnfer]

The argument is that P(customer wants to run their own firmware) cancels out and 2,3 are just the raw probability of you on the receiving end of an evil maid attack. If you think this is a high probability, a locked bootloader won’t save you.

[philistine]

As if the monetary gain of 2 and 3 never entered the picture. Malicious actors want 2 and 3 to make money off you! No one can make reasonable amounts of money off 1.

[the__alchemist]

I encourage you to re-evaluate this. How many devices do you (or have you) own which have have a microcontroller? (This includes all your appliances, your clocks, and many things you own which use electricity.) How many of these have you reflashed with custom firmware?

Imagine any of your friends, family, or colleagues. (Including some non-programmers/hackers/embedded-engineers) What would their answers be?

[account42]

I would reflash almost all my appliances if I could do so easily since they all come with non-optimal behavior for me.

[gjsman-1000]

On Android, according to the Coalition Against Stalkerware, there are over 1 million victims of deliberately placed spyware on an unlocked device by a malicious user close to the victim every year.

#2 is WAY more likely than #1. And that's on Android which still has some protections even with a sideloaded APK (deeply nested, but still detectable if you look at the right settings panels).

As for #3; the point is that it's a virus. You start with a webkit bug, you get into kernel from there (sometimes happens); but this time, instead of a software update fixing it, your device is owned forever. Literally cannot be trusted again without a full DFU wipe.

[samlinnfer]

And where are the stats for people running their own firmware and are not running stalkerware for comparison? You don’t need firmware access to install malware on Android, so how many of stalkerware victims actually would have been saved by a locked bootloader?

[account42]

> And that's on Android which still has some protections even with a sideloaded APK (deeply nested, but still detectable if you look at the right settings panels).

Exactly, secure boot advocates once again completely miss that it doesn't protect against any real threat models.

[lazide]

Clearly you’ve never met my ex’s (or a past employer). Not even being sarcastic this time.

[wombatpm]

You expect that stuff to happy with 3 letter agencies.

[account42]

> 2. Someone malicious close to the customer, an angry ex, tampers with their device, and uses the lack of Secure Boot to modify the OS to hide all trace of a tracker's existence, or

Lol security people are out of their mind if they think that's actually a relevant concern.

> 3. A malicious piece of firmware uses the lack of Secure Boot to modify the boot partition to ensure the malware loads before the OS, thereby permanently disabling all ability for the system to repair itself from within itself

Oh no so now the malware can only permanently encrypt all the users files and permanently leak their secrets. But hey at least the user can repair the operating system instead of having to reinstall it. And in practice they can't even be sure about that because computers are simply too complex.

[dns_snek]

#2 and #3 are fearmongering arguments and total horseshit, excuse the strong language.

Should either of those things happen the bootloader puts up a big bright flashing yellow warning screen saying "Someone hacked your device!"

I use a Pixel device and run GrapheneOS, the bootloader always pauses for ~5 seconds to warn me that the OS is not official.

[root_axis]

Yes. They're making the point that your flashing yellow warning is a good thing, and that it's helpful to the customer that a mechanism is in place to prevent it from being disabled by an attacker.

[dns_snek]

No, they've presented a nonsense argument which Apple uses to ban all unofficial software and firmware as if it had some merit.

[jmye]

Then that customer shouldn't buy a device that doesn't allow for their use case. Exercise some personal agency. Sheesh.

[bakugo]

What happens when there are no more devices that allow for that use case? This is already pretty much the case for phones, it's only a matter of time until Microsoft catches up.

[fsflover]

There are still phones not obeying the megacorps. Sent from my Librem 5.

[bakugo]

Does your Librem 5 run banking apps, though?

[burstmode]

I don't know about executable signing, but in the embedded world SecureBoot is also used to serve the PRODUCER; id est provide guarantees to the PRODUCER that the firmware of the device they SELL has not been tampered with at some point in the PROFIT chain.

[rurban]

In my case a firmware provider went out of business, and in one particular device the firmware gets stuck in an endless boot loop. It tries to calibrate some led's, but forgets to round some differences, so it can never converge to a proper calibration.

Device is bricked, firmware is secured with a signing key, refactoring a new device is pretty hard. The current one needed 10 years of development. I'm on the wait to either patch the firmware by finding the problematic byte (if it's patchable, round() needs much more), or to wait for the original dev willing to release an update on his own. BTW Claude opus got much better than ghidra lately. It's perfect.

I see the value of protected firmware updates, but business has to survive also.

[astrobe_]

Frankly: that's stupid. In case you didn't figure it out, I work in the field and I can tell you that this is was not the mindset at the places where I worked.

[Galanwe]

> id est provide guarantees to the customer that the firmware of the device they receive has not been tampered with

The firmware of the device being a binary blob for the most part... Not like I trust it to begin with.

Whereas my open source Linux distribution requires me to disables SecureBoot.

What a world.

[WhyNotHugo]

You can set up custom SecureBoot keys on your firmware and configure Linux to boot using it.

There's also plenty of folks combining this with TPM and boot measurements.

The ugly part of SecureBoot is that all hardware comes with MS's keys, and lots of software assume that you'll want MS in charge of your hardware security, but SecureBoot _can_ be used to serve the user.

Obviously there's hardware that's the exception to this, and I totally share your dislike of it.

[Galanwe]

> You can set up custom SecureBoot keys on your firmware and configure Linux to boot using it.

Right, but as engineers, we should resist the temptation to equate _possible_ with _practical_.

The mere fact that even the most business oriented Linux distributions have issues playing along SecureBoot is worrying. Essentially, SB has become a Windows only technology.

The promise of what SB could be useful for is even muddier. I would argue that the chances of being victim of firmware tampering are pretty thin compared to other attack vectors, yet somehow we end up all having SB and its most significant achievement is training people that disabling it is totally fine.

[repelsteeltje]

+1

An unsigned hash is plenty guard to against tampering. The supply chain and any secret sauce that went into that firmware is just trust. Trust that the blob is well intentioned, trust that you downloaded from the right URL, checked the right SHA, trust that the organization running the URL is sanctioned to do so by Microsoft...

Once all of that trust for every piece of software is concentrated in one organization, Microsoft, Apple or Google, is has become totally meaningless.

[mort96]

It's to serve the regulators. The Radio Equipment Directive essentially requires the use of secure boot fir new devices.

[petcat]

I happen to like knowing that my mobile device did not have a ring 0 backdoor installed before it left the factory in Asia. SecureBoot gives me that confidence.

[mort96]

No it doesn't? The factory programs in the secure boot public keys

[petcat]

The public keys are provided by the developer. Google, or Apple, for example. It's how they know that nothing was tampered with before it left the factory.

[realusername]

Nothing has been tampered with doesn't mean there's no factory backdoor, it just only means same as factory, nothing more.

[mort96]

This is true for phones but not for IoT in general.

[PunchyHamster]

well, unless govt tells MS to tamper it

[pjmlp]

If only people didn't install Ask Jeeves toolbars all over the place and then asked their grandson during vacations to clean their computer.

[prerok]

Geez, this brings back memories.

At one time at our university we had table desktop dancers installed everywhere. Was kind of funny when it turned up just as a student wanted to defend their work in a lab.

[account42]

Hey I made some good money from that as a kid. And some of the malware that people ended up with was also fairly visually pleasing to a teenager.

[gusfoo]

> I still hope that one of these days people in general will realize that executable signing and SecureBoot are specifically designed for controlling what a normal person can run, rather than for anything resembling real security

For home/business users I'd agree. But in Embedded / money-handling then it's a life-saver and a really important technology.

[account42]

If by "really important technology" you mean it lets companies save a bit on fraud-related expenses then sure. But the world worked just fine with much simpler solutions because secure boot or not we have plenty of ways to discourage most people from committing crimes.

[TitaRusell]

Videogames are increasingly demanding secure boot.

[pezezin]

A few competitive online games do, but most don't. That's why nowadays so many games run great on Linux.

[gloosx]

Executable signing is also designed to make easy money from selling certificates

[asveikau]

Apple is also somewhat responsible for the attitude shift with the introduction of iOS. 20-25 years ago a locked down bootloader and only permitting signed code would have been seen by techies as dystopian. It's now quite normalized. They say it's about security but it's always been about control.

Stallman tried to warn us with "tivoization".

[duped]

This is like saying you shouldn't vaccinate your kids because no one gets polio anymore

[account42]

We we don't just pump our kids with any vaccine ever developed "just in case" either. Instead we weight actual risk against possible side effects - a concept most security people seem to be unable to grasp.