linux-kernel - Re: [PATCH v15 04/10] 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]

Message-ID: <20160720111600.GB25890@e104818-lin.cambridge.arm.com>
Date:	Wed, 20 Jul 2016 12:16:00 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Marc Zyngier <marc.zyngier@....com>
Cc:	David Long <dave.long@...aro.org>,
	Huang Shijie <shijie.huang@....com>,
	James Morse <james.morse@....com>,
	Pratyush Anand <panand@...hat.com>,
	Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
	Will Deacon <will.deacon@....com>,
	William Cohen <wcohen@...hat.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Steve Capper <steve.capper@...aro.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Li Bin <huawei.libin@...wei.com>,
	Jisheng Zhang <jszhang@...vell.com>,
	Mark Rutland <mark.rutland@....com>,
	Daniel Thompson <daniel.thompson@...aro.org>,
	Vladimir Murzin <Vladimir.Murzin@....com>,
	Petr Mladek <pmladek@...e.com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Robin Murphy <robin.murphy@....com>,
	Mark Brown <broonie@...nel.org>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Dave P Martin <Dave.Martin@....com>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	yalin wang <yalin.wang2010@...il.com>,
	Yang Shi <yang.shi@...aro.org>,
	Zi Shen Lim <zlim.lnx@...il.com>,
	John Blackwood <john.blackwood@...r.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alex Bennée <alex.bennee@...aro.org>,
	Adam Buchbinder <adam.buchbinder@...il.com>,
	Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On Wed, Jul 20, 2016 at 10:36:08AM +0100, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
> > +void __kprobes jprobe_return(void)
> > +{
> > +	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > +
> > +	/*
> > +	 * Jprobe handler return by entering break exception,
> > +	 * encoded same as kprobe, but with following conditions
> > +	 * -a magic number in x0 to identify from rest of other kprobes.
> > +	 * -restore stack addr to original saved pt_regs
> > +	 */
> > +	asm volatile ("ldr x0, [%0]\n\t"
> > +		      "mov sp, x0\n\t"
> > +		      ".globl jprobe_return_break\n\t"
> > +		      "jprobe_return_break:\n\t"
> > +		      "brk %1\n\t"
> > +		      :
> > +		      : "r"(&kcb->jprobe_saved_regs.sp),
> > +		      "I"(BRK64_ESR_KPROBES)
> > +		      : "memory");
> 
> A couple of remarks here:
> - the comment seems wrong, as you load the stack pointer in X0, nothing
> else, and seem to identify the jprobe by looking at the PC, not X0.
> - using explicit registers is really ugly. How about something like this
> instead:
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c89811d..823cf92 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
>  	 * -a magic number in x0 to identify from rest of other kprobes.
>  	 * -restore stack addr to original saved pt_regs
>  	 */
> -	asm volatile ("ldr x0, [%0]\n\t"
> -		      "mov sp, x0\n\t"
> +	asm volatile ("mov sp, %0\n\t"
>  		      ".globl jprobe_return_break\n\t"
>  		      "jprobe_return_break:\n\t"
>  		      "brk %1\n\t"
>  		      :
> -		      : "r"(&kcb->jprobe_saved_regs.sp),
> +		      : "r" (kcb->jprobe_saved_regs.sp),
>  		      "I"(BRK64_ESR_KPROBES)
>  		      : "memory");
>  }

The comment indeed doesn't make any sense. Is x0 useful at all?
Otherwise, Marc's fixup looks better.

> though hijacking SP in the middle of a C function still feels pretty fragile.

It may not be that bad if this function is never supposed to return.
However, I no longer hit jprobe_return() in my tests, it fails earlier
when it hits the function entry breakpoint. One difference from the
default Kprobes tests is that tcp_rcv_established() runs in interrupt
context on the IRQ stack. Maybe setjmp_pre_handler() doesn't set things
up properly.

Also, is setjmp_pre_handler() guaranteed to run in a non-preemptible
context? It uses MIN_STACK_SIZE macro which does a
raw_smp_processor_id().

-- 
Catalin