Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

[Jason Thorpe <thorpej%me.com@localhost>]

> On Oct 15, 2021, at 1:19 PM, Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
> 
> On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote:
> 
>> On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
>> 
>>> Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
>> 
>> It's been ages since I touched this area, but don't we have
>> per-sigaction trampolines?  I mean, in practice they all use the same
>> __sigtramp_siginfo_$version trampoline, that sigaction passes to the
>> actual syscall, but in principle the process can have different
>> trampolines for different signals, can't it?
>> 
>> struct sys___sigaction_sigtramp_args {
>> 	syscallarg(int) signum;
>> 	syscallarg(const struct sigaction *) nsa;
>> 	syscallarg(struct sigaction *) osa;
>> 	syscallarg(const void *) tramp; // <-
>> 	syscallarg(int) vers;
>> };
> 
> PS: We used to have a trampoline that the kernel copied out into the
> process address space (bottom of the stack, iirc) - and that would be
> something for KERN_PROC_SIGTRAMP to return indeed.  But that was like
> before netbsd 2.0, iirc.

Right, that was The Very Old Way.  There is an API contract between libc and the kernel vis a vis the signal trampoline, but the trampoline itself is in libc, which could get mapped anywhere.  So there is not a single static address that could be returned, even per-process, because, as uwe points out, the trampoline can be specified on a per-signal basis (there is one for "siginfo" signal delivery and another for the old-style "sigcontext" signal delivery).

-- thorpej