5 ms·

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 securi

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.

gmueckl 1y ago
Security is competing with all other requirements that a product has. That's all there is to it.
EPWN3D 1y 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.
db48x 1y 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.
- bradfa 1y 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 1y ago
    I think you could get AGESA and combine it with EDK2 yourself; it's just person-years of work.
    - bradfa 1y ago
      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.
      - bcantrill 1y ago
        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]. [0] https://github.com/openSIL/openSIL https://github.com/openSIL/openSIL [1] https://github.com/oxidecomputer/illumos-gate https://github.com/oxidecomputer/illumos-gate [2] https://rfd.shared.oxide.computer/rfd/0552 https://rfd.shared.oxide.computer/rfd/0552
- neilv 1y 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?
  - db48x 1y ago
    All of that sounds very plausible to me.
  - privatelypublic 1y 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.
    - nikanj 1y ago
      To be fair, many CVEs are just that
      - worthless-trash 1y ago
        Everyone says that till they get remote rootkitted in ane exploit chain that uses a moderate rated cve.
scraptor 1y 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?
- coderatlarge 1y 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.
- db48x 1y 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.
  - FirmwareBurner 1y ago
    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.
eviks 1y 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?
quotemstr 1y ago
> Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? Lemon market: https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf Buyers can't distinguish good work from bad, so they pay only average price and thereby drive out the high-quality sellers.

gmueckl 1y ago

Security is competing with all other requirements that a product has. That's all there is to it.

EPWN3D 1y 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.

db48x 1y 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.

bradfa 1y 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 1y ago
  I think you could get AGESA and combine it with EDK2 yourself; it's just person-years of work.
  - bradfa 1y ago
    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.
    - bcantrill 1y ago
      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]. [0] https://github.com/openSIL/openSIL https://github.com/openSIL/openSIL [1] https://github.com/oxidecomputer/illumos-gate https://github.com/oxidecomputer/illumos-gate [2] https://rfd.shared.oxide.computer/rfd/0552 https://rfd.shared.oxide.computer/rfd/0552
neilv 1y 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?
- db48x 1y ago
  All of that sounds very plausible to me.
- privatelypublic 1y 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.
  - nikanj 1y ago
    To be fair, many CVEs are just that
    - worthless-trash 1y ago
      Everyone says that till they get remote rootkitted in ane exploit chain that uses a moderate rated cve.

scraptor 1y 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?

coderatlarge 1y 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.
db48x 1y 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.
- FirmwareBurner 1y ago
  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.

eviks 1y 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?

quotemstr 1y ago

> Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? Lemon market: https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf Buyers can't distinguish good work from bad, so they pay only average price and thereby drive out the high-quality sellers.