bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matteo Croce <mcroce@linux.microsoft.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Deven Bowers <deven.desai@linux.microsoft.com>
Subject: Re: [PATCH bpf-next] bpf: allow loading instructions from a fd
Date: Thu, 16 Jul 2020 20:47:36 +0200	[thread overview]
Message-ID: <CAFnufp2_vwyCR95Z=Dkd9XXRO8CTQ5NZtNPdJL+1oPRurv-feQ@mail.gmail.com> (raw)
In-Reply-To: <20200714173154.i2wxhm4n4ob7sfpd@ast-mbp.dhcp.thefacebook.com>

On Tue, Jul 14, 2020 at 7:31 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Mon, Jul 13, 2020 at 03:05:11PM +0200, Matteo Croce wrote:
> > From: Matteo Croce <mcroce@microsoft.com>
> >
> > Allow to load the BPF instructons from a file descriptor,
> > other than a pointer.
> >
> > This is required by the Integrity Subsystem to validate the source of
> > the instructions.
> >
> > In bpf_attr replace 'insns', which is an u64, to a union containing also
> > the file descriptor as int.
> > A new BPF_F_LOAD_BY_FD flag tells bpf_prog_load() to load
> > the instructions from file descriptor and ignore the pointer.
> >
> > As BPF files usually are regular ELF files, start reading from the
> > current file position, so the userspace can skip the ELF header and jump
> > to the right section.
>
> That is not the case at all.
> Have you looked at amount of work libbpf is doing with elf file before
> raw instructions become suitable to be loaded by the kernel?

I see now what bpf_object__relocate() and all the *reloc* functions
do, so it can't be done this way, I see.

A malicious BPF file can be as bad as a malicious binary. Let's say I
want to assert code integrity for BPF files, what could be a viable
option?
Perhaps a signature in the object file as we do with modules?

Regards,
-- 
per aspera ad upstream

  reply	other threads:[~2020-07-16 18:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 13:05 [PATCH bpf-next] bpf: allow loading instructions from a fd Matteo Croce
2020-07-14 17:31 ` Alexei Starovoitov
2020-07-16 18:47   ` Matteo Croce [this message]
2020-07-20 20:33     ` 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='CAFnufp2_vwyCR95Z=Dkd9XXRO8CTQ5NZtNPdJL+1oPRurv-feQ@mail.gmail.com' \
    --to=mcroce@linux.microsoft.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=deven.desai@linux.microsoft.com \
    --cc=linux-kernel@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).