zlacker

Business idea: eprom based firmware

>>iberat+(OP)
And put the EPROM in a socket, like it's 1987?

Some motherboards just have a physical jumper that prevents BIOS flashing. This happens infrequently enough as to warrant it for one server, or 10 servers, or maybe 100 servers. Likely unpractical for 1000 servers though.

>>iberat+(OP)
crazy

>>nine_k+s2
If they can put the jumper on the exterior it might be feasible, if its inside its out of the question if you have to unrack the chassis to change. Rolling in a server lift for an 8u thats half full of copper is not a nice process

>>nine_k+s2
Baseboard management is switching to easily swapped modules for exactly this reason: https://antmicro.com/platforms/dc-scm-open-source-bmc-platfo...

https://www.servethehome.com/the-ocp-dc-scm-hff-is-taking-ov...

>>boreda+k4
The next idea, a second oob management for the first oob managemen. A BMC for the BMC. It only does updates and maybe credential management.

Make this one simple enough and add an EPROM for it. Effectively a security chip for the oob. Extra points for secure enclave-like verified boot.

>>iberat+(OP)
Pulling a physical chip to upgrade the firmware would generate so many returns or RMAs that it would be dropped as a feature immediately.

These days it’s common to do firmware updates to address small issues or even support the new CPU that was launched after the motherboard was manufactured.

I could see manufacturers adding a write-protect physical switch for those who want it. Make it opt-in and toggleable.

>>nine_k+s2
I installed my own physical jumpers on my paytv receivers in the late 90s/early 2000s…

>>c0balt+Ia
The security chip for the BMC is called root of trust.

>>c0balt+Ia
OpenCompute (OCP) Caliptra is an effort by hyperscalers, AMD and others to enforce a platform root of trust with OSS firmware and open silicon, mandating dual signature by server OEM and hyperscaler customer. The platform RoT is responsible for validating device firmware and OS boot, https://www.youtube.com/watch?v=p9PlCm4tLb8&t=2764s

> Often we see.. great security.. compromised by other great ideas for mgmt and other things.. starts to weaken its security posture.. want to keep Caliptra very clean [via OSS firmware transparency]

>>iberat+(OP)
Or two physical firmware chips: one writable, one with no write ability and is a fallback. Then a physical switch, could even be a jumper, to select the fallback. If compromised you flip the switch, boot from the clean firmware, flash the writable chip, flip switch and reboot. I am pretty sure Gigabyte offered this same setup with Dual Bios or something like that.

>>Aurorn+Bc
AMD have recently changed the firmware loading signature verification method to apply cpu microcode that uses the on-motherboard tooling.

Using the method you talk about would mean that this kind of update wouldnt be possible, 99% of users would never toggle with a switch to update firmware.

This would be a huge burden in the server world too, to unrack flip switch, update, revert switch re-install.

I assume you mean specifically motherboard firmware updates, because firmware updates are actually pretty common, for most server grade motherboards vendors ship updates about every other month[1].

1. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

>>Mister+Im
Gigabyte made a lot of marketing hay about it, but I think it was popular for a while. I think their version was some sort of watchdog/failover model where it would automatically load the backup BIOS, but some other firms had a secondary-BIOS jumper.

I think these days, the stub "BIOS flashback" is the trendy thing, where you can plug a flash drive into a magic slot and press a button to flash without even having a CPU installed.

This offered the same "brick-resistance" feature with the added benefit that people weren't stuck if they tried to pair an old-stock mainboard with a new CPU that wasn't supported by the original firmware release.

TBH, I'd rather they go the complete opposite direction: replace the soldered EPROM with a SD slot and a $1 MCU that reads the card and emulates a ROM chip. That could be configurable to write-protect the card, or you could just trivially swap it if you didn't trust the firmware image for any reason, while avoiding the fumbliness of modern tiny 8-pin flash chips. You could socket a big old-fashioned DIP ROM, but will people feel comfortable even trying to pry that out of a $10,000 server even with the appropriate chip puller tool?