#
d60d18db |
| 18-Jun-2019 |
kamil <kamil@NetBSD.org> |
Add support for KTR logs of SIGTRAP for TRAP_CHILD events
Previously it was disabled due to vfork(2) synchronization issues. These problems are now gone.
While there, set l_vforkwaiting to false in
Add support for KTR logs of SIGTRAP for TRAP_CHILD events
Previously it was disabled due to vfork(2) synchronization issues. These problems are now gone.
While there, set l_vforkwaiting to false in posix_spawn. This is not very needed but it does not make harm to keep it initialized explicitly.
show more ...
|
#
af08e3a4 |
| 13-Jun-2019 |
kamil <kamil@NetBSD.org> |
Correct use-after-free issue in vfork(2)
In the previous behavior vforking parent was keeping pointer to a child and checking whether it clears a PL_PPWAIT in its bitfield p_lflag. However a child c
Correct use-after-free issue in vfork(2)
In the previous behavior vforking parent was keeping pointer to a child and checking whether it clears a PL_PPWAIT in its bitfield p_lflag. However a child can go invalid between exec/exit event from child and waking up vforked parent and this can cause invalid pointer read and in the worst scenario kernel crash.
In the new behavior vforked child keeps a reference to vforked parent LWP and sets a value l_vforkwaiting to false. This means that vforked child can finish its work, exec/exit and be terminated and once parent will be woken up it will read its own field whether its child is still blocking.
Add new field in struct lwp: l_vforkwaiting protected by proc_lock. In future it should be refactored and all PL_PPWAIT users transformed to l_vforkwaiting and next l_vforkwaiting probably transformed into a bit field.
This is another attempt of fixing this bug after <rmind> from 2012 in commit:
Author: rmind <rmind@NetBSD.org> Date: Sun Jul 22 22:40:18 2012 +0000
fork1: fix use-after-free problems. Addresses PR/46128 from Andrew Doran. Note: PL_PPWAIT should be fully replaced and modificaiton of l_pflag by other LWP is undesirable, but this is enough for netbsd-6.
The new version no longer performs unsafe access in l_lflag changing the LP_VFORKWAIT bit.
Verified with ATF t_vfork and t_ptrace* tests and they are no longer causing any issues in my local setup.
Fixes PR/46128 by Andrew Doran
show more ...
|
#
f2f41f9b |
| 11-Jun-2019 |
kamil <kamil@NetBSD.org> |
Add support for PTRACE_POSIX_SPAWN to report posix_spawn(3) events
posix_spawn(3) is a first class syscall in NetBSD, different to (V)FORK+EXEC as these operations are executed in one go. This diffe
Add support for PTRACE_POSIX_SPAWN to report posix_spawn(3) events
posix_spawn(3) is a first class syscall in NetBSD, different to (V)FORK+EXEC as these operations are executed in one go. This differs to Linux and FreeBSD, where posix_spawn(3) is implemented with existing kernel primitives (clone(2), vfork(2), exec(3)) inside libc.
Typically LLDB and GDB software is aware of FORK/VFORK events. As discussed with the LLDB community, instead of slicing the posix_spawn(3) operation into phases emulating (V)FORK+EXEC(+VFORK_DONE) and returning intermediate state to the debugger, that might have abnormal state, introduce new event type: PTRACE_POSIX_SPAWN.
A debugger implementor can easily map it into existing fork+exec semantics or treat as a distinct event.
There is no functional change for existing debuggers as there was no support for reporting posix_spawn(3) events on the kernel side.
show more ...
|
#
0cb12df9 |
| 09-May-2019 |
kamil <kamil@NetBSD.org> |
Report TRAP_EXEC (for exec()) to a debugger in the PT_SYSCALL mode
Orignally exec() reporting was disabled in the NetBSD version as there was no support for fine-grained reporting. Meanwhile PT_SYSC
Report TRAP_EXEC (for exec()) to a debugger in the PT_SYSCALL mode
Orignally exec() reporting was disabled in the NetBSD version as there was no support for fine-grained reporting. Meanwhile PT_SYSCALL was broken for years and there is no software that depends on this behavior.
There is need to catch exec() events in syscall tracers using ptrace(2). Instead of adding workarounds of guessing that exec() happened, report the event directly from the kernel.
All ATF ptrace(2) tests pass.
show more ...
|
#
25402c4b |
| 03-May-2019 |
kamil <kamil@NetBSD.org> |
Register KTR events for debugger related signals
Register signals for:
- crashes (FPE, SEGV, FPE, ILL, BUS) - LWP events - CHLD (FORK/VFORK/VFORK_DONE) events -- temporarily disabled - EXEC eve
Register KTR events for debugger related signals
Register signals for:
- crashes (FPE, SEGV, FPE, ILL, BUS) - LWP events - CHLD (FORK/VFORK/VFORK_DONE) events -- temporarily disabled - EXEC events
While there refactor related functions in order to simplify the code.
Add missing comment documentation for recently added kernel functions.
show more ...
|
#
e1b6b715 |
| 01-May-2019 |
kamil <kamil@NetBSD.org> |
Add eventswitch() in signal code
Route all crash and debugger related signal through eventswitch(), that calls sigswitch() with preprocessed arguments.
This code avoids code duplication and allows
Add eventswitch() in signal code
Route all crash and debugger related signal through eventswitch(), that calls sigswitch() with preprocessed arguments.
This code avoids code duplication and allows to introduce changes that will affect all callers of sigswitch() in debugger-related events.
No functional change intended.
show more ...
|
#
53a908d5 |
| 11-Nov-2018 |
maxv <maxv@NetBSD.org> |
Fix stack info leak. There are 2x4 bytes of padding in struct ps_strings.
[ 223.896199] kleak: Possible leak in copyout: [len=32, leaked=8] [ 223.906430] #0 0xffffffff80224d0a in kleak_note <netbs
Fix stack info leak. There are 2x4 bytes of padding in struct ps_strings.
[ 223.896199] kleak: Possible leak in copyout: [len=32, leaked=8] [ 223.906430] #0 0xffffffff80224d0a in kleak_note <netbsd> [ 223.906430] #1 0xffffffff80224d8a in kleak_copyout <netbsd> [ 223.918363] #2 0xffffffff80b1e26c in copyoutpsstrs <netbsd> [ 223.926560] #3 0xffffffff80b1e331 in copyoutargs <netbsd> [ 223.936216] #4 0xffffffff80b21768 in execve_runproc <netbsd> [ 223.946225] #5 0xffffffff80b21cc9 in execve1 <netbsd> [ 223.946225] #6 0xffffffff8025a89c in sy_call <netbsd> [ 223.956225] #7 0xffffffff8025aace in sy_invoke <netbsd> [ 223.966232] #8 0xffffffff8025ab54 in syscall <netbsd>
show more ...
|
#
a8a5c538 |
| 03-Sep-2018 |
riastradh <riastradh@NetBSD.org> |
Rename min/max -> uimin/uimax for better honesty.
These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a n
Rename min/max -> uimin/uimax for better honesty.
These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation.
To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!)
show more ...
|
#
ffe0b410 |
| 10-Aug-2018 |
pgoyette <pgoyette@NetBSD.org> |
Allow syscall_establish() to install new syscalls when the existing entry-point is either sys_nomodule or sys_nosys. Update the makesyscalls.sh script to create a const array of bits to allow syscal
Allow syscall_establish() to install new syscalls when the existing entry-point is either sys_nomodule or sys_nosys. Update the makesyscalls.sh script to create a const array of bits to allow syscall_disestablish() to properly restore the original entry-point. Update all the initializers of struct emul to initialize the pointer to the bit array struct emul.
XXX Regen of all files created by makesyscalls.sh will come soon, XXX followed by a kernel version bump (since struct emul is being XXX modified).
This commit should address PR kern/45781 and also removes the need for the work-around for that PR in file
sys/arch/usermode/modules/syscallemu/syscallemu.c
show more ...
|
#
13ef58b9 |
| 28-May-2018 |
kamil <kamil@NetBSD.org> |
Correct reporting SIGTRAP TRAP_EXEC when SIGTRAP is masked
Switch from kpsignal(9) to sigswitch() as it allows to bypass signal masking rules of a crash signal.
There are no regressions in existing
Correct reporting SIGTRAP TRAP_EXEC when SIGTRAP is masked
Switch from kpsignal(9) to sigswitch() as it allows to bypass signal masking rules of a crash signal.
There are no regressions in existing tests.
Sponsored by <The NetBSD Foundation>
show more ...
|
#
03744b1d |
| 06-May-2018 |
kamil <kamil@NetBSD.org> |
Remove an element from struct emul: e_tracesig
e_tracesig used to be implemented for Darwin compat. Nowadays the Darwin compatiblity layer is gone and there are no other users.
This functionality i
Remove an element from struct emul: e_tracesig
e_tracesig used to be implemented for Darwin compat. Nowadays the Darwin compatiblity layer is gone and there are no other users.
This functionality isn't used where it shall be used in the existing codebase.
If we want to emulate debugging interfaces in compat layers we would need to implement that from scratch anyway. We would need to be bug compatible with other OSes too.
Proposed on tech-kern@.
Welcome to NetBSD 8.99.16!
Sponsored by <The NetBSD Foundation>
show more ...
|
#
5e7f619c |
| 27-Apr-2018 |
christos <christos@NetBSD.org> |
Canonicalize the interpreter path in #! scripts since check_exec() expects an absolute path, and we KASSERT if that's not the case later.
|
#
248b6b25 |
| 23-Feb-2018 |
maxv <maxv@NetBSD.org> |
Fix off-by-one, we don't want the entry point to equal the maximum address.
|
#
8e176c07 |
| 09-Jan-2018 |
maya <maya@NetBSD.org> |
remove struct emul's e_fault.
It used to be used by COMPAT_IRIX for the purpose of overriding uvm_fault (only implemented in MIPS), now removed.
Ride 8.99.12 version bump.
|
#
f3fde60c |
| 05-Jan-2018 |
christos <christos@NetBSD.org> |
don't print for ENOEXEC
|
#
b08db97c |
| 13-Nov-2017 |
christos <christos@NetBSD.org> |
grab a copy of the absolute pathbuf, before namei() munges it.
|
#
0cf36620 |
| 13-Nov-2017 |
christos <christos@NetBSD.org> |
Use the pathbuf which we pass to namei() (which is always absolute) as the resolved pathname. We need this in the case of scripts where p_path needs to point to the interpreter and not the script its
Use the pathbuf which we pass to namei() (which is always absolute) as the resolved pathname. We need this in the case of scripts where p_path needs to point to the interpreter and not the script itself. Otherwise things like perl script that depend on /proc/$$/exe to re-exec themselves end up being fork bombs.
In reality we should be using the fully resolved/canonicalized path here, but namei is not giving it back to us.
show more ...
|
#
3a1c544a |
| 07-Nov-2017 |
christos <christos@NetBSD.org> |
hack around namei problem.
|
#
cf469f47 |
| 07-Nov-2017 |
christos <christos@NetBSD.org> |
Store full executable path in p->p_path as discussed in tech-kern. This means that the full executable path is always available.
- exec_elf.c: use p->path to set AT_SUN_EXECNAME, and since this is
Store full executable path in p->p_path as discussed in tech-kern. This means that the full executable path is always available.
- exec_elf.c: use p->path to set AT_SUN_EXECNAME, and since this is always set, do so unconditionally. - kern_exec.c: simplify pathexec, use kmem_strfree where appropriate and set p->p_path - kern_exit.c: free p->p_path - kern_fork.c: set p->p_path for the child. - kern_proc.c: use p->p_path to return the executable pathname; the NULL check for p->p_path, should be a KASSERT? - exec.h: gc ep_path, it is not used anymore - param.h: bump version, 'struct proc' size change
TODO: 1. reference count the path string, to save copy at fork and free just before exec? 2. canonicalize the pathname by changing namei() to LOCKPARENT vnode and then using getcwd() on the parent directory?
show more ...
|
#
8e7ce8e7 |
| 20-Oct-2017 |
riastradh <riastradh@NetBSD.org> |
Initialize the in/out parameter vmin.
vmin is only an optional hint since we're not passing UVM_FLAG_FIXED, but that doesn't mean we should use uninitialized stack garbage as the hint.
Noted by chs
Initialize the in/out parameter vmin.
vmin is only an optional hint since we're not passing UVM_FLAG_FIXED, but that doesn't mean we should use uninitialized stack garbage as the hint.
Noted by chs@.
show more ...
|
#
bd3f4e6e |
| 20-Oct-2017 |
riastradh <riastradh@NetBSD.org> |
Carve out KVA for execargs on boot from an exec_map like we used to.
Candidate fix for PR kern/45718: `processes sometimes get stuck and spin in vm_map', a problem that has been plaguing all our 32-
Carve out KVA for execargs on boot from an exec_map like we used to.
Candidate fix for PR kern/45718: `processes sometimes get stuck and spin in vm_map', a problem that has been plaguing all our 32-bit ports for years.
Since we currently use large (256k) buffers for execargs, and since nobody has stepped up to tackle breaking them into bite-sized (or at least page-sized) chunks, after KVA gets sufficiently fragmented we can't allocate new execargs buffers from kernel_map.
Until 2008, we always carved out KVA for execargs on boot with a uvm submap exec_map of kernel_map. Then ad@ found that the uvm_km_free call, to discard them when done, cost about 100us, which a pool avoided:
https://mail-index.NetBSD.org/tech-kern/2008/06/25/msg001854.html https://mail-index.NetBSD.org/tech-kern/2008/06/26/msg001859.html
ad@ _simultaneously_ introduced a pool _and_ eliminated the reserved KVA in the exec_map submap. This change preserves the pool, but restores exec_map (with less code, by putting it in MI code instead of copying it in every MD initialization routine).
Patch proposed on tech-kern: https://mail-index.NetBSD.org/tech-kern/2017/10/19/msg022461.html
Patch tested by bouyer@: https://mail-index.NetBSD.org/tech-kern/2017/10/20/msg022465.html
I previously discussed the issue on tech-kern before I knew of the history around exec_map: https://mail-index.NetBSD.org/tech-kern/2012/12/09/msg014695.html
The candidate workaround I proposed of using pool_setlowat to force preallocation of KVA would also force preallocation of physical RAM, which is a waste not incurred by using exec_map, and which is part of why I never committed it.
There may remain a general problem that if thread A calls pool_get and tries to service that request by a uvm_km_alloc call that hangs because KVA is scarce, and thread B does pool_put, the pool_put in thread B will not notify the pool_get in thread A that it doesn't need to wait for KVA, and so thread A may continue to hang in uvm_km_alloc. However,
(a) That won't apply here, because there is exactly as much KVA available in exec_map as exec_pool will ever try to use.
(b) It is possible that may not even matter in other cases as long as the page daemon eventually tries to shrink the pool, which will cause a uvm_km_free that can unhang the hung uvm_km_alloc.
XXX pullup-8 XXX pullup-7 XXX pullup-6 XXX pullup-5, perhaps...
show more ...
|
#
3f085043 |
| 20-Oct-2017 |
martin <martin@NetBSD.org> |
Make check_exec() errors print the name of the binary that fails to execute.
|
#
b036f7f8 |
| 29-Sep-2017 |
maxv <maxv@NetBSD.org> |
Remove compat_linux32 from the autoload list and add a enable/disable sysctl, like compat_linux.
|
#
f4568e4a |
| 29-Sep-2017 |
maxv <maxv@NetBSD.org> |
Remove compat_linux from the autoload list, and add a sysctl to enable or disable it - which defaults to disabled. The following command is now required to use linux binaries:
sysctl -w emul.linux.
Remove compat_linux from the autoload list, and add a sysctl to enable or disable it - which defaults to disabled. The following command is now required to use linux binaries:
sysctl -w emul.linux.enabled=1
After a discussion on tech-kern@. All the other ideas to reduce the attack surface have drawbacks, and this sysctl seems to be the best option.
show more ...
|
#
259b7bfe |
| 08-Aug-2017 |
maxv <maxv@NetBSD.org> |
Remove compat_svr4, compat_svr4_32 and compat_ibcs2 from the list of autoloaded modules. These options are disabled everywhere (except ibcs2 on Vax, but Vax does not support kernel modules, so doesn'
Remove compat_svr4, compat_svr4_32 and compat_ibcs2 from the list of autoloaded modules. These options are disabled everywhere (except ibcs2 on Vax, but Vax does not support kernel modules, so doesn't matter), therefore there is no issue in removing them from the list. Interested users will now have to do a 'modload' first, or uncomment the entries in GENERIC.
show more ...
|