linux-kernel - Re: [PATCH v6 3/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:	Fri, 22 May 2015 11:49:37 -0400
From:	William Cohen <wcohen@...hat.com>
To:	Catalin Marinas <catalin.marinas@....com>,
	David Long <dave.long@...aro.org>
CC:	"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>,
	sandeepa.s.prabhu@...il.com,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Russell King <linux@....linux.org.uk>, davem@...emloft.net,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 3/6] arm64: Kprobes with single stepping support

On 05/22/2015 07:00 AM, Catalin Marinas wrote:
> On Thu, May 21, 2015 at 12:44:45AM -0400, David Long wrote:
>> On 05/20/15 12:39, Catalin Marinas wrote:
>>> 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.
>>
>> We put quite a bit of work into making single-step work.  I don't see any
>> obvious advantage to trying to switch to a software breakpoint. Both are
>> debug exceptions but SS does leave open the possibility of maybe eventually
>> running some instructions that do change the PC.
> 
> I'm not trying to get this re-written, just as a potential workaround
> for the unexpected single-step error reported but I need to read some
> more before I understand it properly (and I can see patches already for
> fixing this).
> 
>>> 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)?
>>
>> Wouldn't a branch instruction have to make use of a register in order to
>> span the whole address space?  How could you do that and have all the
>> registers unmolested when you land back after the original probe point?  The
>> thing that really kills this though is the fact we need to be able to run
>> the pre and post functions before and *after* the XOL stepping.
> 
> A "b #imm" would be able to cover a wide range (+/-128MB), but, as you
> said, it doesn't help with the post function call.
> 
> Any plans to post an updated version with the "unexpected single-step
> error" fixed?
> 

Hi Catalin,

The only place this issue with the "unexpected single-step error" has been observed is with the arm64 kretporbe handler code calling kprobed functions.  Experiments with kprobed functions being called in the kprobe handlers showed that situation was handled appropriately. 

There is proposed fix to address the issue with the trampoline, the attached patch.  This is modeled after the way that the x86 handles the kretprobe.  The trampoline directly save and restores the registers and uses a normal call to the kretprobe handler.  It operates similarly to what you are suggesting above, but just for the special case of the kretprobes.

-Will Cohen

View attachment "0001-Avoid-using-kprobe-in-the-arm64-kretprobe-trampoline.patch" of type "text/x-patch" (5996 bytes)