LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Krzesimir Nowak <krzesimir@kinvolk.io>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: bpf@vger.kernel.org, "Alban Crequy" <alban@kinvolk.io>,
	"Iago López Galeiras" <iago@kinvolk.io>,
	"Yonghong Song" <yhs@fb.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf v1] bpf: Fix undefined behavior in narrow load handling
Date: Fri, 10 May 2019 12:16:25 +0200	[thread overview]
Message-ID: <CAGGp+cFVt_i29Sr07ZJC5zdxTuuwcc02yVy5y03=DXSB6NEr0g@mail.gmail.com> (raw)
In-Reply-To: <46056c60-f106-e539-b614-498cb1e9e3d0@iogearbox.net>

On Thu, May 9, 2019 at 11:30 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 05/08/2019 06:08 PM, Krzesimir Nowak wrote:
> > Commit 31fd85816dbe ("bpf: permits narrower load from bpf program
> > context fields") made the verifier add AND instructions to clear the
> > unwanted bits with a mask when doing a narrow load. The mask is
> > computed with
> >
> > (1 << size * 8) - 1
> >
> > where "size" is the size of the narrow load. When doing a 4 byte load
> > of a an 8 byte field the verifier shifts the literal 1 by 32 places to
> > the left. This results in an overflow of a signed integer, which is an
> > undefined behavior. Typically the computed mask was zero, so the
> > result of the narrow load ended up being zero too.
> >
> > Cast the literal to long long to avoid overflows. Note that narrow
> > load of the 4 byte fields does not have the undefined behavior,
> > because the load size can only be either 1 or 2 bytes, so shifting 1
> > by 8 or 16 places will not overflow it. And reading 4 bytes would not
> > be a narrow load of a 4 bytes field.
> >
> > Reviewed-by: Alban Crequy <alban@kinvolk.io>
> > Reviewed-by: Iago López Galeiras <iago@kinvolk.io>
> > Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> > Cc: Yonghong Song <yhs@fb.com>
> > Signed-off-by: Krzesimir Nowak <krzesimir@kinvolk.io>
> > ---
> >  kernel/bpf/verifier.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 09d5d972c9ff..950fac024fbb 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -7296,7 +7296,7 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> >                                                                       insn->dst_reg,
> >                                                                       shift);
> >                               insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg,
> > -                                                             (1 << size * 8) - 1);
> > +                                                             (1ULL << size * 8) - 1);
> >                       }
>
> Makes sense, good catch & thanks for the fix!
>
> Could you also add a test case to test_verifier.c so we keep track of this?
>
> Thanks,
> Daniel

Hi,

A test for it is a bit tricky. I only found two 64bit fields that can
be loaded narrowly - `sample_period` and `addr` in `struct
bpf_perf_event_data`, so in theory I could have a test like follows:

{
    "32bit loads of a 64bit field (both least and most significant words)",
    .insns = {
    BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1, offsetof(struct
bpf_perf_event_data, addr)),
    BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1, offsetof(struct
bpf_perf_event_data, addr) + 4),
    BPF_MOV64_IMM(BPF_REG_0, 0),
    BPF_EXIT_INSN(),
    },
    .result = ACCEPT,
    .prog_type = BPF_PROG_TYPE_PERF_EVENT,
},

The test like this would check that the program is not rejected, but
it wasn't an issue. The test does not check if the verifier has
transformed the narrow reads properly. Ideally the BPF program would
do something like this:

/* let's assume that low and high variables get their values from narrow load */
__u64 low = (__u32)perf_event->addr;
__u64 high = (__u32)(perf_event->addr >> 32);
__u64 addr = low | (high << 32);

return addr != perf_event->addr;

But the test_verifier.c won't be able to run this, because
BPF_PROG_TYPE_PERF_EVENT programs are not supported by the
bpf_test_run_prog function.

Any hints how to proceed here?

Cheers,
Krzesimir
-- 
Kinvolk GmbH | Adalbertstr.6a, 10999 Berlin | tel: +491755589364
Geschäftsführer/Directors: Alban Crequy, Chris Kühl, Iago López Galeiras
Registergericht/Court of registration: Amtsgericht Charlottenburg
Registernummer/Registration number: HRB 171414 B
Ust-ID-Nummer/VAT ID number: DE302207000

  reply	other threads:[~2019-05-10 10:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 16:08 Krzesimir Nowak
2019-05-09 21:30 ` Daniel Borkmann
2019-05-10 10:16   ` Krzesimir Nowak [this message]
2019-05-13  0:01     ` 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='CAGGp+cFVt_i29Sr07ZJC5zdxTuuwcc02yVy5y03=DXSB6NEr0g@mail.gmail.com' \
    --to=krzesimir@kinvolk.io \
    --cc=alban@kinvolk.io \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=iago@kinvolk.io \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    --subject='Re: [PATCH bpf v1] bpf: Fix undefined behavior in narrow load handling' \
    /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

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).