linux-kernel - Re: [PATCH v4 5/9] perf/amd/ibs: Don't allow freq mode event creation through ->config interface

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: <20250116210959.GB7232@noisy.programming.kicks-ass.net>
Date: Thu, 16 Jan 2025 22:09:59 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: mingo@...hat.com, namhyung@...nel.org, acme@...nel.org,
	eranian@...gle.com, irogers@...gle.com, kan.liang@...ux.intel.com,
	bp@...en8.de, x86@...nel.org, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, santosh.shukla@....com,
	ananth.narayan@....com, sandipan.das@....com
Subject: Re: [PATCH v4 5/9] perf/amd/ibs: Don't allow freq mode event
 creation through ->config interface

On Wed, Jan 15, 2025 at 05:44:34AM +0000, Ravi Bangoria wrote:
> Most perf_event_attr->config bits directly maps to IBS_{FETCH|OP}_CTL
> MSR. Since the sample period is programmed in these control registers,
> IBS PMU driver allows opening an IBS event by setting sample period
> value directly in perf_event_attr->config instead of using explicit
> perf_event_attr->sample_period interface.
> 
> However, this logic is not applicable for freq mode events since the
> semantics of control register fields are applicable only to fixed
> sample period whereas the freq mode event adjusts sample period after
> each and every sample. Currently, IBS driver (unintentionally) allows
> creating freq mode event via ->config interface, which is semantically
> wrong as well as detrimental because it can be misused to bypass
> perf_event_max_sample_rate checks.
> 
> Don't allow freq mode event creation through perf_event_attr->config
> interface.

So this is the case where:

perf_event_attr = {
	.freq = 1.
	.sample_freq = 0,
}

Right, where we would then take the period from the .config fields?

So that seems sensible enough; but does this not break existing users?
Or are we lucky enough to not have any users of this borken behaviour,
unlike the earlier broken behaviour that we now have to live with?


> Acked-by: Namhyung Kim <namhyung@...nel.org>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@....com>
> ---
>  arch/x86/events/amd/ibs.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
> index d9c84f1d530f..3e7ca1e2f25e 100644
> --- a/arch/x86/events/amd/ibs.c
> +++ b/arch/x86/events/amd/ibs.c
> @@ -315,6 +315,9 @@ static int perf_ibs_init(struct perf_event *event)
>  	} else {
>  		u64 period = 0;
>  
> +		if (event->attr.freq)
> +			return -EINVAL;
> +
>  		if (perf_ibs == &perf_ibs_op) {
>  			period = (config & IBS_OP_MAX_CNT) << 4;
>  			if (ibs_caps & IBS_CAPS_OPCNTEXT)
> -- 
> 2.43.0
>