AMD Publishes New Family 19h CPU Microcode

[DRanged]

Yeah, but I don't see anything for that model in this or previous changes. Does it mean there was no firmware published for it yet? And model 1 suspiciously looks like a placeholder value.

On Debian it seems microcode is blacklisted in amd64-microcode-blacklist.conf. I actually don't know what it means so if someone can enlighten me it would be appreciated.

[shmerl]

On Debian it seems microcode is blacklisted in amd64-microcode-blacklist.conf. I actually don't know what it means so if someone can enlighten me it would be appreciated.

I think that's for avoiding dynamic loading of microcode at later stages. But if it's baked into initramfs, it should still be loaded when kernel loads. Which for me just doesn't happen somehow.

[colejohnson66]

And this is why I hate microcode. No idea what's being installed into my CPU or why if the manufacturer doesn't tell the complete truth, needing insider knowledge of the child's workings to understand that truth, and no way to find out barring massive amounts of reverse-engineering.

There's so much misinformation about microcode. Do you even know what microcode is capable of (in terms of vulnerabilities)? Nothing. People think microcode is capable of controlling the whole CPU, but that's not true; Microcode affects the instruction decoder and nothing else. There's only limited scratch RAM for microcode updates (on really old CPUs, it could be as few as 16 entries). A backdoor can't be introduced through these patch registers. The only thing microcode is capable of is saying, "hey, CPU, when you try to decode sequence 0F ..., output these uops instead of what's burned into the PLA/ROM." But those uops can't pwn your computer; they're too limited. They can only make the execution engine do something different with the registers. The microcode updates are kept secret because these companies, for whatever reason, seem to view the internal RISC architecture/uop formats as trade secrets.

Basically, if they're going to introduce a backdoor, microcode is the worst way to do it. A "platform firmware update" is a much easier target as that goes into a larger ROM.

[Anux]

A backdoor can't be introduced through these patch registers.

That doesn't sound logical, if no backdoors can be introduced through microcode updates how can a microcode update mitigate vulnerabilitys?

[qarium]

And this is why I hate microcode. No idea what's being installed into my CPU or why if the manufacturer doesn't tell the complete truth, needing insider knowledge of the child's workings to understand that truth, and no way to find out barring massive amounts of reverse-engineering.

right and it is a miracle why all the people think a closed source microcode is ok only because it does not run on the main cpu and is not fuzzling with the linux kernel...

[arQon]

which listed a lot of errata, most of which were "won't fix".

Errata are nearly *always* "won't fix". :/

Once you get past the first couple of months, about the only time you'll see microcode updates is for data corruption, and even that's only because of a mix of massive reputational damage, legal action, and the "fit for purpose" laws in civilized countries. Even catastrophic security vulnerabilities don't necessarily get workarounds, depending on how large the potential lawsuit is.

Basically, unless the manufacturer would be on the hook for a staggering amount of legal liability, it would rather rather just spend $50M of lawyer time tying the whole thing up in the courts instead. I've never understood why, since even $5M of engineer time - which basically NO amount of repair work would cost - is still by far the cheaper option, but I guess they're just playing the odds.

[colejohnson66]

That doesn't sound logical, if no backdoors can be introduced through microcode updates how can a microcode update mitigate vulnerabilitys?

Honestly, I don't know. It's possible that the microcode for TSX, SGX, etc. is/are just insanely complex. The Intel Atom microcode contains a few rather large sections. I can't find the talk on YouTube, but other research into MSRs revealed that some RDMSR instructions can take hundreds (thousands?) of cycles. That indicates a lot of work going on behind the scenes just to return a 32 bit number.

[Anux]

I can't find the talk on YouTube, but other research into MSRs revealed that some RDMSR instructions can take hundreds (thousands?) of cycles. That indicates a lot of work going on behind the scenes just to return a 32 bit number.

Exactly, you also don't need to implement a calling home function in the microcode, a simple flaw/vulnerability is enough and in conjunction with a hole in the network code you have your backdoor.