On Sat, Sep 09, 2017 at 04:31:16PM +0200, Paul Chaignon wrote:
> Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only
> access stack and packet memory. Allow these helpers to directly access map
> values by passing registers of type PTR_TO_MAP_VALUE.
>
> This change removes the need for an extra copy to the stack when using a
> map value to perform a second map lookup, as in the following:
>
> struct bpf_map_def SEC("maps") infobyreq = {
> .type = BPF_MAP_TYPE_HASHMAP,
> .key_size = sizeof(struct request *),
> .value_size = sizeof(struct info_t),
> .max_entries = 1024,
> };
> struct bpf_map_def SEC("maps") counts = {
> .type = BPF_MAP_TYPE_HASHMAP,
> .key_size = sizeof(struct info_t),
> .value_size = sizeof(u64),
> .max_entries = 1024,
> };
> SEC("kprobe/blk_account_io_start")
> int bpf_blk_account_io_start(struct pt_regs *ctx)
> {
> struct info_t *info = bpf_map_lookup_elem(&infobyreq, &ctx->di);
> u64 *count = bpf_map_lookup_elem(&counts, info);
> (*count)++;
> }
>
> Signed-off-by: Paul Chaignon <paul.chaig...@orange.com>
> ---
> Changes in v2:
> - Additional test cases for adjusted maps.
>
> kernel/bpf/verifier.c | 9 +++-
> tools/testing/selftests/bpf/test_verifier.c | 84
> +++++++++++++++++++++++++++++
> 2 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d690c7d..50e057d 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -1351,7 +1351,8 @@ static int check_func_arg(struct bpf_verifier_env *env,
> u32 regno,
> if (arg_type == ARG_PTR_TO_MAP_KEY ||
> arg_type == ARG_PTR_TO_MAP_VALUE) {
> expected_type = PTR_TO_STACK;
> - if (type != PTR_TO_PACKET && type != expected_type)
> + if (type != PTR_TO_PACKET && type != PTR_TO_MAP_VALUE &&
> + type != expected_type)
> goto err_type;
> } else if (arg_type == ARG_CONST_SIZE ||
> arg_type == ARG_CONST_SIZE_OR_ZERO) {
> @@ -1404,6 +1405,9 @@ static int check_func_arg(struct bpf_verifier_env *env,
> u32 regno,
> if (type == PTR_TO_PACKET)
> err = check_packet_access(env, regno, reg->off,
> meta->map_ptr->key_size);
> + else if (type == PTR_TO_MAP_VALUE)
> + err = check_map_access(env, regno, 0,
> + meta->map_ptr->key_size);
> else
> err = check_stack_boundary(env, regno,
> meta->map_ptr->key_size,
> @@ -1420,6 +1424,9 @@ static int check_func_arg(struct bpf_verifier_env *env,
> u32 regno,
> if (type == PTR_TO_PACKET)
> err = check_packet_access(env, regno, reg->off,
> meta->map_ptr->value_size);
> + else if (type == PTR_TO_MAP_VALUE)
> + err = check_map_access(env, regno, 0,
> + meta->map_ptr->key_size);
as pointed out earlier. above is a bug.
please add negative test cases to see it.
See below...
> else
> err = check_stack_boundary(env, regno,
> meta->map_ptr->value_size,
> diff --git a/tools/testing/selftests/bpf/test_verifier.c
> b/tools/testing/selftests/bpf/test_verifier.c
> index 8eb0995..4532066 100644
> --- a/tools/testing/selftests/bpf/test_verifier.c
> +++ b/tools/testing/selftests/bpf/test_verifier.c
> @@ -5052,6 +5052,90 @@ static struct bpf_test tests[] = {
> .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> },
> {
> + "map helper access to map",
> + .insns = {
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 4),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_0),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map1 = { 3, 8 },
> + .result = ACCEPT,
> + .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> + },
> + {
> + "map helper access to adjusted map (via const imm)",
> + .insns = {
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 5),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_0),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2,
> + offsetof(struct test_val, foo)),
there are few bugs here.
1. it adds 4 byte, so it should have been rejected as misaligned.
2. if you add 100 here, it will still pass.
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map1 = { 9 },
> + .fixup_map2 = { 3 },
> + .result = ACCEPT,
> + .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> + },
> + {
> + "map helper access to adjusted map (via const reg)",
> + .insns = {
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 6),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_0),
> + BPF_MOV64_IMM(BPF_REG_3,
> + offsetof(struct test_val, foo)),
> + BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_3),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map1 = { 10 },
> + .fixup_map2 = { 3 },
> + .result = ACCEPT,
> + .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> + },
> + {
> + "map helper access to adjusted map (via variable)",
> + .insns = {
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 7),
> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_0),
> + BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_0, 0),
> + BPF_JMP_IMM(BPF_JGT, BPF_REG_3,
> + offsetof(struct test_val, foo), 4),
> + BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_3),
> + BPF_LD_MAP_FD(BPF_REG_1, 0),
> + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem),
> + BPF_EXIT_INSN(),
> + },
> + .fixup_map1 = { 11 },
> + .fixup_map2 = { 3 },
> + .result = ACCEPT,
> + .prog_type = BPF_PROG_TYPE_TRACEPOINT,
> + },
> + {
> "map element value is preserved across register spilling",
> .insns = {
> BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> --
> 2.7.4
>
_______________________________________________
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
