>Does the problem persist with allow_wx = 1? No In that case there would be no core dump, but the script would time out after 300 seconds. Doing some manual experiments It seems it fails to set the watchpoint or the probes wont fire
# sysctl kern.elf64.allow_wx=1 kern.elf64.allow_wx: 0 -> 1 # sysctl kern.elf64.aslr.enable=1 kern.elf64.aslr.enable: 1 -> 1 # sysctl kern.elf64.aslr.pie_enable=1 kern.elf64.aslr.pie_enable: 1 -> 1 # exec find / > /dev/null 2>&1 & [1] 27041 akumar3-79afpc2-1# dtrace -n pid27041:a.out:: dtrace: description 'pid27041:a.out::' matched 6828 probes CTRL+C -Amit ________________________________ From: Mark Johnston <[email protected]> on behalf of [email protected] <[email protected]> Sent: Monday, February 14, 2022 7:23 PM To: Amit kumar <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: dtrace fails to trace on FreeBSD-14(CURRENT) with ASLR and W^X On Mon, Feb 14, 2022 at 11:03:47AM +0000, Amit kumar wrote: > Encountered this issue while running > https://github.com/freebsd/freebsd-src/blob/main/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/pid/tst.emptystack.d > > a somewhat simpler method to reproduce > > configuration > file /usr/bin/find > /usr/bin/find: ELF 64-bit LSB shared object, x86-64, <.....> > > kern.elf64.allow_wx: 0 > kern.elf64.aslr.pie_enable: 1 > kern.elf64.aslr.enable: 1 Does the problem persist with allow_wx = 1? > # dtrace -n pid92817:::entry > dtrace: description 'pid92817:::entry' matched 4380 probes > [2] + trace trap (core dumped) exec find / > /dev/null 2>&1 > > # exec find / > /dev/null 2>&1 & > [1] 85293 > # dtrace -n pid85293:a.out:: > dtrace: description 'pid85293:a.out::' matched 6828 probes > [1] + trace trap (core dumped) exec find / > /dev/null 2>&1 > CPU ID FUNCTION:NAME > 1 89149 find_execute:1f8 > > looking at find core in gdb > (gdb) p $_siginfo > $1 = { > si_signo = 5, > si_errno = 0, > si_code = 3, > . > . > . > > Can someone help me understand why am I seeing core due to SIGTRAP > TRAP_DTRACE ? > > Regards > Amit
