17 Nov, 2016

1 commit

  • I made some invalid assumptions with BPF_AND and BPF_MOD that could result in
    invalid accesses to bpf map entries. Fix this up by doing a few things

    1) Kill BPF_MOD support. This doesn't actually get used by the compiler in real
    life and just adds extra complexity.

    2) Fix the logic for BPF_AND, don't allow AND of negative numbers and set the
    minimum value to 0 for positive AND's.

    3) Don't do operations on the ranges if they are set to the limits, as they are
    by definition undefined, and allowing arithmetic operations on those values
    could make them appear valid when they really aren't.

    This fixes the testcase provided by Jann as well as a few other theoretical
    problems.

    Reported-by: Jann Horn
    Signed-off-by: Josef Bacik
    Acked-by: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Josef Bacik
     

29 Sep, 2016

1 commit

  • Suppose you have a map array value that is something like this

    struct foo {
    unsigned iter;
    int array[SOME_CONSTANT];
    };

    You can easily insert this into an array, but you cannot modify the contents of
    foo->array[] after the fact. This is because we have no way to verify we won't
    go off the end of the array at verification time. This patch provides a start
    for this work. We accomplish this by keeping track of a minimum and maximum
    value a register could be while we're checking the code. Then at the time we
    try to do an access into a MAP_VALUE we verify that the maximum offset into that
    region is a valid access into that memory region. So in practice, code such as
    this

    unsigned index = 0;

    if (foo->iter >= SOME_CONSTANT)
    foo->iter = index;
    else
    index = foo->iter++;
    foo->array[index] = bar;

    would be allowed, as we can verify that index will always be between 0 and
    SOME_CONSTANT-1. If you wish to use signed values you'll have to have an extra
    check to make sure the index isn't less than 0, or do something like index %=
    SOME_CONSTANT.

    Signed-off-by: Josef Bacik
    Acked-by: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Josef Bacik
     

22 Sep, 2016

2 commits

  • Advanced JIT compilers and translators may want to use
    eBPF verifier as a base for parsers or to perform custom
    checks and validations.

    Add ability for external users to invoke the verifier
    and provide callbacks to be invoked for every intruction
    checked. For now only add most basic callback for
    per-instruction pre-interpretation checks is added. More
    advanced users may also like to have per-instruction post
    callback and state comparison callback.

    Signed-off-by: Jakub Kicinski
    Acked-by: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Jakub Kicinski
     
  • Move verifier's internal structures to a header file and
    prefix their names with bpf_ to avoid potential namespace
    conflicts. Those structures will soon be used by external
    analyzers.

    Signed-off-by: Jakub Kicinski
    Acked-by: Alexei Starovoitov
    Acked-by: Daniel Borkmann
    Signed-off-by: David S. Miller

    Jakub Kicinski