linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@kernel.org>,
	Suleiman Souhlal <suleiman@google.com>, bpf <bpf@vger.kernel.org>,
	linux-kernel@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	x86@kernel.org
Subject: Re: [PATCH 1/2] x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK
Date: Wed, 7 Sep 2022 10:02:40 +0200	[thread overview]
Message-ID: <YxhQIBKzi+L0KDhc@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <166251212072.632004.16078953024905883328.stgit@devnote2>

On Wed, Sep 07, 2022 at 09:55:21AM +0900, Masami Hiramatsu (Google) wrote:

>  static int can_probe(unsigned long paddr)
>  {
>  	kprobe_opcode_t buf[MAX_INSN_SIZE];
> +	unsigned long addr, offset = 0;
> +	struct insn insn;
>  
>  	if (!kallsyms_lookup_size_offset(paddr, NULL, &offset))
>  		return 0;
>  
> +	/* The first address must be instruction boundary. */
> +	if (!offset)
> +		return 1;
>  
> +	/* Decode instructions */
> +	for_each_insn(&insn, paddr - offset, paddr, buf) {
>  		/*
> +		 * CONFIG_RETHUNK or CONFIG_SLS or another debug feature
> +		 * may install INT3.

Note: they are not debug features.

>  		 */
> +		if (insn.opcode.bytes[0] == INT3_INSN_OPCODE) {
> +			/* Find the next non-INT3 instruction address */
> +			addr = skip_padding_int3((unsigned long)insn.kaddr);
> +			if (!addr)
> +				return 0;
> +			/*
> +			 * This can be a padding INT3 for CONFIG_RETHUNK or
> +			 * CONFIG_SLS. If a branch jumps to the address next
> +			 * to the INT3 sequence, this is just for padding,
> +			 * then we can continue decoding.
> +			 */
> +			for_each_insn(&insn, paddr - offset, addr, buf) {
> +				if (insn_get_branch_addr(&insn) == addr)
> +					goto found;
> +			}
>  
> +			/* This INT3 can not be decoded safely. */
>  			return 0;
> +found:
> +			/* Set loop cursor */
> +			insn.next_byte = (void *)addr;
> +			continue;
> +		}
>  	}
>  
> +	return ((unsigned long)insn.next_byte == paddr);
>  }

If I understand correctly, it'll fail on something like this:

foo:	insn
	insn
	insn
	jmp 2f
	int3

1:	insn
	insn
2:	insn
	jcc 1b

	ret
	int3

Which isn't weird code by any means. And soon to be generated by
compilers.


Maybe something like:

struct queue {
	int head, tail;
	unsigned long val[16]; /* insufficient; probably should allocate something */
};

void push(struct queue *q, unsigned long val)
{
	/* break loops, been here already */
	for (int i = 0; i < q->head; i++) {
		if (q->val[i] == val)
			return;
	}

	q->val[q->head++] = val;

	WARN_ON(q->head > ARRAY_SIZE(q->val)
}

unsigned long pop(struct queue *q)
{
	if (q->tail == q->head)
		return 0;

	return q->val[q->tail++];
}

bool dead_end_insn(struct instruction *insn)
{
	switch (insn->opcode.bytes[0]) {
	case INT3_INSN_OPCODE:
	case JMP8_INSN_OPCODE:
	case JMP32_INSN_OPCODE:
		return true; /* no arch execution after these */

	case 0xff:
		/* jmp *%reg; jmpf */
		if (modrm_reg == 4 || modrm_reg == 5)
			return true;
		break;

	default:
		break;
	}

	return false;
}



	struct queue q;

	start = paddr - offset;
	end = start + size;
	push(&q, paddr - offset);

	while (start = pop(&q)) {
		for_each_insn(&insn, start, end, buf) {
			if (insn.kaddr == paddr)
				return 1;

			target = insn_get_branch_addr(&insn);
			if (target)
				push(&q, target);

			if (dead_end_insn(&insn))
				break;
		}
	}



It's a bit of a pain, but I think it should cover things.

  parent reply	other threads:[~2022-09-07  8:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07  0:55 [PATCH 0/2] x86/kprobes: Fixes for CONFIG_RETHUNK Masami Hiramatsu (Google)
2022-09-07  0:55 ` [PATCH 1/2] x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK Masami Hiramatsu (Google)
2022-09-07  7:06   ` Peter Zijlstra
2022-09-07  9:01     ` [PATCH] objtool,x86: Teach decode about LOOP* instructions Peter Zijlstra
2022-09-07  9:06       ` David Laight
2022-09-07  9:40         ` Peter Zijlstra
2022-09-07 11:13           ` David Laight
2022-09-15 14:24       ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2022-09-07  9:12     ` [PATCH 1/2] x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK Masami Hiramatsu
2022-09-07  9:38       ` Peter Zijlstra
2022-09-07  9:53         ` Masami Hiramatsu
2022-09-07  8:02   ` Peter Zijlstra [this message]
2022-09-07  8:11     ` Peter Zijlstra
2022-09-07  9:49     ` Masami Hiramatsu
2022-09-07 10:19       ` Peter Zijlstra
2022-09-07 11:44         ` Peter Zijlstra
2022-09-07 13:05     ` Peter Zijlstra
2022-09-07 14:14       ` Masami Hiramatsu
2022-09-07 14:27         ` Peter Zijlstra
2022-09-07 15:22           ` Masami Hiramatsu
2022-09-07 12:56   ` Peter Zijlstra
2022-09-07 13:49     ` Masami Hiramatsu
2022-09-07 14:28       ` Peter Zijlstra
2022-09-07 12:59   ` Peter Zijlstra
2022-09-07 13:53     ` Masami Hiramatsu
2022-09-07  0:55 ` [PATCH 2/2] x86/kprobes: Fix optprobe optimization " Masami Hiramatsu (Google)
2022-09-07  6:52 ` [PATCH 0/2] x86/kprobes: Fixes for CONFIG_RETHUNK Peter Zijlstra

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=YxhQIBKzi+L0KDhc@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@suse.de \
    --cc=bpf@vger.kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=suleiman@google.com \
    --cc=x86@kernel.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).