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 > https://patchwork.kernel.org/patch/2468351/ > (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(-) <formletter> 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. </formletter> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html