lkml.org 
[lkml]   [2011]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 07/12] perf_events: add LBR software filter support for Intel X86
From
On Fri, Oct 7, 2011 at 12:42 PM, Peter Zijlstra <peterz@infradead.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@google.com> wrote:
>> > On Thu, Oct 6, 2011 at 5:32 PM, Andi Kleen <andi@firstfloor.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-10-07 12:51    [W:0.086 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site