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.
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.
> 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.)
It's not a point of competition, plain and simple.
Better software doesn't sell more hardware. From those companies' point of view, what matters is hardware features to make consumers want the product, and manufacturing efficiency to make margins high. The quality of what's in the ROM is no more important than the quality of the fans, servos, DACs or what have you. As long as the parts don't break too often and are within specifications, they're good enough, no point in wasting money to make them better.
This, of course, is true until it isn't. At some point, somebody comes along who disrupts the space completely by making the software great and well integrated (or just by making it do what people have previously had to do in hardware), and traditional companies don't know how to cope.
So it might be a mix of cost-engineering, and (consequently) not having the organizational capability to do software better on the occasions that would actually would be worthwhile?
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.
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.
Unfortunately it’s not quite that simple. Yes you can likely get AGESA but there is a whole bunch of other code you’d still have to write yourself and it’s not trivial without quite a few documents that AMD is unlikely to give you even with normal NDAs.
Now, Intel platforms you maybe have a shot at using EDK2 on, especially those with FSP. But Intel is unlikely to give you any support when something goes wrong and there’s probably no way to pay Intel to change that unless you’re a very big customer.
Yes, that's all (unfortunately) correct. Part of the reason that we have been supportive of the openSIL effort[0] is to make our approach more generally attainable -- and of course we have opened our own work[1] and we will continue to be outspoken advocates for transparency at the hardware/software interface[2].
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.
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.
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.
> 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 also wouldn't be trusting random third party code either.
> 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.
>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.
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.