I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS.
I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
lmm · 9m ago
Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.
JCattheATM · 1h ago
> I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS.
Apart from way nicer boot menus and bootloader setup?
In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression.
> Out there, there is software, which I have to figure out how I'm going to trust,
Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
necovek · 57m ago
It's mostly about your UEFI firmware coming with a set of trusted CAs to verify bootloader is built by one of the trusted parties like Microsoft or Canonical or Redhat or...
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
FirmwareBurner · 30m ago
>I own a piece of hardware, so I can do what I want to it.
It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other bad actors.
baxtr · 8h ago
> Because the attacker’s code executes before the operating system even loads, it opens the door for attackers to install bootkits and undermine OS-level security defenses.
Excellent.
db48x · 9h ago
> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables.
Sheer incompetence, in other words.
OjotCewIo · 8h ago
UEFI variables or not: who in their right mind serializes raw pointer values to any kind of storage (network, disk, nvram, ...)?
Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
db48x · 7h ago
It’s something about hardware companies writing software. The motherboard itself may be excellent, but the BIOS/UEFI/ACPI tables will be horrible.
Meanwhile you look at a company like Oxide that is a software company at heart, and their equivalents are so much better. Like someone actually designed it so that when humans write the software it will still be secure.
neilv · 6h ago
> It’s something about hardware companies writing software.
I've seen enough examples of that, to suspect there's some truth to it, and wonder why that is...
Speculation:
* Systems programming is hard, and systems programmers who are familiar enough with the kind of target hardware are even more rare. A company might decide to hire a hardware engineer who can code, rather than a systems programmer software engineer who knows enough hardware.
* Hardware companies know hardware, and might have hardware engineers as execs and managers, so they probably know how to hire hardware engineers, but maybe not software engineers.
* Hardware companies respect hardware engineers, and not so much software people. You don't need all those hard math and engineering classes to be a "coder". Even their 12yo can make an app, but you usually need a team with a ton of hardware education and experience to produce a viable board or IC. ("Coding" even sounds like a tedious but straightforward clerical task.)
Other speculation, or does anyone know?
privatelypublic · 2h ago
Knowing several deep hardware people: they're incredibly dismissive of vulnerabilities. Direct quote (as best I can remember) "Some PhD student can figure out theoretical power attacks. They're not relevant to actual products"
Same person thinks I'm literally paranoid for splitting home, IoT, and Security cameras into separate networks... despite the cameras and dvr being the banned/recalled costco ones.
db48x · 5h ago
All of that sounds very plausible to me.
bradfa · 6h ago
I have a ton of respect for what Oxide did by not using an off the shelf firmware for their Epyc chips. But unless you’re them, AMD is going to send any small customer to Insyde to buy their UEFI and AMD is not going to give you the kind of access and info that normal engineering teams would expect to get in order to implement their own firmware for Zen based Epyc chips.
Most small customers have no choice but to buy a preexisting firmware from an IBV and you get all their security bugs included. You’re lucky if you get full source code and it actually compiles. This is the state of our industry today.
wmf · 4h ago
I think you could get AGESA and combine it with EDK2 yourself; it's just person-years of work.
eviks · 2h ago
The economics is there is little cost to having vulns, so you don't incur the extra cost to hire/push devs to code securely?
scraptor · 6h ago
When's the last time you made a motherboard purchase decision on the basis of firmware quality? Or rather, when's the last time a corporate purchasing manager got fired for buying motherboards with low quality firmware?
db48x · 5h ago
At the Internet Archive we occasionally had to return big batches of hard drives because of firmware bugs. That had to have ruined someone’s day, but apparently not enough to actually level up their engineering so that it wouldn’t happen again.
coderatlarge · 5h ago
> When's the last time you made a motherboard purchase decision on the basis of firmware quality?
i would argue every apple macbook purchase implicitly includes this.
gmueckl · 8h ago
Security is competing with all other requirements that a product has. That's all there is to it.
EPWN3D · 8h ago
They're not. They're ravaged by probably the same quality or slightly higher than average. The cost of mistakes is just way higher.
getcrunk · 5h ago
Yea but when things like this keep happening … it becomes a pattern. A very convenient one at that.
candiddevmike · 8h ago
This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.
ahepp · 7h ago
I'm not sure I understand why secure boot is user-infantilizing? I think there are some legitimate concerns about where attestation could be headed, but I like the ability to force my machine to only run signed executables.
It seems like the immediate problem here is that most people will never enroll their own keys, and if every vendor's crappy EFI binary gets signed by Microsoft, there will be a huge library of garbage vendor code which is all an attack surface.
AnthonyMouse · 6h ago
The problem here is that the signature doesn't do anything for you.
Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've configured, and so on.
That doesn't require any certificates and you get 100% of the benefits. The firmware needs to verify the boot loader and the boot loader the OS etc. The OS doesn't need to verify the firmware because it can't because if the firmware or boot loader was compromised then the code in the OS to validate it would be just as compromised.
The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
And then you also don't get this "garbage code is nonetheless trusted" problem because there is no global root of trust and you never told your firmware to trust this random firmware update utility for somebody else's hardware.
gruez · 6h ago
>Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've configured, and so on.
What if you need to update the bootloader?
>The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. It'd be clumsy, but doable, just like your idea of using hashes for verification.
AnthonyMouse · 1h ago
> What if you need to update the bootloader?
Then you boot the system from the existing bootloader, causing the booted system to be trusted to supply a new hash.
> TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader.
If there are no private keys in the TPM from the factory then there is nothing for a third party to force you to sign the hash with, as intended.
mschuster91 · 6h ago
> The problem here is that the signature doesn't do anything for you.
For your own personal machine, sure. But say you're a sysadmin in a company that has thousands of units. Suddenly, a CA infrastructure is much more appealing than having to deal with component hashes.
AnthonyMouse · 1h ago
How is it any different? You install the hash of the boot loader when you issue the machine, then use the trusted system to update the hash if necessary.
Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys also wouldn't be trusting random third party code either.
jeffrallen · 16m ago
A fish, a gun, and a smoking barrel. Sigh.
fsflover · 8h ago
Fortunately there's a FLOSS alternative: TPM with Heads, https://osresearch.net/. Works for me.
getcrunk · 5h ago
What hardware do you use the most recent supported seems like the Librem offerings. Which are intel 10th gen. Otherwise it’s gets pretty ancient
1oooqooq · 7h ago
why not secure boot with your own keys?
... granted, effectively removing Microsoft keys is a pain on some consumer devices, but still easier than this
dietr1ch · 5h ago
My first encounter with UEFI turned out to be quite expensive because UEFI was way too new and easy to brick. I guess things are better now, but toying around with this might still be a risk not worth taking as a consumer.
hulitu · 53m ago
> I guess things are better now,
A bit. But compared to BIOS is still crap.
The main advantage of UEFI over BIOS is that it offers RCE. /s
jerhewet · 8h ago
Please ... just give me back my BIOS.
gruez · 7h ago
BIOS isn't magically secure either. It has no secureboot so it just runs whatever.
lmm · 8m ago
In theory, sure. In practice I'd bet UEFI-based systems are easier to compromise, because the attack surface is just so much larger.
Lammy · 4h ago
I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.
gruez · 3h ago
You're conflating UEFI with secureboot. Moreover all the secureboot implementations I've seen allow you to either disable it or enroll your own keys.
Lammy · 1h ago
> all the secureboot implementations I've seen allow you to either disable it or enroll your own keys
Here you go — now you have. Thank ${DEITY} for exploits!
I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
Apart from way nicer boot menus and bootloader setup?
In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression.
> Out there, there is software, which I have to figure out how I'm going to trust,
Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other bad actors.
Excellent.
Sheer incompetence, in other words.
Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
Meanwhile you look at a company like Oxide that is a software company at heart, and their equivalents are so much better. Like someone actually designed it so that when humans write the software it will still be secure.
I've seen enough examples of that, to suspect there's some truth to it, and wonder why that is...
Speculation:
* Systems programming is hard, and systems programmers who are familiar enough with the kind of target hardware are even more rare. A company might decide to hire a hardware engineer who can code, rather than a systems programmer software engineer who knows enough hardware.
* Hardware companies know hardware, and might have hardware engineers as execs and managers, so they probably know how to hire hardware engineers, but maybe not software engineers.
* Hardware companies respect hardware engineers, and not so much software people. You don't need all those hard math and engineering classes to be a "coder". Even their 12yo can make an app, but you usually need a team with a ton of hardware education and experience to produce a viable board or IC. ("Coding" even sounds like a tedious but straightforward clerical task.)
Other speculation, or does anyone know?
Same person thinks I'm literally paranoid for splitting home, IoT, and Security cameras into separate networks... despite the cameras and dvr being the banned/recalled costco ones.
Most small customers have no choice but to buy a preexisting firmware from an IBV and you get all their security bugs included. You’re lucky if you get full source code and it actually compiles. This is the state of our industry today.
i would argue every apple macbook purchase implicitly includes this.
It seems like the immediate problem here is that most people will never enroll their own keys, and if every vendor's crappy EFI binary gets signed by Microsoft, there will be a huge library of garbage vendor code which is all an attack surface.
Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've configured, and so on.
That doesn't require any certificates and you get 100% of the benefits. The firmware needs to verify the boot loader and the boot loader the OS etc. The OS doesn't need to verify the firmware because it can't because if the firmware or boot loader was compromised then the code in the OS to validate it would be just as compromised.
The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
And then you also don't get this "garbage code is nonetheless trusted" problem because there is no global root of trust and you never told your firmware to trust this random firmware update utility for somebody else's hardware.
What if you need to update the bootloader?
>The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. It'd be clumsy, but doable, just like your idea of using hashes for verification.
Then you boot the system from the existing bootloader, causing the booted system to be trusted to supply a new hash.
> TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader.
If there are no private keys in the TPM from the factory then there is nothing for a third party to force you to sign the hash with, as intended.
For your own personal machine, sure. But say you're a sysadmin in a company that has thousands of units. Suddenly, a CA infrastructure is much more appealing than having to deal with component hashes.
Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys also wouldn't be trusting random third party code either.
... granted, effectively removing Microsoft keys is a pain on some consumer devices, but still easier than this
A bit. But compared to BIOS is still crap. The main advantage of UEFI over BIOS is that it offers RCE. /s
Here you go — now you have. Thank ${DEITY} for exploits!
https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot
https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...