04:43:44 <nomad> rmustacc, I've updated the ticket with that. Hopefully I followed your directions correctly.
05:32:03 <gitomat> [illumos-gate] 15756 ipsecutils: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>
16:28:17 <nomad> rmustacc, was the data I provided correct?
17:40:57 <rmustacc> nomad: Data looks OK, but I haven't gone through and started looking at it relative to the spec.
17:43:29 <nomad> k
17:59:45 <jbk> has anyone seen qemu's ahci emulation trigger a panic on illumos?
18:33:19 <jbk> https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-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)
18:49:36 <sommerfeld> jbk: yes, that would make a lot of sense
18:52:29 <jbk> (just thinking out loud) i actually wonder if having say 'keymem_[z]alloc()/free' that did that (as well as did bzero on free)..
18:52:37 <jbk> might be useful
18:53:57 <jbk> 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
18:54:24 <jbk> and while MS sanitizes their dumps, apparently a bug meant it didn't always happen
19:08:12 <sommerfeld> something similar for userland core dumps would also be useful..
19:08:43 <sommerfeld> but then getting userland crypto libraries to use it would be a long battle
19:08:47 <jbk> yeah, though that seems like it could present more complications
19:09:09 <jbk> well more difficulty
19:09:53 <jbk> yeah.. i mean, we can make pkcs11_softtoken + libsoftcrypto use whatever mechanism
19:10:10 <jbk> but that still leaves most stuff that uses openssl
19:10:15 <jbk> which is just about everything
19:12:12 <jbk> (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)
19:12:19 <copec> How difficult is it to generate the key from the state contained in the crashdump?
19:12:41 <jbk> depends on what type of key and what type of dump
19:13:02 <jbk> though i suspect for say a zfs dataset key, it probably wouldn't be too difficult
19:17:02 <copec> Not intending to suggest from the peanut gallery that excluding the key wasn't a good idea, just got me thinking about it
19:25:52 <jbk> it's worth thinking about...
19:26:06 <jbk> and what the exposure is
19:26:21 <jbk> i suspect for the kernel, zfs dataset keys are the biggest concern
19:26:44 <jbk> the other big common kernel consumer of crypto that I can think of is smb
19:27:09 <jbk> but that's going to be mostly session keys (e.g. ephemeral)...
19:27:31 <jbk> (not to say we shouldn't protect them if we can, just in terms of risk/exposure potential)
19:33:38 <jbk> hmm.. no alex (he'd have some thoughts on this i'm sure)...
21:24:00 <gitomat> [illumos-gate] 15872 Allow nvme 2.x devices to attach -- Robert Mustacchi <rm⊙fo>