linux-kernel - Re: [PATCH 07/12] perf_events: add LBR software filter support for Intel X86

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]

Date:	Fri, 7 Oct 2011 12:49:44 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, acme@...hat.com, ming.m.lin@...el.com,
	robert.richter@....com, ravitillo@....gov
Subject: Re: [PATCH 07/12] perf_events: add LBR software filter support for
 Intel X86

On Fri, Oct 7, 2011 at 12:42 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, 2011-10-07 at 12:40 +0200, Stephane Eranian wrote:
>> On Fri, Oct 7, 2011 at 12:38 PM, Stephane Eranian <eranian@...gle.com> wrote:
>> > On Thu, Oct 6, 2011 at 5:32 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> >>> +     kernel_insn_init(&insn, kaddr);
>> >>> +     insn_get_opcode(&insn);
>> >>
>> >> This makes me uncomfortable. AFAIK that's the first use of the opcode
>> >> decoder being used directly for user space. It has a quite large attack
>> >> surface. Who says it cannot be exploited?
>> >>
>> > This is not new, it's already used for the PEBS fixups and that includes
>> > user level fixups, if possible.
>> >
>> > We are not executing the instruction here, just decoding it to filter it out
>> > from a buffer if necessary.
>> >
>> I would add that in this particular usage, the source address is coming
>> straight from LBR, it's not made up my SW. That means it corresponds
>> to a point where there was a control flow change. But it can certainly
>> be any x86 opcode (not just branches). LBR captures control flow changes
>> due to traps, faults, interrupts.
>
> You could still fuzz it after the cpu passed through and before the
> kernel reads the LBR. Its a narrow window, but quite feasible.
>
Yeah, depending on the depth of the LBR. But then what happens, you
decode an instruction that is not what was executed. In this scenario,
either that new instruction matches the user LBR filter or it does not.
In the latter situation, the LBR record is not copied into the sampling
buffer. In the former case, it is included and all you've done is generate
a false profile. I think this can happen even without being malicious but
just with self-modifying (JIT) code, though the depth of LBR is such that
this is very unlikely (it must happen in the last 16 branches before the
PMU interrupt).
--
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/