Re: [PATCH 1/2] Fix perf LBR filtering
From: Greg KH
Date: Wed Apr 24 2013 - 19:24:25 EST
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> The perf LBR code has special code to filter specific
> instructions in software.
> The LBR logs any instruction address, even if IP just faulted.
> This means user space can control any address by just branching
> to a bad address.
> On a modern Intel system the only software filtering needed
> is to include SYSCALL/RETs in PERF_SAMPLE_BRANCH_ANY_CALL/RETURN.
> The hardware call filter only handles short calls, but syscall
> is a far call. So it enables far call logging too, but removes
> any other far calls (like interrupts) by looking at the instruction.
> On older systems some additional software filtering is done too,
> to work a problem that CALLs can be only logged together with
> indirect jumps.
> It currently assumes that any address that looks like a kernel
> address can be safely referenced.
> But that is dangerous if can be controlled by the user:
> - It can be used to crash the kernel
> - It allows to probe any physical address for a small set of values
> (valid call op codes) which is an information leak.
> - It may point to a side effect on read MMIO region
> So we cannot reference kernel addresses safely.
> Possible options:
> I) Disable FAR calls for ANY_CALL/RETURNS.
> This just means syscalls are not logged
> as calls. This also lowers the overhead of call logging.
> This changes semantics slightly.
> This is reasonable on Sandy Bridge and later, but would
> cause additional problems on Nehalem and Westmere with
> their additional filters.
> II) Simple disable any filtering for kernel space.
> This means interrupts in kernel space are reported as calls
> and on Nehalem/Westmere some indirect jumps are reported
> as calls too
> III) Enumerate all the kernel entry points and check.
> Any bad call must have a kernel entry point as to.
> This seemed to fragile to maintain.
> IV) Enumerate all kernel code and check for these ranges.
> Quite complicated, especially with the new kernel code JITs.
> Would also allow to probe for kernel code (defeating randomized kernel)
> This patch implements II: Simply disable software filtering for
> any kernel address, which seemed the best.
> (I) would be also an option and was earlier implemented in
> (however this patch still leaves Nehalem/Westmere/Atom open to the problem)
> (III) and (IV) appear too complicated and risky.
> Should be applied to applicable stable branches too. The problem
> goes back a long time.
> Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> arch/x86/kernel/cpu/perf_event_intel_lbr.c | 18 +++++++++++++++---
> 1 files changed, 15 insertions(+), 3 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/