The following simple testcase fails when ran in jail, but works outside: # gdb /bin/cat (gdb) run ... ^C (gdb) print (char*)"asd" Cannot access memory at address 0x7fffffffe45f Interestingly, the address looks completely different in the prison 0: (gdb) print (char*)"asd" $2 = 0x801608028 "asd" I first thought it is a gdb-specific problem, but it seems that lldb also suffers from it. The only difference is much less clear error message: (lldb) print (char*)"asd" error: Can't evaluate the expression without a running target due to: Interpreter doesn't handle one of the expression's operands
address 0x7fffffffe45f vs address 0x801608028 suggests that debugger either - cannot disable aslr, - or cannot properly read disabled aslr status, in the jail. Can you try to see if either is the case?
Also just to confirm, lldb does work as expected outside of a jail?
(In reply to Konstantin Belousov from comment #1) Doesn't seem to be the either case. In GDB the ASLR handling is consolidated here [1]. I put the debugging output everywhere in this function and verified that all procctl() calls succeed. I also tried setting kern.elf64.aslr.enable=0 outside of the jail (without restarting the jail, though) and it had no effect on the problem. Neither running gdb under proccontrol -m aslr -s disable change anything. I also tried elfctl -e +noaslr on both gdb and cat binaries - nothing helps the issue. [1] https://github.com/bminor/binutils-gdb/blob/877d74ab5f2f33aa062c4b8d1ba910a46e4ef9d1/gdb/fbsd-nat.c#L1776
(In reply to Ed Maste from comment #2) Yes, outside of a jail the 'print (char*)"asd"' command works fine in both debuggers.
Could you try to ktrace gdb in the jail and see what syscall fails, and how? BTW, when you say that gdb in jail fails, you do run both the target process and gdb itself in the same jail, right?
(In reply to Konstantin Belousov from comment #5) I see suspicious ptrace failures at the end of the dump: 53589 gdb151 CALL ptrace(PT_LWPINFO,0x76ae2,0x8227bb130,0xa0) 53589 gdb151 RET ptrace 0 53589 gdb151 CALL ptrace(PT_IO,0x76ae2,0x8227bb1b0,0) 53589 gdb151 RET ptrace -1 errno 1 Operation not permitted At the same time, there are no ptrace failures in the dump of the unjailed process. > BTW, when you say that gdb in jail fails, you do run both the target process and gdb itself in the same jail, right? Yep.
https://reviews.freebsd.org/D49682
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8ef6d8ad1a61a17cdaed2f5666d5a6904fd0737c commit 8ef6d8ad1a61a17cdaed2f5666d5a6904fd0737c Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2025-04-06 16:57:01 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2025-04-06 22:13:30 +0000 jails: delegate checking PRIV_PROC_MEM_WRITE to priv_check_cred() PR: 285811 Fixes: 4a5fa1086184f7450f63d4a8e403b16f40a78fce Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D49682 sys/kern/kern_jail.c | 5 +++++ 1 file changed, 5 insertions(+)
Yep, it worked for me too. Thanks!