On Fri, Jan 07, 2022 at 11:06:30AM +0000, Visa Hankala wrote:
> 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.
I agree, but the intent is replacing a debugging method with another
debugging method (hoping it is more useful). The messages showed here
are the same that the ones which would be shown on the console before
the diff.
And to see them you need to run a kernel with DEBUG_UNVEIL defined (in
kern/kern_unveil.c file).
--
Sebastien Marie
