All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@netronome.com>
To: alexei.starovoitov@gmail.com, daniel@iogearbox.net
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
	oss-drivers@netronome.com, davem@davemloft.net,
	paul.burton@mips.com, udknight@gmail.com, zlim.lnx@gmail.com,
	illusionist.neo@gmail.com, naveen.n.rao@linux.ibm.com,
	sandipan@linux.ibm.com, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, jakub.kicinski@netronome.com,
	Jiong Wang <jiong.wang@netronome.com>
Subject: [PATCH v8 bpf-next 02/16] bpf: verifier: mark patched-insn with sub-register zext flag
Date: Fri, 24 May 2019 12:35:12 +0100	[thread overview]
Message-ID: <1558697726-4058-3-git-send-email-jiong.wang@netronome.com> (raw)
In-Reply-To: <1558697726-4058-1-git-send-email-jiong.wang@netronome.com>

Patched insns do not go through generic verification, therefore doesn't has
zero extension information collected during insn walking.

We don't bother analyze them at the moment, for any sub-register def comes
from them, just conservatively mark it as needing zero extension.

Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
---
 kernel/bpf/verifier.c | 37 +++++++++++++++++++++++++++++++++----
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index f6b4c71..a6af316 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1269,6 +1269,24 @@ static bool is_reg64(struct bpf_verifier_env *env, struct bpf_insn *insn,
 	return true;
 }
 
+/* Return TRUE if INSN doesn't have explicit value define. */
+static bool insn_no_def(struct bpf_insn *insn)
+{
+	u8 class = BPF_CLASS(insn->code);
+
+	return (class == BPF_JMP || class == BPF_JMP32 ||
+		class == BPF_STX || class == BPF_ST);
+}
+
+/* Return TRUE if INSN has defined any 32-bit value explicitly. */
+static bool insn_has_def32(struct bpf_verifier_env *env, struct bpf_insn *insn)
+{
+	if (insn_no_def(insn))
+		return false;
+
+	return !is_reg64(env, insn, insn->dst_reg, NULL, DST_OP);
+}
+
 static void mark_insn_zext(struct bpf_verifier_env *env,
 			   struct bpf_reg_state *reg)
 {
@@ -7298,14 +7316,23 @@ static void convert_pseudo_ld_imm64(struct bpf_verifier_env *env)
  * insni[off, off + cnt).  Adjust corresponding insn_aux_data by copying
  * [0, off) and [off, end) to new locations, so the patched range stays zero
  */
-static int adjust_insn_aux_data(struct bpf_verifier_env *env, u32 prog_len,
-				u32 off, u32 cnt)
+static int adjust_insn_aux_data(struct bpf_verifier_env *env,
+				struct bpf_prog *new_prog, u32 off, u32 cnt)
 {
 	struct bpf_insn_aux_data *new_data, *old_data = env->insn_aux_data;
+	struct bpf_insn *insn = new_prog->insnsi;
+	u32 prog_len;
 	int i;
 
+	/* aux info at OFF always needs adjustment, no matter fast path
+	 * (cnt == 1) is taken or not. There is no guarantee INSN at OFF is the
+	 * original insn at old prog.
+	 */
+	old_data[off].zext_dst = insn_has_def32(env, insn + off + cnt - 1);
+
 	if (cnt == 1)
 		return 0;
+	prog_len = new_prog->len;
 	new_data = vzalloc(array_size(prog_len,
 				      sizeof(struct bpf_insn_aux_data)));
 	if (!new_data)
@@ -7313,8 +7340,10 @@ static int adjust_insn_aux_data(struct bpf_verifier_env *env, u32 prog_len,
 	memcpy(new_data, old_data, sizeof(struct bpf_insn_aux_data) * off);
 	memcpy(new_data + off + cnt - 1, old_data + off,
 	       sizeof(struct bpf_insn_aux_data) * (prog_len - off - cnt + 1));
-	for (i = off; i < off + cnt - 1; i++)
+	for (i = off; i < off + cnt - 1; i++) {
 		new_data[i].seen = true;
+		new_data[i].zext_dst = insn_has_def32(env, insn + i);
+	}
 	env->insn_aux_data = new_data;
 	vfree(old_data);
 	return 0;
@@ -7347,7 +7376,7 @@ static struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 of
 				env->insn_aux_data[off].orig_idx);
 		return NULL;
 	}
-	if (adjust_insn_aux_data(env, new_prog->len, off, len))
+	if (adjust_insn_aux_data(env, new_prog, off, len))
 		return NULL;
 	adjust_subprog_starts(env, off, len);
 	return new_prog;
-- 
2.7.4


  parent reply	other threads:[~2019-05-24 11:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 11:35 [PATCH v8 bpf-next 00/16] bpf: eliminate zero extensions for sub-register writes Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 01/16] bpf: verifier: mark verified-insn with sub-register zext flag Jiong Wang
2019-05-24 11:35 ` Jiong Wang [this message]
2019-05-24 11:35 ` [PATCH v8 bpf-next 03/16] bpf: introduce new mov32 variant for doing explicit zero extension Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 04/16] bpf: verifier: insert zero extension according to analysis result Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 05/16] bpf: introduce new bpf prog load flags "BPF_F_TEST_RND_HI32" Jiong Wang
2019-05-24 20:43   ` Alexei Starovoitov
2019-05-24 21:37     ` Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 06/16] bpf: verifier: randomize high 32-bit when BPF_F_TEST_RND_HI32 is set Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 07/16] libbpf: add "prog_flags" to bpf_program/bpf_prog_load_attr/bpf_load_program_attr Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 08/16] selftests: bpf: adjust several test_verifier helpers for insn insertion Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 09/16] selftests: bpf: enable hi32 randomization for all tests Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 10/16] arm: bpf: eliminate zero extension code-gen Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 11/16] powerpc: " Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 12/16] s390: " Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 13/16] sparc: " Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 14/16] x32: " Jiong Wang
2019-05-24 11:35 ` [PATCH v8 bpf-next 15/16] riscv: " Jiong Wang
2019-05-24 16:25   ` Björn Töpel
2019-05-24 16:36     ` Jiong Wang
2019-05-24 17:16       ` Björn Töpel
2019-05-24 11:35 ` [PATCH v8 bpf-next 16/16] nfp: " Jiong Wang

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=1558697726-4058-3-git-send-email-jiong.wang@netronome.com \
    --to=jiong.wang@netronome.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=illusionist.neo@gmail.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=naveen.n.rao@linux.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=paul.burton@mips.com \
    --cc=sandipan@linux.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=udknight@gmail.com \
    --cc=zlim.lnx@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.