linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tixy@linaro.org (Jon Medhurst (Tixy))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
Date: Mon, 27 Oct 2014 17:17:39 +0000	[thread overview]
Message-ID: <1414430259.1430.9.camel@linaro.org> (raw)
In-Reply-To: <544B7228.9050200@huawei.com>

On Sat, 2014-10-25 at 17:49 +0800, Wang Nan wrote:
[...]
> Anyway, I have done the separation. Please refer to:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297031.html
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297036.html
> 
> There is a big change in checker code in the first thread. Please help me review
> whether checker is acceptable.

I had started reviewing the previous version, I'll switch to the new
one.

I do prefer the new checker code better, and the only obvious
alternative I can think off would be to break down the decoding tables
into a lot more special cases of instruction forms, which I isn't as
scalable, so I don't like that idea.

However, I wonder if there is scope for the checker functions to
recursively call probes_decode_insn rather than decoding instructions in
C code. I don't know if that would be clearer and/or smaller or not.

Below is something I've just thrown together to get a feel of how it
could look. The decode table could possibly incorporate patterns to
cover instructions types that you split up in PATCH 1, e.g. so we might
not need separate PROBES_STORE and PROBES_STORE_EXTRA (depends if that
ends up making things simpler or not)...


int stack_use_none(probes_opcode_t insn,
		       struct arch_probes_insn *asi,
		       const struct decode_header *h)
{
	asi->stack_space = 0;
	return INSN_GOOD_NO_SLOT;
}

int stack_use_unknown(probes_opcode_t insn,
		       struct arch_probes_insn *asi,
		       const struct decode_header *h)
{
	asi->stack_space = -1;
	return INSN_GOOD_NO_SLOT;
}

int stack_use_imm_x0x(probes_opcode_t insn,
		       struct arch_probes_insn *asi,
		       const struct decode_header *h)
{
	asi->stack_space = ((insn & 0xf00) >> 4) + (insn & 0xf);
	return INSN_GOOD_NO_SLOT;
}

int stack_use_imm_xxx(probes_opcode_t insn,
		       struct arch_probes_insn *asi,
		       const struct decode_header *h)
{
	asi->stack_space = insn & 0xfff;
	return INSN_GOOD_NO_SLOT;
}

enum {
	STACK_USE_NONE,
	STACK_USE_UNKNOWN,
	STACK_USE_FIXED_X0X,
	STACK_USE_FIXED_XXX,
	NUM_STACK_USE_TYPES
};

static const union decode_action chk_stack_actions[] = {
	[STACK_USE_NONE] = {.handler = stack_use_none},
	[STACK_USE_UNKNOWN] = {.handler = stack_use_unknown},
	[STACK_USE_FIXED_X0X] = {.handler = stack_use_imm_x0x}
	[STACK_USE_FIXED_XXX] = {.handler = stack_use_imm_xxx}
}

enum probes_insn __kprobes chk_stack_use_arm(probes_opcode_t insn,
		       struct arch_probes_insn *asi,
		       const struct decode_header *h)
{
	static const union decode_item table[] = {
		/* Register indexed addressing modes with SP as index register (!)*/
		DECODE_OR	(0x0040000d, 0x0000000d),
		/* Register indexed addressing modes with SP as base register */
		DECODE_CUSTOM	(0x004f0000, 0x000d0000, STACK_USE_UNKOWN,
							 REGS(0, 0, 0, 0, 0)),

		/* STR{,B} with immediate pre-indexed addressing mode with SP base address */
		DECODE_CUSTOM	(0x05cf0000, 0x054d0000, STACK_USE_FIXED_XXX,
							 REGS(0, 0, 0, 0, 0)),

		/* STR{H,D} with immediate pre-indexed addressing mode with SP base address */
		DECODE_CUSTOM	(0x05cf0000, 0x014d0000, STACK_USE_FIXED_X0X,
							 REGS(0, 0, 0, 0, 0)),

		... other rules here, possibly including ...
		... REGS values like 'NOSP' to reject certain forms ...

		/* Catch all remaining cases */
		DECODE_CUSTOM	(0, 0, STACK_USE_NONE, REGS(0, 0, 0, 0, 0))
	}

	return probes_decode_insn(insn, asi, table, false, false, chk_stack_actions, NULL);
}

And in the dubious case that anyone wants to copy any of the above, it's
Signed-off-by: Jon Medhurst <tixy@linaro.org>

-- 
Tixy

  reply	other threads:[~2014-10-27 17:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 11:31 [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32 Wang Nan
2014-10-22 11:31 ` [PATCH v6 1/7] ARM: kprobes: replace 'union decode_action' to 'struct decode_action' Wang Nan
2014-10-22 11:32 ` [PATCH v6 2/7] ARM: kprobes: seprates load and store actions Wang Nan
2014-10-22 11:32 ` [PATCH v6 3/7] ARM: kprobes: introduces checker Wang Nan
2014-10-22 11:32 ` [PATCH v6 4/7] ARM: kprobes: collects stack consumption for store instructions Wang Nan
2014-10-22 11:32 ` [PATCH v6 5/7] ARM: kprobes: disallow probing stack consuming instructions Wang Nan
2014-10-22 11:32 ` [PATCH v6 6/7] kprobes: copy ainsn after alloc aggr kprobe Wang Nan
2014-10-22 11:32 ` [PATCH v6 7/7] ARM: kprobes: enable OPTPROBES for ARM 32 Wang Nan
2014-10-24  0:52 ` [PATCH v6 0/7] " Masami Hiramatsu
2014-10-24  9:02   ` Jon Medhurst (Tixy)
2014-10-25  9:49     ` Wang Nan
2014-10-27 17:17       ` Jon Medhurst (Tixy) [this message]
2014-10-28 10:58         ` Jon Medhurst (Tixy)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1414430259.1430.9.camel@linaro.org \
    --to=tixy@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).