This is a legacy interface from 4.4BSD, and it was
introduced to overcome shortcomings of ptrace(2) at that time, which are
no longer relevant (performance). Today /proc/#/ctl offers a narrow
subset of ptrace(2) commands and is not applicable for modern
applications use beyond simplistic tracing scenarios.
This removal will simplify kernel internals. Users will still be able to
use all the other /proc files.
This change won't affect other procfs files neither Linux compat
features within mount_procfs(8). /proc/#/ctl isn't available on Linux.
Remove:
- /proc/#/ctl from mount_procfs(8)
- P_FSTRACE note from the documentation of ps(1)
- /proc/#/ctl and filesystem tracing documentation from mount_procfs(8)
- KAUTH_REQ_PROCESS_PROCFS_CTL documentation from kauth(9)
- source code file miscfs/procfs/procfs_ctl.c
- PFSctl and procfs_doctl() from sys/miscfs/procfs/procfs.h
- KAUTH_REQ_PROCESS_PROCFS_CTL from sys/sys/kauth.h
- PSL_FSTRACE (0x00010000) from sys/sys/proc.h
- P_FSTRACE (0x00010000) from sys/sys/sysctl.h
Reduce code complexity after removal of this functionality.
Update TODO.ptrace accordingly: remove two entries about /proc tracing.
Do not keep legacy notes as comments in the headers about removed
PSL_FSTRACE / P_FSTRACE, as this interface had little number of users
(close or equal to zero).
Proposed on tech-kern@.
All filesystem tracing utility users are encouraged to switch to ptrace(2).
Sponsored by <The NetBSD Foundation>
Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
If it's yes, all local symbols of shared libraries are stripped
(default). If it's no, only temporary local symbols are stripped;
for example, symbols of static functions are kept. Keeping such
symbols is useful on using DTrace for userland libraries and
getting a backtrace from a rump server loading modules (shared
libraries).
Proposed and discussed on tech-kern and tech-toolchain
Remove entries:
- research support PT_SYSCALL & PT_STEP combined like in Linux
- GDB Remote Protocol expects a case with a step with a signal to be sent,
this is currently unsupported on NetBSD
Implemented as PT_SETSTEP and PT_CLEARSTEP.
Remove:
- support QPassSignals (PT_SET_SIGPASS/PT_GET_SIGPASS) in the kernel, a way to
stop routing a set of signals to tracer as they are uninteresting - GDB and
LLDB expect this feature
This interface has been abandoned and will be handled on the debugger level.
Sponsored by <The NetBSD Foundation>
Added:
support QPassSignals (PT_SET_SIGPASS/PT_GET_SIGPASS) in the kernel, a way to
stop routing a set of signals to tracer as they are uninteresting - GDB and
LLDB expect this feature
Added entries:
ptrace(2): Add new API replacing PT_WATCHPOINT for Debug Registers:
PT_GETDBREGS and PT_SETDBREGS
siginfo(2): Add new si_code values for SIGTRAP: TRAP_SCE and TRAP_SCX
Sponsored by <The NetBSD Foundation>
Remove entries:
- add new ptrace(2) calls to lock (suspend) and unlock LWP within a process
- switch PT_WATCHPOINT* to PT_*ETDBREGS and document it, add ATF tests
- add ATF tests for PT_SYSCALL and PT_SYSCALLEMU
Sponsored by <The NetBSD Foundation>
It replaces previous TRAP_HWWPT and is designed to be used for debug
register traps (both watchpoints and breakpoints).
TRAP_HWWPT wasn't documented in siginfo(2) neither noted in doc/CHANGES -
- document it and add new entry in CHANGES. This move is a step towards
switch the watchpoint ptrace(2) api to PT_*DBREGS.
This code was introduced recently and has no impact on stable releases.
Sponsored by <The NetBSD Foundation>
Remove:
- add PT_SET_SIGMASK and PT_GET_SIGMASK - used by checkpointing software
This interface has been committed to HEAD.
Sponsored by <The NetBSD Foundation>
Added entries:
- add support to read debugger events via a file descriptor in procfs
(kevent(2)), it's still useful in cases when a parent traces tracee and has
to call waitpid(2) for its child - as this clashes with GUI toolkits
- fix more calls for netbsd32 compat
Sponsored by <The NetBSD Foundation>
Remove entries:
- remove exect(3) from libc - there is no usecase for it
Interface has been marked obsolete and it's on the queue to be removed for.
- research what happens when a tracee masks signals (including SIGTRAP) and a
breakpoint is triggered
It has been researched and ATF tests added (signal1 .. signal10).
It's currently broken on NetBSD.
Add:
- research support PT_SYSCALL & PT_STEP combined like in Linux
There are circumstances when we want to sstep and catch syscall events.
Sponsored by <The NetBSD Foundation>
libpthread_dbg(3) is a remnant library from the M:N thread model
(pre-NetBSD-5.0) API to introspect threads within a process and for use
of debuggers.
Currently in the 1:1 model it's not used in GDB neither in LLDB and it's
not either planned to be used. It's current function to read pthread_t
structures is realizable within a regular debugger capable to
instrospect objects within a tracee (GDB, LLDB...).
Remaining users of this API can still use this library from
pkgsrc/devel/libpthread_dbg.
Sponsored by <The NetBSD Foundation>
Note PT_WATCHPOINT change to PT_*ETDBREGS.
Remove GDB and LLDB related entries from generic ptrace(2) TODO.
Note need for TRAP_SCE and TRAP_SCX si_codes in PT_SYSCALL*.
Note removal request of pthread_dbg(3).
Sponsord by <The NetBSD Foundation>
Things I want to finish for 8:
- as much as possible from the LLDB, Swift, .NET and VirtualBox projects
- more c11 in libc
Things I want to research for 9:
- turn system utilities into C libraries + add bindings for Lua
- rebase Haiku stack on NetBSD + add Kit(s) accessing libsystem utilities
Drop:
- add ATF tests for PIOD_READ_AUXV
Add new entry:
- research what happens when a tracee masks signals (including SIGTRAP)
and a breakpoint is triggered
Sponsored by <The NetBSD Foundation>
bpf_mtap of some drivers is still called in hardware interrupt context.
We want to run them in softint as well as bpf_mtap of most drivers
(see if_percpuq_softint and if_input).
To this end, bpf_mtap_softint mechanism is implemented; it defers
bpf_mtap processing to a dedicated softint for a target driver.
By using the machanism, we can move bpf_mtap processing to softint
without changing target drivers much while it adds some overhead
on CPU and memory. Once target drivers are changed to softint-based,
we should return to normal bpf_mtap.
Proposed on tech-kern and tech-net
Added new entries:
ptrace(2): Add new options in EVENT_MASK: PTRACE_LWP_CREATE and
PTRACE_LWP_EXIT
siginfo(2): Add new si_code for SIGTRAP: TRAP_LWP
Sponsored by <The NetBSD Foundation>
Removed:
- evaluate equivalent for PTRACE_O_TRACECLONE from Linux
clone(2)-like calls are traced with PTRACE_FORK, PTRACE_VFORK and
PTRACE_VFORK_DONE. VFORK ones block parent till termination or execve(2) of
its child.
Added:
- add proper implementation of PTRACE_VFORK for vfork(2)-like events
Currently PTRACE_VFORK is a stub.
Sponsored by <The NetBSD Foundation>
since the pre-6.0 period and nobody else has been doing the work. There's
a lot of things whose current state I don't know; please fill in. Also the
stuff I've added is necessarily biased towards projects I think about, so
please add more.
1. siginfo_t accessors done
2. PTRACE_O_TRACEEXIT not applicable for NetBSD as we are tracing the whole
process at once, not per thread
3. PTRACE_O_TRACEEXEC implemented as SIGTRAP & TRAP_EXEC
Sponsored by <The NetBSD Foundation>
Added:
ptrace(2): Add new si_code value of SIGTRAP: TRAP_EXEC [kamil 20170107]
ptrace(2): Add signal information accessors API:
PT_GET_SIGINFO and PT_SET_SIGINFO [kamil 20170107]
Sponsored by <The NetBSD Foundation>
Mark exect(3) for removal, there is no use-case for it. exec() is already
monitored and emits SIGTRAP when traced.
Accessor for siginfo_t is not case for PT_IO -- it's not reading/writing
process space of other process, but shared kernel space.
Currently all the MD interfaces are documented, remove this line from TODO.
Add new note:
once the API for hardware watchpoints will stabilize, document it
Sponsored by <The NetBSD Foundation>
Hardware assisted breakpoint/watchpoint API has been merged with current.
Add note about pthread_dbg(3) API needed to be refactored and limited to
querying POSIX thread private data fields.
Sponsored by <The NetBSD Foundation>
- add support for detecting equivalent events to PTRACE_O_TRACEEXEC,
PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT from Linux
- exect(3) rething or remove -- maybe PT_TRACE_ME + PTRACE_O_TRACEEXEC?
Sponsored by <The NetBSD Foundation>
Add new entries:
- add support for PT_STEP, PT_GETREGS, PT_SETREGS, PT_GETFPREGS,
PT_SETFPREGS in all ports
- integrate all ptrace(2) features in gdb
- add ptrace(2) NetBSD support in LLDB
Sponsored by <The NetBSD Foundation>