Debian to vote on its firmware path

No - I'm making a much more subtle argument than that, relating to the size of my trust base.

I have to trust AMD's designs, and AMD's manufacturing partner for silicon, when using AMD CPUs. That's just a fact of life as it is at the moment; if I used Intel CPUs, I'd just change the word AMD for Intel in that sentence, and it'd still hold true (albeit that Intel current manufacture their own chips). Same applies for any CPU vendor - I trust that vendor's designs, and I trust that their manufacturing will implement the design as created by the vendor, not a modified version to target me.

That is the core trust base I have when using any CPU - I can't avoid trusting the designer and the manufacturer of the silicon. Beyond that, my trust base can be extended by design decisions - for example, in a traditional cloud system (without AMD-SEV), I must also trust the motherboard manufacturer, the BIOS vendor, the DIMM manufacturer, the DRAM chip maker, the hypervisor vendor, the hypervisor operator, and the datacenter owner.

The promise of AMD-SEV is that I no longer need to trust as large a trust base, because AMD-SEV uses cryptography to remove all but AMD from the trust base. I still have to trust AMD and whoever made the CPU, but I no longer have to trust all the other parties involved, since they can only see encrypted data, and cannot get the key. The value of this promise is, however, weakened by the fact that we can't see into the memory controller startup blob - because it is entirely opaque, there is a reasonable possibility that AMD used the startup blob to disable AMD-SEV debug features that break the promises of AMD-SEV (and I would consider having these features that can be disabled in a one-way operation to be entirely reasonable on AMD's part - they need to be able to debug things if their chips misbehave in their labs). And because there is one combined blob that contains both AMD-supplied code and motherboard vendor code, the effect of this is to widen my trust base for AMD-SEV from "just AMD" to "AMD and the motherboard vendor".

There's at least two routes AMD could take to reduce the size of the trust base back down to that promised by AMD-SEV:

1. Split the blob. Have two blobs, one from AMD that does cache-as-RAM setup and anything needed to make AMD-SEV safe, and a second from the motherboard vendor that does the DRAM training. This would allow me to verify that the AMD blob is indeed from AMD, without needing to trust the motherboard vendor too.
2. Open up the AMD parts of the blob - fully describe the blob and its system accesses, so that I can validate that the blob from my motherboard vendor only touches the registers that are involved in DRAM training (and thus can be confident that I only need to trust AMD, since my motherboard vendor has done nothing that AMD say is suspicious).

Both work - you will notice that one of them doesn't even involve opening up the blob. But unless AMD do one of the two options, I have no way of telling whether or not the blob expands my trust domain to include the motherboard vendor, or whether it in fact limits me to just trusting AMD because the motherboard vendor modifications aren't able to affect AMD-SEV.