linux-kernel - Re: [RFC] perf arm-spe: Track task context switch for cpu-mode events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210923142305.GA603008@leoy-ThinkPad-X240s>
Date:   Thu, 23 Sep 2021 22:23:05 +0800
From:   Leo Yan <leo.yan@...aro.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>,
        Stephane Eranian <eranian@...gle.com>,
        James Clark <james.clark@....com>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [RFC] perf arm-spe: Track task context switch for cpu-mode events

Hi Namhyung,

On Thu, Sep 16, 2021 at 02:01:21PM -0700, Namhyung Kim wrote:

[...]

> > Before we had discussion for enabling PID/TID for SPE samples; in the patch
> > set [1], patches 07, 08 set sample's pid/tid based on the Arm SPE context
> > packets.  To enable hardware tracing context ID, you also needs to enable
> > kernel config CONFIG_PID_IN_CONTEXTIDR.
> 
> Thanks for sharing this.
> 
> Yeah I also look at the context info but having a dependency on a kconfig
> looks limiting its functionality.  Also the kconfig says it has some overhead
> in the critical path (even if perf is not running, right?) - but not sure how
> much it can add.

Yes, after enabled config PID_IN_CONTEXTIDR, the kernel will always
write PID into the system register CONTEXTIDR during process context
switching.  Please see the flow:

  __switch_to() (arch/arm64/kernel/process.c)
    `-> contextidr_thread_switch(next)

> config PID_IN_CONTEXTIDR
>     bool "Write the current PID to the CONTEXTIDR register"
>     help
>       Enabling this option causes the kernel to write the current PID to
>       the CONTEXTIDR register, at the expense of some additional
>       instructions during context switch. Say Y here only if you are
>       planning to use hardware trace tools with this kernel.
> 
> >
> > At that time, there have a concern is the hardware context ID might
> > introduce confusion for non-root namespace.
> 
> Sounds like a problem.
> 
> >
> > We also considered to use PERF_RECORD_SWITCH_CPU_WIDE event for setting
> > pid/tid, the Intel PT implementation uses two things to set sample's
> > pid/tid: one is PERF_RECORD_SWITCH_CPU_WIDE event and another is to detect
> > the branch instruction is the symbol "__switch_to".  Since the trace
> > event PERF_RECORD_SWITCH_CPU_WIDE is coarse, so it only uses the new
> > pid/tid after the branch instruction for "__switch_to".  Arm SPE is
> > 'statistical', thus it cannot promise the trace data must contain the
> > branch instruction for "__switch_to", please see details [2].
> 
> I can see the need in the Intel PT as it needs to trace all (branch)
> instructions, but is it really needed for ARM SPE too?
> Maybe I am missing something, but it seems enough to have a
> coarse-grained context switch for sampling events..

The issue is that the coarse-grained context switch if introduces any
inaccuracy in the reported result.  If we can run some workloads and
prove the coarse-grained context switch doesn't cause significant bias,
it will be great and can give us the confidence for this approach.

Even enabling PERF_RECORD_SWITCH_CPU_WIDE event, I think it's good to
give priority for hardware PID tracing in Arm SPE trace data, if detects
the hardware PID tracing is enabled, then we can rollback to use
context packets from hardware trace data to set sample's PID.

How about you think for this?

Thanks,
Leo