bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Andrei Matei <andreimatei1@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH bpf-next v3 4/4] selftest/bpf: add test for var-offset stack access
Date: Mon, 8 Feb 2021 14:03:19 -0800	[thread overview]
Message-ID: <CAEf4BzaTVc61DTgOJk4JcWLMmvsGUAsx9SDHmLxm+3VYZaU=eQ@mail.gmail.com> (raw)
In-Reply-To: <20210207011027.676572-5-andreimatei1@gmail.com>

On Sat, Feb 6, 2021 at 5:11 PM Andrei Matei <andreimatei1@gmail.com> wrote:
>
> Add a higher-level test (C BPF program) for the new functionality -
> variable access stack reads and writes.
>
> Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
> ---
>  .../selftests/bpf/prog_tests/stack_var_off.c  | 36 ++++++++++++
>  .../selftests/bpf/progs/test_stack_var_off.c  | 56 +++++++++++++++++++
>  2 files changed, 92 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/stack_var_off.c
>  create mode 100644 tools/testing/selftests/bpf/progs/test_stack_var_off.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/stack_var_off.c b/tools/testing/selftests/bpf/prog_tests/stack_var_off.c
> new file mode 100644
> index 000000000000..52e00486b1aa
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/stack_var_off.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <test_progs.h>
> +#include "test_stack_var_off.skel.h"
> +
> +/* Test read and writes to the stack performed with offsets that are not
> + * statically known.
> + */
> +void test_stack_var_off(void)
> +{
> +       int duration = 0;
> +       struct test_stack_var_off *skel;
> +
> +       skel = test_stack_var_off__open_and_load();
> +       if (CHECK(!skel, "skel_open", "failed to open skeleton\n"))
> +               return;
> +       if (CHECK(!skel->bss, "check_bss", ".bss wasn't mmap()-ed\n"))
> +               goto cleanup;

can't happen, no need to check for !skel->bss


> +
> +       test_stack_var_off__attach(skel);

check errors (ASSERT_OK is good for this)

> +
> +       /* Give pid to bpf prog so it doesn't trigger for anyone else. */
> +       skel->bss->test_pid = getpid();
> +       /* Initialize the probe's input. */
> +       skel->bss->input[0] = 2;
> +       skel->bss->input[1] = 42;  /* This will be returned in probe_res. */
> +
> +       /* Trigger probe. */
> +       usleep(1);
> +
> +       if (CHECK(skel->bss->probe_res != 42, "check_probe_res",
> +                 "wrong probe res: %d\n", skel->bss->probe_res))
> +               goto cleanup;
> +
> +cleanup:
> +       test_stack_var_off__destroy(skel);
> +}
> diff --git a/tools/testing/selftests/bpf/progs/test_stack_var_off.c b/tools/testing/selftests/bpf/progs/test_stack_var_off.c
> new file mode 100644
> index 000000000000..bd9c8d86cd91
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/test_stack_var_off.c
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017 Facebook

2021 already :) Facebook isn't right here as well, probably?

> +
> +#include <linux/ptrace.h>

don't need this

> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>

and don't need this as well

> +
> +int probe_res;
> +
> +char input[4] = {};
> +int test_pid;
> +
> +SEC("tracepoint/syscalls/sys_enter_nanosleep")
> +int probe(void *ctx)
> +{
> +       /* This BPF program performs variable-offset reads and writes on a
> +        * stack-allocated buffer.
> +        */
> +       char stack_buf[16];
> +       unsigned long len;
> +       unsigned long last;
> +
> +       if (test_pid == 0)
> +               return 0;

can't happen, please remove

> +       if ((bpf_get_current_pid_tgid() >> 32) != test_pid)
> +               return 0;
> +
> +       /* Copy the input to the stack. */
> +       __builtin_memcpy(stack_buf, input, 4);
> +
> +       /* The first byte in the buffer indicates the length. */
> +       len = stack_buf[0] & 0xf;
> +       last = (len - 1) & 0xf;
> +
> +       /* Append something to the buffer. The offset where we write is not
> +        * statically known; this is a variable-offset stack write.
> +        */
> +       stack_buf[len] = 42;
> +
> +       /* Index into the buffer at an unknown offset. This is a
> +        * variable-offset stack read.
> +        *
> +        * Note that if it wasn't for the preceding variable-offset write, this
> +        * read would be rejected because the stack slot cannot be verified as
> +        * being initialized. With the preceding variable-offset write, the
> +        * stack slot still cannot be verified, but the write inhibits the
> +        * respective check on the reasoning that, if there was a
> +        * variable-offset to a higher-or-equal spot, we're probably reading
> +        * what we just wrote.
> +        */
> +       probe_res = stack_buf[last];
> +       return 0;
> +}
> +
> +char _license[] SEC("license") = "GPL";
> --
> 2.27.0
>

  reply	other threads:[~2021-02-08 22:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07  1:10 [PATCH bpf-next v3 0/4] allow variable-offset stack acces Andrei Matei
2021-02-07  1:10 ` [PATCH bpf-next v3 1/4] bpf: allow variable-offset stack access Andrei Matei
2021-02-07  1:10 ` [PATCH bpf-next v3 2/4] selftest/bpf: adjust expected verifier errors Andrei Matei
2021-02-07  1:10 ` [PATCH bpf-next v3 3/4] selftest/bpf: verifier tests for var-off access Andrei Matei
2021-02-07  1:10 ` [PATCH bpf-next v3 4/4] selftest/bpf: add test for var-offset stack access Andrei Matei
2021-02-08 22:03   ` Andrii Nakryiko [this message]
2021-02-10 19:14 ` [PATCH bpf-next v3 0/4] allow variable-offset stack acces Alexei Starovoitov

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='CAEf4BzaTVc61DTgOJk4JcWLMmvsGUAsx9SDHmLxm+3VYZaU=eQ@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andreimatei1@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.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).