Add a mask of optional ptrace() events.

[jhb]

Summary

Add a mask of optional ptrace() events.

ptrace() now stores a mask of optional events in p_ptevents. Currently
this mask is a single integer, but it can be expanded into an array of
integers in the future.

Two new ptrace requests can be used to manipulate the event mask:
PT_GET_EVENT_MASK fetches the current event mask and PT_SET_EVENT_MASK
sets the current event mask.

The current set of events include:

• PTRACE_EXEC: trace calls to execve().
• PTRACE_SIG: trace signals.
• PTRACE_SCE: trace system call entries.
• PTRACE_SCX: trace syscam call exits.
• PTRACE_FORK: trace forks and auto-attach to new child processes.
• PTRACE_LWP: trace LWP events.

The S_PT_SCX and S_PT_SCE events in the procfs p_stops flags have
been replaced by PTRACE_SCE and PTRACE_SCX. PTRACE_FORK replaces
P_FOLLOW_FORK and PTRACE_LWP replaces P2_LWP_EVENTS.

Assuming I can't fit this into 11.0, I may try to request the p_ptevents
slot in the pre-zeroed area at least. Its not the end of the world if
it has to wait though.

Test Plan

• Run new tests as well as existing ptrace tests.

[kib]

Does P_TRACED implies that PTRACE_SIG must be set ? I would expect this, but this is not enforced by the PT_SET_EVENT_MASK interface.

Is P_TRACED flag needed ? What would the behaviour if debugger clears the mask ?

sys/kern/kern_exit.c

341 ↗

(On Diff #18051)

Why is this needed ?

sys/kern/sys_process.c

994 ↗

(On Diff #18051)

You don't check that only supported bits are set in the user supplied mask.

[jhb]

sys/kern/kern_exit.c

341 ↗

(On Diff #18051)

I explicitly cleared p_ptevents to 0 in all the places that cleared P_TRACED so that I could just use 'p->p_ptevents & PTRACE_FOO' without also having to check if P_TRACED was still set.

[jhb]

In D7044#147411, @kib wrote:

Does P_TRACED implies that PTRACE_SIG must be set ? I would expect this, but this is not enforced by the PT_SET_EVENT_MASK interface.

Is P_TRACED flag needed ? What would the behaviour if debugger clears the mask ?

The idea is for P_TRACED to not imply PTRACE_SIG. In theory if PTRACE_SIG is clear, then signals are passed to the debugee transparently without any notice to the debugger. Explicit events like SCE/SCX that call ptracestop() directly will still post events. SIGTRAP due to breakpoints or watchpoints should always register a stop as well regardless of PTRACE_SIG (I suspect I might not be handling that correctly in the current patch, in fact I'm almost certainly not.) It may be that it is just too hard to get that right (and of limited usefulness). If so, I can drop PTRACE_SIG and just leave signal catching always enabled. procfs treats S_SIG as a flag, so I was trying to provide an equivalent level of granularity. It does seem that blocking S_SIG in procfs might also break breakpoints in debuggers though.

[jhb]

• Check for invalid events.

[jhb]

• Drop PTRACE_SIG.
• Add a test for a user signal delivery.
• Renumber after dropping PTRACE_SIG.

[jhb]

• New child processes should not inherit the event mask.
• Update the manpage for the event mask.

[kib]

lib/libc/sys/ptrace.2

152 ↗

(On Diff #18437)

'kernel-scheduled threads' ?

155 ↗

(On Diff #18437)

lowercase N in new.

'Stop _and_ report an event. ' Initially I read it as the statement that PL_FLAG_BORN reporting is not performed anymore.

sys/kern/sys_process.c

659 ↗

(On Diff #18437)

A comment stating that uap->data is sanity checked elsewhere could be useful.

[jhb]

• Note that uap->data is validated in kern_ptrace().
• Suggestions from Konstantin.

[jhb]

lib/libc/sys/ptrace.2

152 ↗

(On Diff #18437)

Most places I'm familiar with (textbooks, etc.) just use "kernel threads" for LWPs (vs "user threads" for scheduler activations / libc_r, etc.).