svn commit: r342962 - in head: sys/amd64/conf sys/arm64/conf sys/conf sys/kern sys/sys tests/sys/kern

[Warner Losh]

On Sat, Jan 12, 2019 at 1:14 PM Cy Schubert <Cy.Schubert at cschubert.com>
wrote:

> In message <201901121121.x0CBLSiv058912 at repo.freebsd.org>, Andrew
> Turner writes
> :
> > Author: andrew
> > Date: Sat Jan 12 11:21:28 2019
> > New Revision: 342962
> > URL: https://svnweb.freebsd.org/changeset/base/342962
> >
> > Log:
> >   Add support for the Clang Coverage Sanitizer in the kernel (KCOV).
> >
> >   When building with KCOV enabled the compiler will insert function calls
> >   to probes allowing us to trace the execution of the kernel from
> userspace.
> >   These probes are on function entry (trace-pc) and on comparison
> operations
> >   (trace-cmp).
> >
> >   Userspace can enable the use of these probes on a single kernel thread
> with
> >   an ioctl interface. It can allocate space for the probe with
> KIOSETBUFSIZE,
> >   then mmap the allocated buffer and enable tracing with KIOENABLE, with
> the
> >   trace mode being passed in as the int argument. When complete
> KIODISABLE
> >   is used to disable tracing.
> >
> >   The first item in the buffer is the number of trace event that have
> >   happened. Userspace can write 0 to this to reset the tracing, and is
> >   expected to do so on first use.
> >
> >   The format of the buffer depends on the trace mode. When in PC tracing
> just
> >   the return address of the probe is stored. Under comparison tracing the
> >   comparison type, the two arguments, and the return address are traced.
> The
> >   former method uses on entry per trace event, while the later uses 4. As
> >   such they are incompatible so only a single mode may be enabled.
> >
> >   KCOV is expected to help fuzzing the kernel, and while in development
> has
> >   already found a number of issues. It is required for the syzkaller
> system
> >   call fuzzer [1]. Other kernel fuzzers could also make use of it, either
> >   with the current interface, or by extending it with new modes.
> >
> >   A man page is currently being worked on and is expected to be committed
> >   soon, however having the code in the kernel now is useful for other
> >   developers to use.
> >
> >   [1] https://github.com/google/syzkaller
> >
> >   Submitted by:       Mitchell Horne <mhorne063 at gmail.com> (Earlier
> version)
> >   Reviewed by:        kib
> >   Testing by: tuexen
> >   Sponsored by:       DARPA, AFRL
> >   Sponsored by:       The FreeBSD Foundation (Mitchell Horne)
> >   Differential Revision:      https://reviews.freebsd.org/D14599
> >
> > Added:
> >   head/sys/kern/kern_kcov.c   (contents, props changed)
> >   head/sys/sys/kcov.h   (contents, props changed)
> >   head/tests/sys/kern/kcov.c   (contents, props changed)
> > Modified:
> >   head/sys/amd64/conf/GENERIC
> >   head/sys/arm64/conf/GENERIC
> >   head/sys/conf/files
> >   head/sys/conf/kern.pre.mk
> >   head/sys/conf/options
> >   head/sys/kern/kern_thread.c
> >   head/sys/sys/proc.h
> >   head/tests/sys/kern/Makefile
> >
> [...]
> > Modified: head/sys/sys/proc.h
> >
> =============================================================================
> > =
> > --- head/sys/sys/proc.h       Sat Jan 12 11:14:59 2019        (r342961)
> > +++ head/sys/sys/proc.h       Sat Jan 12 11:21:28 2019        (r342962)
> > @@ -175,6 +175,7 @@ struct filecaps;
> >  struct filemon;
> >  struct kaioinfo;
> >  struct kaudit_record;
> > +struct kcov_info;
> >  struct kdtrace_proc;
> >  struct kdtrace_thread;
> >  struct mqueue_notifier;
> > @@ -300,6 +301,7 @@ struct thread {
> >       sbintime_t      td_sleeptimo;   /* (t) Sleep timeout. */
> >       int             td_rtcgen;      /* (s) rtc_generation of abs.
> sleep */
> >       size_t          td_vslock_sz;   /* (k) amount of vslock-ed space */
> > +     struct kcov_info *td_kcov_info; /* (*) Kernel code coverage data */
> >  #define      td_endzero td_sigmask
> >
> >  /* Copied during fork1() or create_thread(). */
> >
>
> This breaks 32-bit builds (see jenkins email to recent committers from
> this morning).
>
> Inserting this here and calculating offsets for 64-bit platforms
> without taking into consideration 32-bit is the reason why. Maybe we
> should consider deorbit of 32-bit platforms sooner than later.
>

I have the missing mips 64-bit stuff for mips32. i386 already has the
64-bit ops, I believe. Arm has them. Just powerpc 32-bit will be left w/o
them.

Warner