>>zdw+(OP)
Is this related to controversial Bloomberg 2021 piece about China hacking Supermicro servers?

https://www.bloomberg.com/features/2021-supermicro/

>>nine_k+0Ya
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...

>>c0balt+g6b
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]

>>Tactic+3wb
Different. In 2018 there was articles [0] talking about hacked Supermicro servers being in the wild that had (simplifying) extra ICs in their motherboard, like some short of supply chain attack.

But AFAIK, tangible evidence never surfaced. [1]

--

  0: https://news.ycombinator.com/item?id=18176620
  1: https://news.ycombinator.com/item?id=19910537

>>Aurorn+98b
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...

>>vetrom+I7b
I've worked with automated EEPROM/Flash programmers (earlier versions of this line: https://www.bpmmicro.com/device-programmers/automated-progra...), and used pre-programming services from distributors, like Digi-Key, but that was the exception. It's almost exclusively faster, cheaper, and easier to load firmware from a test fixture. You need to test the assembly anyway, and it's much easier to update a test procedure, when a new firmware is developed, than to update and track inventory of pre-programmed devices, especially when different firmware versions are needed for different hardware variations.

Pogo pins are only really needed for mass production, especially for reducing repetitive stress injuries. For one-off updates, if a header isn't populated, it's easy to hold an unsoldered header in place, for long enough to flash an update.

>>Tactic+3wb
The story is called "The Big Hack" and was run by Bloomberg in 2018. All the major companies named in the story conducted investigations and never found anything, but the story was never retracted.

https://www.bloomberg.com/2018-the-big-hack

>>tinco+Xsc
Just a quick point of clarification that while our boot architecture is very important (e.g., a service processor in lieu of a BMC, the elimination of UEFI entirely, etc.), we are quite a bit different from Dell beyond that. There are certainly many hardware-level differentiators (e.g. DC busbar-based design, blindmated networking, built-in switch, etc.) but the big differentiator is really what these things allow: entirely integrated software. The Oxide rack comes with all of the software to run elastic infrastructure (that is, the distributed system that comprises the control plane), including switch software, storage software, etc. And then (critically!) the capacity to update all of this.[0]

All of it is a far cry from the offerings of Dell/HPE/Supermicro, which rely on others to provide the software that turns the hardware into real infrastructure.

[0] https://oxide.computer/blog/systems-software-in-the-large