linux-kernel - Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Nov 2013 16:54:59 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Sandeepa Prabhu <sandeepa.prabhu@...aro.org>
Cc:	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 14:39), Sandeepa Prabhu wrote:
> On 9 November 2013 14:40, Masami Hiramatsu
> <masami.hiramatsu.pt@...achi.com> wrote:
>> (2013/11/09 1:56), Will Deacon wrote:
>>> Hi Sandeepa,
>>>
>>> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>>>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>>>> for ARM64.
>>>
>>> I think this series will conflict quite heavily with the jump_label series,
>>> since they both introduce some common instruction manipulation code. On the
>>> debug side, there will also be conflicts with the kgdb series, so it might
>>> make sense for us to merge those two first, then you can rebase on a stable
>>> branch from us.
>>
>> [...]
>>
>>> 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.

On the other hand, kgdb is a special case and it should be,
because, IMHO, kgdb is a debugger, which means that the kgdb
has to be able to monitor whole the kernel from outside. So
kprobes should not change its behavior even if used with kgdb.

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/