Re: rdcycle from userland with RISCV_PMU_SBI=y

From: Jan Wassenberg <janwas@google.com>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Anup Patel <anup@brainfault.org>,
	Mathieu Malaterre <malat@debian.org>,
	 Atish Patra <atishp@atishpatra.org>,
	linux-riscv@lists.infradead.org,
	 Aurelien Jarno <aurelien@aurel32.net>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	 Jan Newger <jannewger@google.com>
Subject: Re: rdcycle from userland with RISCV_PMU_SBI=y
Date: Mon, 5 Sep 2022 07:40:45 +0200	[thread overview]
Message-ID: <CAGRC-mhdmjcf=6gx8Rh5Rt8jvy5a2Rz+2g_UBRG_0fAG-D14uQ@mail.gmail.com> (raw)
In-Reply-To: <CAK9=C2W2tkmyX0x2A7iaNLGoRq4N7L0CwwNacmdtsw6OUdfODQ@mail.gmail.com>

> Currently, only "time" CSR is available to user-space and all other performance
> counters should be enabled (or accessed) using Linux perf syscalls.
Unfortunately that would seem to prevent precisely measuring very small code
regions (order of 10 cycles). What is the corresponding advantage/benefit?
As mentioned, there is no security gain from merely disabling rdcycle.

> In the future, someone can always propose a RISC-V ISA extension to obfuscate
> "time" CSR values visible to user-space but the "cycle" counter is
> purely a performance counter and accurately reflects cycles taken by the CPU.
Yes, this is why we use it. I'm curious why we think rdcycle is being
used to measure wall time?

About consistency: I understand there will be a time when rdcycle may
or may not be available on Linux depending on PMU.
But there is also bare metal, and other OSes. Is there a way for
userland to detect whether rdcycle will fault?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv