uugh.. who thought it was good idea to propagate the whole non-NUL terminated, space padded to fixed length strings

this isn't the 80s

(KCF)

I wonder if AMD chips will get some update soo too: cachewarpattack.com

there is a microcode patch for AMD, but it only matters if your host is running a hypervisor that uses SEV

far smaller set of affected systems than intel's bug

oh it would have been nice had the kcf ARC materials had made it out the door...

for some reason, the system attaches, detaches, then attaches again this driver.. which shouldn't be a problem

except desipte crypto_register_provider()/crypto_unregister_provider() being called successfully during attach/detach

KCF ends up with two entries for the driver

(and both are in the 'ready' state.... it does appear it'll leave old ones around for a bit marked as free)

or rather it's supposed to do that

i suspect i have an upcoming date with kmdb in my future :)

once more bug from intel

CVE-2023-23583

Already fixed illumos.org/issues/16058

→ BUG 16058: Update Intel microcode to 20231114 (Closed) | code.illumos.org/c/illumos-gate/+/3135

denk: see illumos#16057

Thanks ptribble for the link (my bad for slow typing).

@jbk --> kcf is beholden more than a little to the PKCS#11 standard for userland back-end.

thanks, I read old news :)

yeah, that's my guess why they decided to act like it's the 80s and they're running DOS with their non-NUL, space padded strings :P

though that's just a wtf

i've got a mostly working tpm2.0 driver, and i was going to include rng support for kcf (because we have a rather dearth of entropy sources currently)

and the attach / detach / attach sequence is causing a panic when you query provider info

because the crypto unregister doesn't appear to actually be unregistering

sommerfeld: hah, clever name (Runaway Reptar)

I imagine they can't come up with a cute logo for it given that it'd violate Nickelodeon's copyrights

[illumos-gate] 16049 Update AMD microcode to 20231019 -- Andy Fiddaman <illumos⊙fn>

hrm... we cap vioif's tx/rx buffer amount at 256... that does seem a bit on the low side if you're wanting to push a decent amount of data

probably should at least make that a dladm private property

am I thinking of the wrong thing, or is that one of the differences in virtio interfaces?

i'm not sure..

i mean for comparison, a real single HW ring usually has something like 4-10x the amount

depending on whatever defaults the driver writer picked

I was thinking of the virtio queue, not this

(it'd be nice to add multi-queue support if the HV supports it as well)

jbk: I think the big difference is also the 64 KiB data size that gets allocated.