27 comments

[ 3.3 ms ] story [ 75.2 ms ] thread
Why is cloudflare blogging this? It doesn’t add any more information than the original article and seems tangentially related to their infra other than they are patching systems with the microcode update.
To reassure customers?
I figured the default assumption was these vendors kept updated with security patches.

Do we really need a blog post every-time they run apt/yum update?

That still doesn't stop people from asking about log4j way over a year after the entire fiasco went down...
When every tech news site puts the vulnerability in headlines, it's going to have a lot of visibility and many of Cloudflare's customers are going to ask them about it (regardless of whether the attention is warranted or not).
> I figured the default assumption was these vendors kept updated with security patches.

That's a damn big assume when you have compliance to worry about.

If you’re right, that’s still (comparatively) a lot of English to communicate very few bits of information. If I cared, I’d honestly be a bit miffed that they made me spend a minute on this shaggy-dog post/ad chimera instead of putting a single sentence in the announcements section of their front page or dashboard (which is a section that needs to exist if it doesn’t already). Like

  2023-07-25: Microcode patch for [Zenbleed](https://lock.cmpxchg8b.com/zenbleed.html) ([CVE-2023-20593](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593)) now rolling out across fleet, expected complete 2023-mm-dd, no evidence of exploitation so far.
Was that so hard? TFA doesn’t even give an estimated completion date, so that’s actually more info than the original! (If they don’t have one yet, that’s OK too of course.)

If the post actually did a better job than other sources of explaining the problem to at least some potential audience, I would’ve welcomed it, and in fact I’m probably crabby exactly because I’ve come to expect good and frank technical explanations from the Cloudflare blog (whatever I may think of their business). But this one is just meh, with a sprinkling of bleh from the forced cheer in the title.

(Sez I who has just spent 200 words’ worth of English just to complain.)

> Was that so hard?

Because your suggestion provides less value and near zero or actually probably negative information to the target audience.

Can you elaborate? I may certainly have missed a potential target audience, but I can’t really think of one that would be more confused / farther from the truth after reading my headlinese than before, which is what I assume you meant by negative information.
(comment deleted)
Cloudflare never, ever misses an opportunity to loudly advertise what they are doing.
Sure but they didn’t do anything here but apply a microcode patch…

Heck they are taking attention away from the original authors and what shining a spotlight at their hardware partner’s flaw?

Because this is an advert and they want to show people that they are aware & are doing something about it
Yeah, they do that. Just look at their pages when a website using them goes down. Cloudflare never misses an opportunity to advertise themselves.
As someone who has dealt with a lot of upper management, I can say that they love articles like this coming from one of their infrastructure providers. It gives them a feel-good feeling, and probably avoids unnecessary emails to their support staff on whether they've done anything to mitigate the risk.
On a smaller scale, these "I'm looking at it" emails are also good for internal problems (accidental downtime, discovered bug, etc) for the exact same reason.
The real genius was OpenBSD adding microcode updates they should have had for 10 years, and on top we get a smug Theo email about how it's really not even very much affected except when using AVX (duh).
Posting a big public note like this can also reduce the number of support cases asking “did you fix this?”
If we don’t our customers will ask us about this. Doing so means they have a page that reassures them that we’re dealing with it.
Staying ahead of the AMD vulnerability known as “Zenbleed” by applying the same microcode patch everybody else applied
(comment deleted)
So as far as I understand, if I have the latest AMD microcode on my system, at least on Linux, I don't really have to worry about this anymore?

As a sidenote, any word on Microsoft working on this?

If you're not running a Zen 2 CPU or APU, you don't have to worry about this.

If you're running the latest kernel, which automatically sets the chicken bit, you don't have to worry about this.

If you're running fixed microcode, which is only available for Rome, Castle Peak and Mendocino, you don't have to worry about this. Good microcode revisions are:

    Rome / Castle Peak: 0x0830107a (published)
    Xbox Series X: unknown
    Renoir / Grey Hawk: 0x0860010b
    Lucienne: 0x08608105
    Matisse: 0x08701032
    Van Gogh (Steam Deck): unknown
    Mendocino: 0x08a00008  (published) 


If you're running neither the latest kernel, nor fixed microcode, you should set the chicken bit yourself until you have updated those.

    wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
Microsoft is dead silent on zenbleed.

It's not easy to set chicken bit manually either.

In other words windows on AMD Zen2 is fcked.