public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: John Fastabend <john.fastabend@gmail.com>
Cc: Luca Boccassi <bluca@debian.org>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Matteo Croce <mcroce@linux.microsoft.com>,
	bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	keyrings@vger.kernel.org,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Lorenzo Bianconi <lorenzo@kernel.org>
Subject: Re: [PATCH bpf-next 0/3] bpf: add signature
Date: Mon, 6 Dec 2021 18:11:53 -0300	[thread overview]
Message-ID: <Ya58mWyqlVzgQc9F@kernel.org> (raw)
In-Reply-To: <61ae75487d445_c5bd20827@john.notmuch>

Em Mon, Dec 06, 2021 at 12:40:40PM -0800, John Fastabend escreveu:
> I'll just reiterate (I think you get it though) that simply signing
> enforcement doesn't mean now BPF is safe. Further these programs

I think this was clear from the get go, at most this would help with
fingerpointing :-) I.e. BPF signing is not about making things safer,
its just an attempt to know who messed up.

> have very high privileges and can do all sorts of things to the
> system. But, sure sig enforcement locks down one avenue of loading
> bogus program.
 
> > the capability of calling bpf(). Trying to define heuristics is also
> > not good enough for us - creative malicious actors have a tendency to
> > come up with ways to chain things that individually are allowed and
> > benign, but combined in a way that you just couldn't foresee. It would
 
> Sure, but I would argue some things can be very restrictive and
> generally useful. For example, never allow kernel memory read could be
> enforced from BPF side directly. Never allow pkt redirect, etc.

But this is something unrelated to BPF signing, right? Its something
desirable, I'd say this will be at some point required, i.e. one more
step in having BPF programs to be more like userspace apps, where you
can limit all sorts of things it can do, programmatically, a BPF ulimit,
hey, blimit?
 
- Arnaldo

  reply	other threads:[~2021-12-06 21:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 19:18 [PATCH bpf-next 0/3] bpf: add signature Matteo Croce
2021-12-03 19:18 ` [PATCH bpf-next 1/3] bpf: add signature to eBPF instructions Matteo Croce
2021-12-03 21:46   ` kernel test robot
2021-12-03 19:18 ` [PATCH bpf-next 2/3] bpf: add option to require BPF signature Matteo Croce
2021-12-03 19:18 ` [PATCH bpf-next 3/3] bpftool: add signature in skeleton Matteo Croce
2021-12-03 19:22 ` [PATCH bpf-next 0/3] bpf: add signature Alexei Starovoitov
2021-12-03 19:35   ` Matteo Croce
2021-12-03 19:37     ` Alexei Starovoitov
2021-12-03 22:06       ` Luca Boccassi
2021-12-03 22:20         ` Alexei Starovoitov
2021-12-04  0:42           ` Matteo Croce
2021-12-04  2:02             ` Alexei Starovoitov
2021-12-04  3:39               ` John Fastabend
2021-12-04 12:37                 ` Luca Boccassi
2021-12-06 20:40                   ` John Fastabend
2021-12-06 21:11                     ` Arnaldo Carvalho de Melo [this message]
2021-12-06 22:59                     ` Luca Boccassi
2021-12-08 16:25                       ` Luca Boccassi
2021-12-08 20:17                         ` John Fastabend
2021-12-09 13:40                           ` Luca Boccassi

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=Ya58mWyqlVzgQc9F@kernel.org \
    --to=acme@kernel.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bluca@debian.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hawk@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=keyrings@vger.kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=mcroce@linux.microsoft.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox