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] [day] [month] [year] [list]

Message-ID: <337e17e7-b3db-44a1-9493-495b4c7313eb@amd.com>
Date: Fri, 17 Jan 2025 10:21:28 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Peter Zijlstra <peterz@...radead.org>
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,
 Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [PATCH v4 5/9] perf/amd/ibs: Don't allow freq mode event creation
 through ->config interface

On 17-Jan-25 2:39 AM, Peter Zijlstra wrote:
> 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?

I'm not aware of any existing tools using the ->config interface.

Also, I can't think of any advantage of the ->config interface over
stranded one. So, if anyone is using it and start seeing an error, they
can switch to { attr->freq=1, attr->sample_freq=xxx } and there is no
functional breakage.

Thanks for the review,
Ravi