not a signal but I believe getppid() will change when the parent dies.

if you control both processes you can have the parent create a pipe, retain the write end, and pass the read end to the child; child will get an EOF when the parent goes away and closes the write end of the pipe.

Perhaps you can use a contract?

yeah, i was wondering about a contract...

i'm working on getting the tss2-libs building on illumos.. and there's multiple 'backend' libraries (they call them transports) .. more or less plugins, and one of them is where it spawns a command (presumably some sort of tpm emulator, though I guess it doesn't really matter) and talks over a pipe

from what I can gather, I think the intention is so that the child thing it spawns won't get orphaned if the calling parent dies

looks like it uses prctl on linux and procctl on fbsd

(I can also skip that backend for now)

this way i have a bit more to work with when testing out my driver vs. using artisinal hand crafted tpm2 byte streams

:)

jbk: If you want to ensure that the child doesn't get orphaned when it dies, then this is more straightforward.

This is what ctrun -o noorphan does.

So logically you can do the equivalent in the backend I guess?

oooh that'd work i bet

hello all, is there any plan to Introduce SM4 encryption algorithm for illumos/zfs ? gmssl.org/english.html

i don't think i've seen anyone talk about, so I don't think anyone has any plans to

but absent some other reason (licensing, etc) that'd prevent it (I'm not familiar with SM4, so not sure how relevant those would be), i don't think there'd be anything that'd stop someone from adding it if they wanted to

[illumos-gate] 15913 zfs: get_special_prop() should also check for ZFS_TYPE_SNAPSHOT -- Toomas Soome <tsoome⊙mc>

one more question, the openzfs 2.2 released recently, there are many improvement, such as draid/ fast dedup/ disk expantion/ (not sure z.i.a and direct io), I read the docs from openzfs.org says illumos(omnios and smartos) is distributions, so I’m confuse if omnios or smartos had already with the feature already in recent build? if not contain the feature, when it will be merged? best wishes

a big thanks for the answer

i think the answer is yes, but if I make a device driver fm-aware, there's no other restrictions on when I can generate ereports (nothing may be looking at them, but that's fine), right?

i think every instance i've ever seen of them is basically after checking DMA operations

so just want to be sure there's not some additional assumptions there i've not discovered

e.g. if a request to a device times out, it seems like it might be nicer to generate an ereport w/ more detailed information (the request, etc.) vs. just spitting something out to the messages file

I think the fma prm is somewhere, but I don't have a copy, it might help.

hrm.. i think i might have a copy of that somewhere... i'll dig around and see if I can find it and see if that helps

Aside from generating the need to eventually write that up so it's not unexpected telemetry, the CONTEXT page of ddi_fm_ereport_post() indicates that you can use it any time.

[illumos-gate] 16063 SMB server login fails in non-global zone after 15965 -- Gordon Ross <gwr⊙rc>

i think i've floated the idea in here before, but do you think adding a vmem arena for memory sensitive crypto data (e.g. keys) so it could be excluded by default in crash dumps (like zfs data is) is something that'd need an IPD?

or enough to just have a ticket on it?

probably depends on how complex the implementation is, I think probably just file an RFE?

if it gets complicated, write it up

there might be interesting questions about what guarantees we can make, I'm not sure

I think the other bit for consideration is understanding how much data is it, what throughput, what caches are needed, etc.

my thought was just to make it like kvmm_arena or zio_alloc_arena -- really just so it can be skipped during a crash dump (unless there's an easier way, but that seems to be the precedent)

I think the challenge / question is what is the policy around sizing this? Do you import more at run-time if it runs out?

i'm thinking mostly keys stored in the kernel

I think even if it's not for the contexts that operate on them, it's worth spelling out those policies.

Despite our druthers, memory is finite.

yeah, there might be more interesting future things that could be done, but my goal is just to get encryption keys out of crash dumps

at least the immediate goal

I get it. I'm not disagreeing with you. Just think the work needs to answer that.