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
| ||
|
Date: Mon, 18 Nov 2013 14:21:04 +0530 From: Sandeepa Prabhu <sandeepa.prabhu@...aro.org> To: Will Deacon <will.deacon@....com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "patches@...aro.org" <patches@...aro.org>, "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>, Catalin Marinas <Catalin.Marinas@....com>, "steve.capper@...aro.org" <steve.capper@...aro.org>, "nico@...aro.org" <nico@...aro.org>, "srikar@...ux.vnet.ibm.com" <srikar@...ux.vnet.ibm.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>, "dsaxena@...aro.org" <dsaxena@...aro.org>, "Vijaya.Kumar@...iumnetworks.com" <Vijaya.Kumar@...iumnetworks.com>, Jiang Liu <liuj97@...il.com>, "yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Ingo Molnar <mingo@...hat.com> Subject: Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support On 18 November 2013 12:25, Sandeepa Prabhu <sandeepa.prabhu@...aro.org> wrote: >>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko) >>> which places watchpoint for bothe read/write. >>> Atleast watchpt should have triggered for Read right? I also tried >>> with othe functions like do_fork, vfs_read etc but no hit. >> >> You'd need to place something for exec if you want to see anything on the >> instruction side. A read by the instruction fetcher does not trigger a read >> watchpoint on ARM. > Hmm, then watchpoint cannot not be placed on text address (instruction > fetch path) right? > (Sorry I did not check debug spec fully for watchpoint/hw breakpoints, > I should do that) > >> >>> >> 2. Placing text breakpoint (modified sample module with attr.bp_type >>> >> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null >>> >> /tmp/foo". This time, breakpoint hit but exception is re-cursing >>> >> infinitely! >>> > >>> > The problem here is that we expect the overflow handler to deal with the >>> > stepping (like GDB does via ptrace). If you don't register a handler, the >>> > kernel will do the step (like you would get if you used perf stat -e >>> > mem:0xNNNN:x). >>> [This test was done on upstream branch, without kprobes patches.] >>> Hmm, then this is expected with test breakpoint right? is this >>> handling to be done by perf and ptrace? >> >> perf stat doesn't register an overflow handler, so the hw_breakpoint >> backend will handle the step. ptrace registers a handler which sends a >> SIGTRAP to the debugger (e.g. gdb), which handles the step manually >> (probably using a PTRACE_SINGLESTEP request). >> >>> I did not see arm64 support in linux/tools/perf/, there are multiple >>> patches in mailing list though. Are you aware of any version of perf >>> that work with arm64? >> >> The perf tool should work fine on arm64 using mainline. Are you seeing >> problems? > Hmm basically perf is working and I can run tests now. Hi Will, Okay. I can see what you meant with respect to D-flag unmasking, on original patchset(v2). :) a. Placed a kprobe on vfs_read - works fine independently. b. Placed hw_breakpoint on vfs_read using perf (perf record -e mem:0xffffffc000134ba4:x -a -- sleep 10) and it works fine independently. c. Now, a+b, first placed kprobe on vfs_read and then ran perf record event on vfs_read (hw breakpoint). Now, seeing that kprobe single step is never complete/never disabled!, so debug exception would generate forever! (Continuously printing "Unexpected kernel single-step exception at EL1") kprobe pre_handler: p->addr = 0xffffffc000134ba4 reenter_dbg: test API invoked kprobe post_handler: p->addr = 0xffffffc000134ba4 fmp/fo^[[5Dreenter_dbg: test API invoked kprobe pre_handler: p->addr = 0xffffffc000134ba4 Unexpected kernel single-step exception at EL1 Unexpected kernel single-step exception at EL1 .... Once I change the location of D-flag manipulation (your suggestion) and run enough tests, I would come back with more details and inputs. Thanks, Sandeepa >> >> Will >> -- >> 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/ -- 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/
Powered by blists - more mailing lists