All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Alexander Potapenko <glider@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Kees Cook <keescook@chromium.org>, Michal Marek <mmarek@suse.com>
Subject: Re: [PATCHv2] kcov: reject open when kernel not instrumented
Date: Thu, 16 Jun 2016 11:09:37 +0100	[thread overview]
Message-ID: <57627AE1.9020102@arm.com> (raw)
In-Reply-To: <1466010285-2772-1-git-send-email-mark.rutland@arm.com>

Hi Mark,

On 15/06/16 18:04, Mark Rutland wrote:
> If the toolchain does not support -fsanitize-coverage=trace-pc, we blat
> this option from CFLAGS_KCOV, and build the kernel without
> instrumentation, even if CONFIG_KCOV was selected. However, we still
> build the rest of the kcov infrastructure, and expose a kcov file under
> debugfs. This can be confusing, as the kernel will appear to support
> kcov, yet will never manage to sample any trace PC values. While we do
> note this fact at build time, this may be missed, and a user may not
> have access to build logs.
> 
> This patch ensures that CC_HAVE_SANCOV_TRACE_PC is defined when the
> toolchain supports -fsanitize-coverage=trace-pc, and is not defined
> otherwise. When CC_HAVE_SANCOV_TRACE_PC is not defined, the kernel will
> return -ENOTSUPP if userspace attempts to open the kcov debugfs file,
> indicating that kcov functionality is unavailable.

> diff --git a/Makefile b/Makefile
> index 0f70de6..3785a63 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -369,7 +369,7 @@ LDFLAGS_MODULE  =
>  CFLAGS_KERNEL	=
>  AFLAGS_KERNEL	=
>  CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
> -CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
> +CFLAGS_KCOV	= -fsanitize-coverage=trace-pc -DCC_HAVE_SANCOV_TRACE_PC
>  
>  
>  # Use USERINCLUDE when you must reference the UAPI directories only.
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index a02f2dd..0a0b164 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -3,6 +3,7 @@
>  #define DISABLE_BRANCH_PROFILING
>  #include <linux/compiler.h>
>  #include <linux/types.h>
> +#include <linux/errno.h>
>  #include <linux/file.h>
>  #include <linux/fs.h>
>  #include <linux/mm.h>
> @@ -160,6 +161,14 @@ static int kcov_open(struct inode *inode, struct file *filep)
>  {
>  	struct kcov *kcov;
>  
> +#ifndef CC_HAVE_SANCOV_TRACE_PC

I don't think this will work as kernel/kcov.c is listed in the Makefile as:
> # Don't self-instrument.
> KCOV_INSTRUMENT_kcov.o := n


This will cause the build machinery in scripts/Makefile.lib to not give
kernel/kcov.c the CFLAGS_KCOV contents:
> ifeq ($(CONFIG_KCOV),y)
> _c_flags += $(if $(patsubst n%,, \
> 	$(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)y), \
> 	$(CFLAGS_KCOV))
> endif

... so kernel/kcov.c will never see anything in CFLAGS_KCOV ...


An alternative would be to add the flag to the compiler test that generates the
'not supported' warning, but it needs to go in another CFLAGS variable.
Something like:

-------------------%<-------------------
diff --git a/Makefile b/Makefile
@@ -687,6 +687,8 @@ ifdef CONFIG_KCOV
     $(warning Cannot use CONFIG_KCOV: \
              -fsanitize-coverage=trace-pc is not supported by compiler)
     CFLAGS_KCOV =
+  else
+    KBUILD_CFLAGS += -DCC_HAVE_SANCOV_TRACE_PC
   endif
 endif
-------------------%<-------------------


Thanks,

James

  parent reply	other threads:[~2016-06-16 10:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-15 17:04 [PATCHv2] kcov: reject open when kernel not instrumented Mark Rutland
2016-06-15 19:16 ` Dmitry Vyukov
2016-06-16 10:09 ` James Morse [this message]
2016-06-16 10:28   ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57627AE1.9020102@arm.com \
    --to=james.morse@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mmarek@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.