From: Atish Patra <atishp@atishpatra.org>
To: linux-perf-users@vger.kernel.org
Cc: "linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Will Deacon <will@kernel.org>,
Stephane Eranian <eranian@google.com>,
Andi Kleen <ak@linux.intel.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Beeman Strong <beeman@rivosinc.com>,
Atish Patra <atishp@rivosinc.com>,
Kan Liang <kan.liang@linux.intel.com>,
Anup Patel <apatel@ventanamicro.com>
Subject: Expected rdpmc behavior during context swtich and a RISC-V conundrum
Date: Thu, 5 Jan 2023 11:59:24 -0800 [thread overview]
Message-ID: <CAOnJCUKNFNRs6WkPNWV94BuLmT3KSPWK2FYCiD4PxPCxRs76PA@mail.gmail.com> (raw)
Hi All,
There was a recent uabi update[1] for RISC-V that allows the users to
read cycle and instruction count without any checks.
We tried to restrict that behavior to address security concerns
earlier but it resulted in breakage for some user space
applications[2].
Thus, previous behavior was restored where a user on RISC-V platforms
can directly read cycle or instruction count[3].
Comparison with other ISAs w.r.t user space access of counters:
ARM64
-- Enabled/Disabled via (/proc/sys/kernel/perf_user_access)
-- Only for task bound events configured via perf.
X86
--- rdpmc instruction
--- Enable/Disable via “/sys/devices/cpu/rdpmc”
-- Before v4.0
-- any process (even without active perf event) rdpmc
After v4.0
-- Default behavior changed to support only active events in a
process’s context.
-- Configured through perf similar to ARM64
-- Continue to maintain backward compatibility for unrestricted access
by writing 2 to “/sys/devices/cpu/rdpmc”
IMO, RISC-V should only enable user space access through perf similar
to ARM64 and x86 (post v4.0).
However, we do have to support the legacy behavior to avoid
application breakage.
As per my understanding a direct user space access can lead to the
following problems:
1) There is no context switch support, so counts from other contexts are exposed
2) If a perf user is allocated one of these counters, the counter
value will be written
Looking at the x86 code as it continues to allow the above behavior,
rdpmc_always_available_key is enabled in the above case. However,
during the context switch (cr4_update_pce_mm)
only dirty counters are cleared. It only prevents leakage from perf
task to rdpmc task.
How does the context switch of counters work for users who enable
unrestricted access by writing 2 to “/sys/devices/cpu/rdpmc” ?
Otherwise, rdpmc users likely get noise from other applications. Is
that expected ?
This can be a security concern also where a rogue rdpmc user
application can monitor other critical applications to initiate side
channel attack.
Am I missing something? Please correct my understanding of the x86
implementation if it is wrong.
[1] https://lore.kernel.org/lkml/20221201135110.3855965-1-conor.dooley@microchip.com/
[2] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/REWcwYnzsKE?pli=1
[3] https://lore.kernel.org/all/YxIzgYP3MujXdqwj@aurel32.net/T/
--
Regards,
Atish
next reply other threads:[~2023-01-05 19:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 19:59 Atish Patra [this message]
2023-01-06 12:02 ` Expected rdpmc behavior during context swtich and a RISC-V conundrum Mark Rutland
2023-01-09 9:06 ` Atish Patra
2023-01-09 15:26 ` Mark Rutland
2023-01-09 19:38 ` Atish Patra
2023-01-09 12:41 ` Peter Zijlstra
2023-01-09 15:31 ` Mark Rutland
2023-01-09 19:56 ` Atish Patra
2023-01-10 6:17 ` Anup Patel
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=CAOnJCUKNFNRs6WkPNWV94BuLmT3KSPWK2FYCiD4PxPCxRs76PA@mail.gmail.com \
--to=atishp@atishpatra.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--cc=beeman@rivosinc.com \
--cc=eranian@google.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--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).