[db48x]

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]

> 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?

[miki123211]

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.

[neilv]

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?

[privatelypublic]

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]

To be fair, many CVEs are just that

[worthless-trash]

Everyone says that till they get remote rootkitted in ane exploit chain that uses a moderate rated cve.

[privatelypublic]

More like: go see fusee gelee. Nvidia didn't do boundary checking on their usb DFU boot and it compromised every nintendo switch up to that date, and (i expect) got all nvidia shields' level 2 widevine keys revoked.

[worthless-trash]

For those who are are not asking and are lazy.

https://nvd.nist.gov/vuln/detail/cve-2018-6242

and

https://github.com/erdzan12/switch-fusee

[db48x]

All of that sounds very plausible to me.

[bradfa]

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]

I think you could get AGESA and combine it with EDK2 yourself; it's just person-years of work.

[bradfa]

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]

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

[1] https://github.com/oxidecomputer/illumos-gate

[2] https://rfd.shared.oxide.computer/rfd/0552