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:	Wed, 20 May 2015 17:39:47 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	David Long <dave.long@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Russell King <linux@....linux.org.uk>,
	"Jon Medhurst (Tixy)" <tixy@...aro.org>,
	Steve Capper <steve.capper@...aro.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Will Deacon <will.deacon@....com>,
	linux-kernel@...r.kernel.org,
	Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	sandeepa.s.prabhu@...il.com, William Cohen <wcohen@...hat.com>,
	davem@...emloft.net
Subject: Re: [PATCH v6 3/6] arm64: Kprobes with single stepping support

On Mon, Apr 20, 2015 at 04:19:44PM -0400, David Long wrote:
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
> 
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
> 
> A software breakpoint is placed at the probe address to trap the
> kernel execution into the kprobe handler.
> 
> ARM v8 supports enabling single stepping before the break exception
> return (ERET), with next PC in exception return address (ELR_EL1). The
> kprobe handler prepares an executable memory slot for out-of-line
> execution with a copy of the original instruction being probed, and
> enables single stepping. The PC is set to the out-of-line slot address
> before the ERET. With this scheme, the instruction is executed with the
> exact same register context except for the PC (and DAIF) registers.

I wonder whether it would be simpler to use another software breakpoint
after the out of line instruction copy. You won't run the instructions
that change the PC anyway.

Since an unconditional branch instruction within the kernel address
space can reach any point in the kernel (and modules), could we go a
step further and avoid the software breakpoint altogether, just generate
a branch instruction to the original location (after the software
breakpoint)?

As for simulating/emulating instructions, could we actually avoid it for
most of them where we can generate a similar instruction with the
corrected offset? If the out of line slot is somewhere within the kernel
data section, I think many of them can be re-encoded (e.g. branches).

-- 
Catalin
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ