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  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 11:09:42 +0530
From:	Sandeepa Prabhu <>
To:	Masami Hiramatsu <>
Cc:	Will Deacon <>,
	"" <>,
	"" <>,
	"" <>,
	Catalin Marinas <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	Jiang Liu <>
Subject: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support

On 9 November 2013 14:40, Masami Hiramatsu
<> 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.

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 ?

> Thank you,
> --
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists