From: Artem Savkov <asavkov@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Daniel Vacek <dvacek@redhat.com>, Jiri Olsa <olsajiri@gmail.com>,
Song Liu <song@kernel.org>
Subject: Re: [PATCH bpf-next 1/4] bpf: add BPF_F_DESTRUCTIVE flag for BPF_PROG_LOAD
Date: Fri, 22 Jul 2022 06:18:45 +0200 [thread overview]
Message-ID: <YtolJfvSGjSSwbc3@sparkplug.usersys.redhat.com> (raw)
In-Reply-To: <CAADnVQ+mt1iEsXUGBeL-dgXRoRwPxoz+G=aRcZTkhx2AA10R-A@mail.gmail.com>
On Thu, Jul 21, 2022 at 07:02:07AM -0700, Alexei Starovoitov wrote:
> On Wed, Jul 20, 2022 at 4:47 AM Artem Savkov <asavkov@redhat.com> wrote:
> >
> > +/* If BPF_F_DESTRUCTIVE is used in BPF_PROG_LOAD command, the loaded program
> > + * will be able to perform destructive operations such as calling bpf_panic()
> > + * helper.
> > + */
> > +#define BPF_F_DESTRUCTIVE (1U << 6)
>
> I don't understand what value this flag provides.
>
> bpf prog won't be using kexec accidentally.
> Requiring user space to also pass this flag seems pointless.
bpf program likely won't. But I think it is not uncommon for people to
run bpftrace scripts they fetched off the internet to run them without
fully reading the code. So the idea was to provide intermediate tools
like that with a common way to confirm user's intent without
implementing their own guards around dangerous calls.
If that is not a good enough of a reason to add the flag I can drop it.
--
Artem
next prev parent reply other threads:[~2022-07-22 4:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 11:46 [PATCH bpf-next 0/4] destructive bpf kfuncs (was: bpf_panic) Artem Savkov
2022-07-20 11:46 ` [PATCH bpf-next 1/4] bpf: add BPF_F_DESTRUCTIVE flag for BPF_PROG_LOAD Artem Savkov
2022-07-21 14:02 ` Alexei Starovoitov
2022-07-22 4:18 ` Artem Savkov [this message]
2022-07-22 4:32 ` Alexei Starovoitov
2022-07-25 9:27 ` Artem Savkov
2022-07-25 19:23 ` Daniel Xu
2022-07-20 11:46 ` [PATCH bpf-next 2/4] bpf: add destructive kfunc set Artem Savkov
2022-07-20 11:46 ` [PATCH bpf-next 3/4] selftests/bpf: add destructive kfunc tests Artem Savkov
2022-07-20 11:46 ` [PATCH bpf-next 4/4] bpf: export crash_kexec() as destructive kfunc Artem Savkov
2022-07-21 13:00 ` [PATCH bpf-next 0/4] destructive bpf kfuncs (was: bpf_panic) Daniel Borkmann
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=YtolJfvSGjSSwbc3@sparkplug.usersys.redhat.com \
--to=asavkov@redhat.com \
--cc=aarcange@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dvacek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=song@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).