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.
>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 potential bad actors.
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.
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.
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?
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.
Enterprise datacenter customers is a different kettle of fish than accounting making decisions on which fleet of laptops the rank and file get to use.
The former decision is made by engineers, the latter by bean counters.
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.
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.
It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.
> 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 w…
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.
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.
It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on…
It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on…
Which vendors?
As example, FaceIT Anti Cheat only works if Secure Boot is enabled. I guess their argument is that they can ensure you only boot genuine Windows and thus they can better check if you've tampered with anything.
> 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.
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…
> 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.
With your private CA you can skip the "update the hash" part, removing a crucial step that one might forget in a hurry or that simply might go wrong because of whatever sort of bug or power outage... and brick thousands of machines as a result.