procdesc: add NOTE_PDSIGCHLD

[kib]

Summary

The note type wakes up when there is something for pdwait(2) to report on the process descriptor.

[markj]

sys/sys/event.h

206

Why repurpose NOTE_FORK? Isn't it possible someone might want to use a procdesc to wait for NOTE_FORK events?

[kib]

sys/sys/event.h

206

Should we ever allow it? NOTE_FORK is very close to limited tracing functionality, and you was explicitly against the ptrace attach over procdesc

I just acted under assumption that procdesc knote actions should not extend the functionality of existing syscalls, mainly pdwait().

If you prefer, I can reuse the free bit from PCTRLMASK but may be instead we should split the namespace between _PROC and _PROCDESC filters?

[markj]

sys/sys/event.h

206

you was explicitly against the ptrace attach over procdesc

Well, to be clear, I was against enabling ptrace() in capability mode, at least without some more design and discussion; PT_ATTACH_PD on its own is fine I suppose, but I do not really see the point unless you want to enable capmode ptrace(). Meanwhile, NOTE_FORK already exists, and supporting it from procdesc does not require much complexity (I think?), and procdescs already implement NOTE_EXIT. Plus, with procdescs you can avoid PID reuse races. For ptrace() I think such races are probably not a real concern (but correct me if I am wrong).

So, I think it makes some sense to leave NOTE_FORK available for procdescs.

BTW, does anything prevent a capmode process from using EVFILT_PROC? If not, then that is a bug.

[kib]

sys/sys/event.h

206

you was explicitly against the ptrace attach over procdesc

Well, to be clear, I was against enabling ptrace() in capability mode, at least without some more design and discussion; PT_ATTACH_PD on its own is fine I suppose, but I do not really see the point unless you want to enable capmode ptrace(). Meanwhile, NOTE_FORK already exists, and supporting it from procdesc does not require much complexity (I think?), and procdescs already implement NOTE_EXIT. Plus, with procdescs you can avoid PID reuse races. For ptrace() I think such races are probably not a real concern (but correct me if I am wrong).

For ptrace() the races are impossible since the target is reparented to the debugger.

So, I think it makes some sense to leave NOTE_FORK available for procdescs.

Ok, consumed the new bit for NOTE_PDSIGCHLD.

BTW, does anything prevent a capmode process from using EVFILT_PROC? If not, then that is a bug.

Yes, this seems to be a bug. It is easy to disallow registering new knotes when in cap mode. What should we do about knotes that are were registered before entering the cap mode?

[kib]

Don't alias NOTE_FORK.

[markj]

sys/sys/event.h

206

It is easy to disallow registering new knotes when in cap mode.

Maybe kqueue filters with f_isfd == 0 should be disallowed by default in capability mode, with some mechanism to opt in. We have:

• EVFILT_JAIL, should be disallowed by default
• EVFILT_PROC, should be disallowed by default
• EVFILT_TIMER, seems ok
• EVFILT_SIGNAL, seems ok
• EVFILT_AIO/LIO, probably ok, I am not sure
• EVFILT_FS, should be disallowed by default

What should we do about knotes that are were registered before entering the cap mode?

The only real choices seem to be 1) ignore them, 2) in cap_enter(), go through all of the process' kqueues and knotes, and somehow purge them.

I think 1) is probably acceptable. 2) is significant complexity for a very rare and easily avoidable situation. Maybe @emaste or @oshogbo have an opinion there.

[markj]

sys/kern/sys_procdesc.c

351

In procdesc_kqops_event() there is a test, if (event == NOTE_EXIT). Probably that needs to change to if (event & NOTE_EXIT).

[kib]

Properly test for the no longer solo flag.

[kib]

Update the man page

[markj]

sys/kern/sys_procdesc.c

524–525

Should this generate NOTE_PDSIGCHLD too?

[kib]

Always report PDSIGCHLD when reporting EXIT.