BPF List
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Peter Zijlstra <peterz@infradead.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 18:49:57 +0900	[thread overview]
Message-ID: <20220907184957.d41f085a998b2c7485353171@kernel.org> (raw)
In-Reply-To: <YxhQIBKzi+L0KDhc@hirez.programming.kicks-ass.net>

On Wed, 7 Sep 2022 10:02:40 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

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

Yes, sorry for confusion. CONFIG_RETHUNK/CONFIG_SLS are security
feature, and something like kgdb is debug feature, what I meant
here.

> 
> >  		 */
> > +		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.

Hmm, yeah, I thought that was rare case.

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

Yeah, this looks good to me. What I just need is to add expanding
queue buffer. (can we use xarray for this purpose?)

Thank you!


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  parent reply	other threads:[~2022-09-07  9:50 UTC|newest]

Thread overview: 26+ 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-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
2022-09-07  8:11     ` Peter Zijlstra
2022-09-07  9:49     ` Masami Hiramatsu [this message]
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=20220907184957.d41f085a998b2c7485353171@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=bp@suse.de \
    --cc=bpf@vger.kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.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