linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: James Clark <james.clark@arm.com>
Cc: Leo Yan <leo.yan@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	James Morse <james.morse@arm.com>, Marc Zyngier <maz@kernel.org>,
	Joey Gouly <joey.gouly@arm.com>,
	Peter Collingbourne <pcc@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Stephane Eranian <eranian@google.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFCv1 1/4] arm64: Use static key for tracing PID in CONTEXTIDR
Date: Thu, 21 Oct 2021 08:47:30 -0700	[thread overview]
Message-ID: <202110210846.8A7B9F684@keescook> (raw)
In-Reply-To: <53962765-53b9-dfdc-a5b2-a3133a924c12@arm.com>

On Thu, Oct 21, 2021 at 03:33:01PM +0100, James Clark wrote:
> 
> 
> On 21/10/2021 14:45, Leo Yan wrote:
> > The kernel provides CONFIG_PID_IN_CONTEXTIDR for tracing PID into system
> > register CONTEXTIDR; we need to statically enable this configuration
> > when build kernel image to use this feature.
> > 
> > On the other hand, hardware tracing modules (e.g. Arm CoreSight, SPE,
> > etc) rely on this feature to provide context info in their tracing data.
> > If kernel has not enabled configuration CONFIG_PID_IN_CONTEXTIDR, then
> > tracing modules have no chance to capture PID related info.
> > 
> > This patch introduces static key for tracing PID in CONTEXTIDR, it
> > provides a possibility for device driver to dynamically enable and
> > disable tracing PID into CONTEXTIDR as needed.
> > 
> > As the first step, the kernel increases the static key if
> > CONFIG_PID_IN_CONTEXTIDR is enabled when booting kernel, in this case
> > kernel will always trace PID into CONTEXTIDR at the runtime.  This means
> > before and after applying this patch, the semantics for
> > CONFIG_PID_IN_CONTEXTIDR are consistent.
> > 
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> >  arch/arm64/include/asm/mmu_context.h |  4 +++-
> >  arch/arm64/kernel/process.c          | 11 +++++++++++
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> > index f4ba93d4ffeb..e1f33616f83a 100644
> > --- a/arch/arm64/include/asm/mmu_context.h
> > +++ b/arch/arm64/include/asm/mmu_context.h
> > @@ -26,9 +26,11 @@
> >  
> >  extern bool rodata_full;
> >  
> > +DECLARE_STATIC_KEY_FALSE(contextidr_in_use);
> > +
> >  static inline void contextidr_thread_switch(struct task_struct *next)
> >  {
> > -	if (!IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR))
> > +	if (!static_branch_unlikely(&contextidr_in_use))
> >  		return;
> >  
> >  	write_sysreg(task_pid_nr(next), contextidr_el1);
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 40adb8cdbf5a..d744c0c7e4c4 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -61,6 +61,9 @@ unsigned long __stack_chk_guard __ro_after_init;
> >  EXPORT_SYMBOL(__stack_chk_guard);
> >  #endif
> >  
> > +DEFINE_STATIC_KEY_FALSE(contextidr_in_use);
> > +EXPORT_SYMBOL_GPL(contextidr_in_use);
> > +
> >  /*
> >   * Function pointers to optional machine specific functions
> >   */
> > @@ -721,3 +724,11 @@ int arch_elf_adjust_prot(int prot, const struct arch_elf_state *state,
> >  	return prot;
> >  }
> >  #endif
> > +
> > +static int __init contextidr_init(void)
> > +{
> > +	if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR))
> > +		static_branch_inc(&contextidr_in_use);
> > +	return 0;
> > +}
> > +early_initcall(contextidr_init);
> 
> Hi Leo,
> 
> Can you skip this early_initcall() part if you do something like this:
> 
>     DECLARE_STATIC_KEY_MAYBE(CONFIG_PID_IN_CONTEXTIDR, contextidr_in_use)
> 
> It seems like there is a way to conditionally initialise it to true.

I was going to suggest the same thing. :) With this change, it looks
good:

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

  parent reply	other threads:[~2021-10-21 15:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 13:45 [RFCv1 0/4] arm64: Use static key for PID in CONTEXTIDR Leo Yan
2021-10-21 13:45 ` [RFCv1 1/4] arm64: Use static key for tracing " Leo Yan
2021-10-21 14:33   ` James Clark
2021-10-21 14:37     ` Leo Yan
2021-10-21 15:47     ` Kees Cook [this message]
2021-10-21 13:45 ` [RFCv1 2/4] arm64: entry: Always apply workaround for contextidr_el1 Leo Yan
2021-10-21 13:45 ` [RFCv1 3/4] arm64: Introduce functions for controlling PID tracing Leo Yan
2021-10-21 13:45 ` [RFCv1 4/4] perf: arm_spe: Dynamically switch PID tracing to contextidr Leo Yan
2021-10-21 15:49   ` Kees Cook
2021-10-22  2:09     ` Leo Yan
2021-11-01 15:28     ` Leo Yan
2021-12-03 16:22       ` Catalin Marinas
2021-12-05 13:51         ` Leo Yan
2021-12-07 11:48           ` Catalin Marinas
2021-12-07 12:31             ` Leo Yan
2021-12-08 17:29               ` Catalin Marinas
2021-12-10  7:59                 ` Leo Yan
2021-12-17  7:58                   ` Leo Yan
2022-01-17 18:48                   ` Catalin Marinas
2022-02-01 13:02                     ` Leo Yan
2021-10-22 15:36   ` James Clark
2021-10-22 15:40     ` James Clark
2021-10-22 16:23     ` James Clark
2021-10-24 10:25       ` Leo Yan

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=202110210846.8A7B9F684@keescook \
    --to=keescook@chromium.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=eranian@google.com \
    --cc=james.clark@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=pcc@google.com \
    --cc=peterz@infradead.org \
    --cc=samitolvanen@google.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).