Re: CVS commit: src/sys
On 2020/11/05 23:07, Paul Goyette wrote: I will investigate. Thanks! Can you confirm that it works correctly if you have the built-in module? (ie, kernel with ``options COMPAT_NETBSD32'') Yes, it works fine. rin
Re: CVS commit: src/sys
I will investigate.
Can you confirm that it works correctly if you have the built-in
module? (ie, kernel with ``options COMPAT_NETBSD32'')
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module
`compat_netbsd32', error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
!DSPAM:5fa3f309175521945872603!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: CVS commit: src/sys
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules
modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is
#include
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.
Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
# uname -ap
NetBSD 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov 5 20:26:39 JST 2020
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[ 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_vm_default_addr' not found
[ 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_init' not found
[ 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sendsig' not found
[ 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_mcontext32_validate' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_setmcontext32' not found
[ 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_machdep_md_fini' not found
[ 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`startlwp32' not found
[ 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`cpu_getmcontext32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`machine32' not found
[ 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol
`netbsd32_sysarch' not found
[ 29.7318320] WARNING: module error: unable to affix module `compat_netbsd32',
error 8
modload: compat_netbsd32: Exec format error
This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.
Thanks,
rin
Re: CVS commit: src/sys/kern
On 2020/11/05 2:45, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.
The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.
Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.
If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.
If the module is not built-in, then a privileged user will need to
modload(8) the module.
Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine. Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main(). This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.
Please check to make sure that ``options PTRACE'' is included in
your kernel config.
Yes:
$ config -x netbsd.gdb | grep PTRACE
###> options PTRACE # Include ptrace(2) syscall
###> options PTRACE_HOOKS # Include ptrace hooks
The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():
https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184
184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd, ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd, ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }
Yes that would be a problem.
Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:
$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1] Abort trap (core dumped) gdb echo
Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.
I have some prior obligations, so I won't be able to look at this
until this evening.
Thanks for the detailed analysis.
Fixed. Thanks!
rin
