hmm, ran into this guy again on one of our machines over the weekend: illumos.org/issues/15024

→ BUG 15024: NFS can exhaust pool threads getting RPCSEC_GSS credentials (In Progress) | code.illumos.org/c/illumos-gate/+/2402

We insisted our users not use krb5 for now, but it does seem to be an issue. Usually we'd see it after a DC reboot but there's was nothing to indicate what provoked it this time

Does anyone have notes on how to perform the workaround for zenbleed on illumos?

sounds like it's an eventual microcode update

that looks nasty

You could pull the microcode from linux-firmware and apply it

Yes, I'd recommend just hot-loading the microcode. We'll get stuff written up and sent out before long.

I'll keep an eye out.

Quick instruction: download the fam17h file, put it on your system and rename it to anything starting with `amd`, then `ucodeadm -u <file>` to load it. `ucodeadm -v` will show the version on each CPU.

Thanks andyf!

andyf: what's the difference between model0xh.sbin and model3xh.sbin

The correct file is git.kernel.org/pub/scm/linux/kernel…/amd-ucode/microcode_amd_fam17h.bin (and there's a detached signature in the same .asc if you want to verify it against AMD's published keys)

papertigers - my first link was wrong, sorry.

thanks

OA

If I tried to load in the wrong file, would the system protect itself, or is this a pretty dangerous operation?

well at least the ^[[ didn't come through :)

rmustacc / andyf: do you know if I need to apply that on zen3? Seems like my 5600X is post zen2

papertigers: You do not.

This is noted as only impacting Zen 2.

thanks -- I will just apply it to my Rome box then

We'll get more info sent out and with our standard security impact, action required, etc. in a little bit.

nahamu - it should not accept an incorrect update. Note that this is not persistent though, it will need doing after every reboot if you load it manually.

andyf: cool. Thanks.

thanks ucodeadm reports I went from 0x8301072 -> 0x830107a if you are curious nahamu

ucodeadm shows me on 0xa20120a so now I'm confused.

nahamu: What does psrinfo -vp say about your CPU?

I guess I'm on Zen3

What specific CPU is it?

AMD Ryzen 7 5800X3D 8-Core Processor

That's Zen 3, not Zen 2.

You're not impacted.

Only Zen 2 is impacted.

Well now I feel really bad for wasting folks' time.

It's all good, don't worry.

The microcode revision is going to be processor model specific.

nahamu: you alerted me to zenbleed so it was worth while!

But I learned some things, so thanks everyone.

So for example, Zen 2 Rome parts (EPYC) is different from Zen 2 client parts.

papertigers: aha, good.

papertigers - that tracks with what I just put in illumos.org/issues/15811

→ BUG 15811: Update AMD microcode to 20230724 (In Progress)

Can we have some links for illumos 15811 please fenix?

BUG 15811: Update AMD microcode to 20230719 (In Progress)

↳ illumos.org/issues/15811 | code.illumos.org/c/illumos-gate/+/2970

andyf: does the non-hotload version of loading the microcode persist across reboots, or is this something where to remain safe you must stay on up-to-date versions of illumos (or Linux or whatever)? I just want to be certain before advising anyone else.

andyf: feel free to ignore me:

if you want to be sure you're safe, I believe the best is to get a BIOS/UEFI/motherboard-firmware update that includes the new microcode, so it's there before the OS boots and the OS doesn't have to worry about it/can't fail to update it

otherwise I believe OS-loaded microcode updates persist across fast reboots, but not power-cycles/full-resets/"slow" reboots

yup, thanks alanc

[illumos-gate] 15811 Update AMD microcode to 20230719 -- Andy Fiddaman <illumos⊙fn>

does fast reboot even work anymore? :)

as well as it ever did

it's increasingly unlikely that it'll happen for you, since xhci(4D) doesn't quiesce

you'll either have to forcibly disable all your usb3, or be on a computer old enough it probably got tested on it.