On Fri, Jan 07, 2022 at 10:54:54AM +0100, Sebastien Marie wrote:
> Debugging some code paths is complex: for example, unveil(2) code is
> involved inside VFS, and using DEBUG_UNVEIL means that the kernel is
> spamming printf() for all processes using unveil(2) (a lot of
> processes) instead of just the interested cases I want to follow.
>
> So I cooked the following diff to add a KTRLOG() facility to be able
> to replace printf()-like debugging with a more process-limited method.
>
> From ktrace(2) point of vue, it adds a new KTR_LOG record type, which
> is just a string. And it adds a function ktrlog(struct proc *, const char *,
> ...)
> which is a printf-like function.
>
> The following diff includes unveil(2) conversion from printf-debug
> message to KTRLOG-debug message.
>
>
> kdump output (LOG entries are new):
>
> 10388 a.out CALL unveil(0x149833ac,0x149833c3)
> 10388 a.out STRU flags="rx"
> 10388 a.out NAMI "/usr/bin/id"
> 10388 a.out LOG "added name id underneath vnode 0xd580c9a0"
> 10388 a.out LOG "unveil: added name id beneath restricted vnode
> 0xd580c9a0, uvcount 6"
> 10388 a.out RET unveil 0
> 10388 a.out CALL unveil(0,0)
> 10388 a.out RET unveil 0
> 10388 a.out CALL kbind(0xcf7e4724,12,0x35c420ed57689eb8)
> 10388 a.out RET kbind 0
> 10388 a.out CALL stat(0x149833ba,0xcf7e47a0)
> 10388 a.out NAMI "/usr/bin"
> 10388 a.out LOG "unveil: component directory match for vnode 0xd58537f8"
> 10388 a.out LOG "unveil: no match for vnode 0xd580c9a0"
> 10388 a.out LOG "unveil: matched \"bin\" underneath/at vnode 0xd58537f8"
> 10388 a.out STRU struct stat { dev=3, ino=77952, mode=drwxr-xr-x ,
> nlink=2, uid=0<"root">, gid=0<"wheel">, rdev=319024, atime=1641543393<"Jan 7
> 09:16:33 2022">.860011379, mtime=1641542018<"Jan 7 08:53:38
> 2022">.406865980, ctime=1641542018<"Jan 7 08:53:38 2022">.406865980,
> size=5632, blocks=12, blksize=16384, flags=0x0, gen=0x0 }
> 10388 a.out RET stat 0
>
> Additionnally, it permits to properly link the message string with the
> syscall involved and the process code path.
>
>
> Does it might be interesting for people ? or should I just keep it
> locally ?
If this gets added, more care is needed with the messages. For example,
kernel memory addresses should not be shown because they are privileged
information.
