Date: Sat, 12 Jan 2019 12:13:43 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Andrew Turner <andrew@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r342962 - in head: sys/amd64/conf sys/arm64/conf sys/conf sys/kern sys/sys tests/sys/kern Message-ID: <201901122013.x0CKDhjA064204@slippy.cwsent.com> In-Reply-To: Message from Andrew Turner <andrew@FreeBSD.org> of "Sat, 12 Jan 2019 11:21:28 %2B0000." <201901121121.x0CBLSiv058912@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <201901121121.x0CBLSiv058912@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@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. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201901122013.x0CKDhjA064204>