ptrace(2): PT_SET_SC_RET request

[kib]

Document PT_SET_SC_RET

[markj]

sys/kern/sys_process.c

1350

1364

Why not set TDB_USERWR here?

[kib]

sys/kern/sys_process.c

1350

I will also fix the style for PT_GET_SC_RET then.

1364

It would not serve any purpose, IMO.

[kib]

Style

[markj]

lib/libsys/ptrace.2

866 ↗

(On Diff #182031)

The size is not validated anywhere AFAICS.

871 ↗

(On Diff #182031)

My suggestion for the last sentence: "After the thread is resumed, it returns to userspace with machine state set as though the system call handler had returned the values passed via the .Fa data argument."

sys/compat/freebsd32/freebsd32_misc.c

1065

Shouldn't we require uap->data == sizeof(r32.psr)? If uap->data is smaller, we'll copy uninitialized stack bytes into the native struct.

[markj]

sys/kern/subr_syscall.c

70

How is it possible to have !traced && (td->td_dbgflags & TDB_SET_SC_RET) != 0?

[kib]

lib/libsys/ptrace.2

871 ↗

(On Diff #182031)

I replaced it with the slight modification, it is not the 'data'.

sys/kern/subr_syscall.c

70

Might be it is not, but I did it out of caution.

I can remove it, but the idea is to ensure that the flags affecting the previous syscall entry do not leak to the current.

[kib]

Validate uap->data to be the size of the structure.
Edit man page.

[markj]

lib/libsys/ptrace.2

873 ↗

(On Diff #182061)

sys/kern/subr_syscall.c

88

If TDB_SET_SC_RET is set, we will log the syscall via KTR and ktrace (but not dtrace) even though it is not executed. IMO it is better not to log anything in this case, i.e., we should skip this tracing.

[kib]

sys/kern/subr_syscall.c

88

TDB_SET_SC_RET is not set at this point, so KTR tracing goes due to the natural flow.

But for ktrace records, I thought about it, and I want them both (enter/exit) recorded. When I do the ktrace, I want to see the traced program perception of the kernel actions, and this includes the fake syscalls.

In fact, my use case is that I did 'ktrace -di capsicumised-truss -f sh -c 'date;date' and I want to see the values reported to the controlled process, sh in this case, by the tracer (truss).

In principle I agree with the sentiment that a marker would be useful in the ktrace records that would flag the fake syscall results.