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, 11 Nov 2013 19:51:52 +0900 From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> Cc: Sandeepa Prabhu <sandeepa.prabhu@...aro.org>, Will Deacon <will.deacon@....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: [PATCH RFC 2/6] arm64: Kprobes with single stepping support (2013/11/11 16:54), Masami Hiramatsu wrote: >>>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody >>>> places a hardware breakpoint on an instruction in the kernel for which >>>> kprobes has patched in a brk. We take the hardware breakpoint, disable the >>>> breakpoint and set up a single step before returning to the brk. The brk >>>> then traps, but we must take care not to disable single-step and/or unmask >>>> debug exceptions, because that will cause the hardware breakpoint code to >>>> re-arm its breakpoint before we've stepped off the brk instruction. >>> >>> Hmm, frankly to say, this kind of race issue is not seriously discussed >>> on x86 too, since kgdb is still a special tool (not used on the production >>> system). >>> I think under such situation kgdb operator must have full control of the >>> system, and he can (and has to) avoid such kind of race. >> Masami, >> >> Hmm I think in same lines, but not sure if we expect kprobes to be >> able to work fool-proof along with kgdb or hw breakpoints ? > > For hw breakpoint, yes, we finally get check each other to safely > use it even if one rejects the other one at some points(address). > Since the hw breakpoint is already open for normal user via perf, > we should do it. But the policy still needs to be discussed. OK, I've ensured that the hw_breakpoint (from perf) can work with kprobes (from ftrace) at the same address on x86. So if arm64 already support hw_breakpoint on perf, kprobes should work with it. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@...achi.com -- 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