rmustacc, I've updated the ticket with that. Hopefully I followed your directions correctly.

[illumos-gate] 15756 ipsecutils: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>

rmustacc, was the data I provided correct?

nomad: Data looks OK, but I haven't gone through and started looking at it relative to the spec.

k

has anyone seen qemu's ahci emulation trigger a panic on illumos?

msrc.microsoft.com/blog/2023/09/res…ions-for-storm-0558-key-acquisition <--- makes me wonder if it'd be worth making the sw kernel crypto provider allocate keys from an arena that's by default excluded from dumps (as best as I can tell, we don't do this today)

jbk: yes, that would make a lot of sense

(just thinking out loud) i actually wonder if having say 'keymem_[z]alloc()/free' that did that (as well as did bzero on free)..

might be useful

the tl;dr on that link is -- the big key breach MS had a few months ago appears to have been done by gaining access to someone's account that had permissions to read crash dumps

and while MS sanitizes their dumps, apparently a bug meant it didn't always happen

something similar for userland core dumps would also be useful..

but then getting userland crypto libraries to use it would be a long battle

yeah, though that seems like it could present more complications

well more difficulty

yeah.. i mean, we can make pkcs11_softtoken + libsoftcrypto use whatever mechanism

but that still leaves most stuff that uses openssl

which is just about everything

(though I have thought about something like softtokend w/ pkcs11_softtoken that could segregate your keys from the process (maybe even store them such that they're inaccessable except through the api as well)

How difficult is it to generate the key from the state contained in the crashdump?

depends on what type of key and what type of dump

though i suspect for say a zfs dataset key, it probably wouldn't be too difficult

Not intending to suggest from the peanut gallery that excluding the key wasn't a good idea, just got me thinking about it

it's worth thinking about...

and what the exposure is

i suspect for the kernel, zfs dataset keys are the biggest concern

the other big common kernel consumer of crypto that I can think of is smb

but that's going to be mostly session keys (e.g. ephemeral)...

(not to say we shouldn't protect them if we can, just in terms of risk/exposure potential)

hmm.. no alex (he'd have some thoughts on this i'm sure)...

[illumos-gate] 15872 Allow nvme 2.x devices to attach -- Robert Mustacchi <rm⊙fo>