Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1546563

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

Show all headers | View raw

On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>>>
>>> We don't prevent ebpf programs being loaded based on the digest but
>>> just to uniquely identify loaded programs from user space and match up
>>> with their source.
>>
>> The commit log talks about using the hash to see if the program has
>> already been compiled and JITted.  If that's done, then a collision
>> will directly cause the kernel to malfunction.
>
> Andy, please read the code.
> we could have used jhash there just as well.
> Collisions are fine.

There's relevant in the code to read yet AFAICS.  The code exports it
via fdinfo, and userspace is expected to do something with it.  The
commit message says:

    When programs are pinned and retrieved by an ELF loader, the loader
    can check the program's digest through fdinfo and compare it against
    one that was generated over the ELF file's program section to see
    if the program needs to be reloaded.

I assume this means that a userspace component is expected to compare
the digest of a loaded program to a digest of a program it wants to
load and to use the result of the comparison to decide whether the
programs are the same.  If that's indeed the case (and it sure sounds
like it, and I fully expect CRIU to do very similar things when
support is added), then malicious collisions do matter.

It's also not quite clear to me why userspace needs to be able to
calculate the digest on its own.  A bpf(BPF_CALC_PROGRAM_DIGEST)
command that takes a BPF program as input and hashes it would seem to
serve the same purpose, and that would allow the kernel to key the
digest and change the algorithm down the road without breaking things.

Regardless, adding a new hash algorithm that is almost-but-not-quite
SHA-1 and making it a stable interface to userspace is not a good
thing.

--Andy

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use  SipHash in place of MD5) Andy Lutomirski <luto@amacapital.net> - 2016-12-22 17:10 +0100
  Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-22 17:30 +0100
    Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Andy Lutomirski <luto@amacapital.net> - 2016-12-22 18:00 +0100
  Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6]  random: use SipHash in place of MD5) Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-22 18:00 +0100
    Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Andy Lutomirski <luto@amacapital.net> - 2016-12-22 18:30 +0100
      Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6]  random: use SipHash in place of MD5) Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-22 19:00 +0100
      Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-12-22 20:40 +0100
        Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Andy Lutomirski <luto@kernel.org> - 2016-12-22 21:00 +0100
          Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-22 21:10 +0100
      Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Daniel Borkmann <daniel@iogearbox.net> - 2016-12-23 11:30 +0100
    Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-22 19:20 +0100
    Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Daniel Borkmann <daniel@iogearbox.net> - 2016-12-23 11:10 +0100
      Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6]  random: use SipHash in place of MD5) Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-23 12:00 +0100
        Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Daniel Borkmann <daniel@iogearbox.net> - 2016-12-23 13:10 +0100
          Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Andy Lutomirski <luto@amacapital.net> - 2016-12-23 17:30 +0100
            Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Andy Lutomirski <luto@amacapital.net> - 2016-12-23 17:50 +0100
              Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-23 19:20 +0100
                Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random:  use SipHash in place of MD5) "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-23 22:20 +0100

csiph-web