4 ms·

It’s something about hardware companies writing software. The motherboard itself may be excellent, but the BIOS/UEFI/ACPI tables will be horrible. Meanwhile yo

• 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.