linux-kernel - Re: [PATCH v5 12/20] x86: perf: intel

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: <87tx2t27yb.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Fri, 24 Oct 2014 11:22:20 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Robert Richter <rric@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>, kan.liang@...el.com,
	adrian.hunter@...el.com, acme@...radead.org
Subject: Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver

Peter Zijlstra <peterz@...radead.org> writes:

> On Mon, Oct 13, 2014 at 04:45:40PM +0300, Alexander Shishkin wrote:
>> +static int pt_config(struct perf_event *event)
>> +{
>> +	u64 reg;
>> +
>> +	reg = RTIT_CTL_TOPA | RTIT_CTL_BRANCH_EN;
>> +
>> +	if (!event->attr.exclude_kernel)
>> +		reg |= RTIT_CTL_OS;
>> +	if (!event->attr.exclude_user)
>> +		reg |= RTIT_CTL_USR;
>> +
>> +	reg |= (event->attr.config & PT_CONFIG_MASK);
>> +
>> +	/*
>> +	 * User can try to set bits in RTIT_CTL through PT_BYPASS_MASK,
>> +	 * that aren't supported by the hardware. Weather or not a
>> +	 * particular bitmask is supported by a cpu can't be determined
>> +	 * via cpuid or otherwise, so we have to rely on #GP handling
>> +	 * to catch these cases.
>> +	 */
>> +	return wrmsrl_safe(MSR_IA32_RTIT_CTL, reg);
>> +}
>
> Whether the weather is nice or not :-)
>
> But no, this cannot be, once we've accepted the event is must be
> programmable. Failing at the time of programming is vile; pmu::start()
> is a void return, failure is not an option there.

This is called from pmu::add(), which can fail. If this wrmsrl throws a
gp, pmu::add() will fail and we won't even get to pmu::start(). Of
course, the problem with such event faulting every time it is added is
still there. Maybe we can simply disable such events after the first
fault. Good news is, only a CAP_SYS_ADMIN can set arbitrary bits, so the
damage is limited.

> The fact that the hardware cannot even tell you the supported mask is
> further fail.
>
> IIRC I think Andi once suggested probing each of the 64 bits in that MSR
> to determine the supported mask at device init time.

The problem with this is that some bits go in groups, there'd be 2..3..4
bit fields encoding desired packet frequency, for example.

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/