Re: bin/58630: dtrace is "hit or miss", but mostly "miss"

[gnats-admin%netbsd.org@localhost]

The following reply was made to PR bin/58630; it has been noted by GNATS.

From: Havard Eidnes <he%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
Cc: netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/58630: dtrace is "hit or miss", but mostly "miss"
Date: Sat, 24 Aug 2024 13:07:54 +0200 (CEST)

 >  > 	What's even more strange is that this error is not
 >  > 	consistently observed among my different systems:
 >
 >  ```
 >  $ env DTRACE_DEBUG=1 dtrace -s ./probes.d -h -o probes.h
 >  libdtrace DEBUG: failed to open /dev/ksyms: Permission denied
 >  [...]
 >  dtrace: failed to compile script ./probes.d: "/usr/lib/dtrace/psinfo.d", line 46: syntax error near "u_int"
 >  $ ls -l /dev/ksyms
 >  cr--r-----  1 root  kmem  85, 0 Jan 31  2024 /dev/ksyms
 >  $ sudo chmod o+r /dev/ksyms
 >  $ dtrace -s ./probes.d -h -o probes.h && echo OK
 >  OK
 >  $
 >  ```
 >
 >  Is /dev/ksyms world-readable on the other systems [...]
 
 Bingo!
 
 >  [...], or is dtrace setuid there?
 
 Surely it should not be? (It isn't)
 
 
 Hm, OK, so this goes perhaps back to the method I use when
 updating my systems, and I thought that I mostly did it
 "according to one of the recommended procedures", which is:
 
 1) transfer all the sets (or build them from source) for the
    version you want to upgrade to
 2) extract the new kernel, install the kernel, reboot (after
    renaming the old running kernel for easy reversion in case of
    disaster)
 3) in a shell loop from /, extract all the sets you want
    installed (except etc and possibly xetc) with "tar xfzp".  I
    like using "progress" in this loop as well.
 4) run "etcupdate -s <etc set file>"
 5) run the postinstall command etcupdate suggests, and clear up
    any additional things which needs to be done manually
 
 If /dev/ksyms was initially in some version of MAKEDEV mode 440,
 but should now be 444, I would have expected postinstall to warn
 me about that, but it has not.
 
 So this may turn into a bug report about postinstall and not
 about dtrace, which I guess is an easier problem to deal with.
 
 (It's a tangential issue that etcupdate by default suggests to
 change files that are almost always an essential part of the
 configuration of the running system, such as /etc/group,
 /etc/master.passwd, /etc/rc.conf and /etc/hosts (and I'm sure
 there are more in this category...), so it's "a sharp knife" and
 requires full alertness when used...)
 
 Returning back to postinstall and MAKEDEV, specifically
 MAKEDEV.tmpl:
 
 ----------------------------
 revision 1.191
 date: 2018-07-21 09:46:56 +0200;  author: maxv;  state: Exp;  lines: +2 -2;  commitid: 4dw22L6uN8Y2AYKA;
 Create /dev/ksyms as "440 $g_kmem". This prevents unprivileged users from
 reading the kernel symbols. Discussed in January 2018 on tech-kern@,
 reported by maya@, tested by tih@.
 ----------------------------
 
 so this appears to have been done conciously, possibly as a
 "security measure".
 
 >  I wonder if something like this would do instead of reading from /dev/ksyms?
 >
 >  ```
 >  diff -urN a/src/external/cddl/osnet/dist/lib/libdtrace/common/dt_module.c b/src/external/cddl/osnet/dist/lib/libdtrace/common/dt_module.c
 >  --- a/src/external/cddl/osnet/dist/lib/libdtrace/common/dt_module.c	2024-04-02 02:28:51.360422339 +0000
 >  +++ b/src/external/cddl/osnet/dist/lib/libdtrace/common/dt_module.c	2024-08-24 05:23:22.497654556 +0000
 >  @@ -1186,7 +1186,14 @@
 >    	bool ismod;
 >  
 >    	if (strcmp("netbsd", name) == 0) {
 >  -		strlcpy(fname, _PATH_KSYMS, sizeof fname);
 >  +		char tmp[MAXPATHLEN];
 >  +		len = sizeof(tmp);
 >  +#if defined(__i386__) || defined(__x86_64__)
 >  +		if (sysctlbyname("machdep.booted_kernel", tmp, &len, NULL, 0) == 0) 
 >  +			snprintf(fname, sizeof fname, "%s%s", tmp[0] == '/' ? "" : "/", tmp);
 >  +		else
 >  +#endif
 >  +			strlcpy(fname, _PATH_KSYMS, sizeof fname);
 >    		ismod = false;
 >    	} else {
 >  
 >  ```
 
 That is probably a good idea, especially if we don't revert the
 setting of the file mode for /dev/ksyms.
 
 It was quite confusing that e.g. ctfdump could get at the types
 (I assume it's using the booted kernel, along the above pattern)
 but dtrace could not, don't these tools basically come from the
 same place?  Or was it just our customization / porting which was
 done inconsistently?
 
 Best regards,
 
 - Havard