linux-kernel - Re: [PATCH v2 10/13] kprobes: Remove uneeded kernel dependency on struct arch_specific

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, 13 Nov 2013 17:13:53 +0000
From:	"Jon Medhurst (Tixy)" <tixy@...aro.org>
To:	David Long <dave.long@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org, Rabin Vincent <rabin@....in>,
	Oleg Nesterov <oleg@...hat.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [PATCH v2 10/13] kprobes: Remove uneeded kernel dependency on
 struct arch_specific_insn

On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long" <dave.long@...aro.org>
> 
> Instead of depending on include/asm/kprobes.h to provide a dummy definition
> for struct arch_specific_insn, do so in include/linux/kprobes.h.

That change description doesn't quite seem to quite make sense to me.

Anyway, what we're trying to do with this patch is to allow us to use
arch_specific_insn for purposes additional to implementing kprobes. This
patch enables that but I'm wary that the kprobes code assumes that ainsn
is a struct arch_specific_insn, e.g. in linux/kernel/kprobes.c we have:

	memcpy(&p->ainsn, &ap->ainsn, sizeof(struct arch_specific_insn));

Now, that code isn't compiled when kprobes isn't configured, but it
seams to me to be safer if that was also changed to 

	memcpy(&p->ainsn, &ap->ainsn, sizeof(p->ainsn));

However, I also wonder if we should instead leave arch_specific_insn as
a kprobes specific structure and on ARM define it in terms of a new more
generic 'struct probe_insn'? The drawback with that is that we'd
probably end up with a struct just containing a single member which
seems a bit redundant:

struct arch_specific_insn {
	struct probe_insn pinsn;
};

Thought's anyone?

> 
> Signed-off-by: David A. Long <dave.long@...aro.org>
> ---
>  include/linux/kprobes.h | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index 925eaf2..4b5a74d 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -52,9 +52,6 @@
>  
>  #else /* CONFIG_KPROBES */
>  typedef int kprobe_opcode_t;
> -struct arch_specific_insn {
> -	int dummy;
> -};
>  #endif /* CONFIG_KPROBES */
>  
>  struct kprobe;
> @@ -110,7 +107,11 @@ struct kprobe {
>  	kprobe_opcode_t opcode;
>  
>  	/* copy of the original instruction */
> +#ifdef CONFIG_KPROBES
>  	struct arch_specific_insn ainsn;
> +#else
> +	int ainsn;
> +#endif
>  
>  	/*
>  	 * Indicates various status flags.

-- 
Tixy


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