Skip to content
  1. Jul 01, 2018
  2. Jun 30, 2018
    • Alexei Starovoitov's avatar
      Merge branch 'bpf-fixes' · ca09cb04
      Alexei Starovoitov authored
      
      
      Daniel Borkmann says:
      
      ====================
      This set contains three fixes that are mostly JIT and set_memory_*()
      related. The third in the series in particular fixes the syzkaller
      bugs that were still pending; aside from local reproduction & testing,
      also 'syz test' wasn't able to trigger them anymore. I've tested this
      series on x86_64, arm64 and s390x, and kbuild bot wasn't yelling either
      for the rest. For details, please see patches as usual, thanks!
      ====================
      
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      ca09cb04
    • Daniel Borkmann's avatar
      bpf: undo prog rejection on read-only lock failure · 85782e03
      Daniel Borkmann authored
      
      
      Partially undo commit 9facc336 ("bpf: reject any prog that failed
      read-only lock") since it caused a regression, that is, syzkaller was
      able to manage to cause a panic via fault injection deep in set_memory_ro()
      path by letting an allocation fail: In x86's __change_page_attr_set_clr()
      it was able to change the attributes of the primary mapping but not in
      the alias mapping via cpa_process_alias(), so the second, inner call
      to the __change_page_attr() via __change_page_attr_set_clr() had to split
      a larger page and failed in the alloc_pages() with the artifically triggered
      allocation error which is then propagated down to the call site.
      
      Thus, for set_memory_ro() this means that it returned with an error, but
      from debugging a probe_kernel_write() revealed EFAULT on that memory since
      the primary mapping succeeded to get changed. Therefore the subsequent
      hdr->locked = 0 reset triggered the panic as it was performed on read-only
      memory, so call-site assumptions were infact wrong to assume that it would
      either succeed /or/ not succeed at all since there's no such rollback in
      set_memory_*() calls from partial change of mappings, in other words, we're
      left in a state that is "half done". A later undo via set_memory_rw() is
      succeeding though due to matching permissions on that part (aka due to the
      try_preserve_large_page() succeeding). While reproducing locally with
      explicitly triggering this error, the initial splitting only happens on
      rare occasions and in real world it would additionally need oom conditions,
      but that said, it could partially fail. Therefore, it is definitely wrong
      to bail out on set_memory_ro() error and reject the program with the
      set_memory_*() semantics we have today. Shouldn't have gone the extra mile
      since no other user in tree today infact checks for any set_memory_*()
      errors, e.g. neither module_enable_ro() / module_disable_ro() for module
      RO/NX handling which is mostly default these days nor kprobes core with
      alloc_insn_page() / free_insn_page() as examples that could be invoked long
      after bootup and original 314beb9b ("x86: bpf_jit_comp: secure bpf jit
      against spraying attacks") did neither when it got first introduced to BPF
      so "improving" with bailing out was clearly not right when set_memory_*()
      cannot handle it today.
      
      Kees suggested that if set_memory_*() can fail, we should annotate it with
      __must_check, and all callers need to deal with it gracefully given those
      set_memory_*() markings aren't "advisory", but they're expected to actually
      do what they say. This might be an option worth to move forward in future
      but would at the same time require that set_memory_*() calls from supporting
      archs are guaranteed to be "atomic" in that they provide rollback if part
      of the range fails, once that happened, the transition from RW -> RO could
      be made more robust that way, while subsequent RO -> RW transition /must/
      continue guaranteeing to always succeed the undo part.
      
      Reported-by: default avatar <syzbot+a4eb8c7766952a1ca872@syzkaller.appspotmail.com>
      Reported-by: default avatar <syzbot+d866d1925855328eac3b@syzkaller.appspotmail.com>
      Fixes: 9facc336 ("bpf: reject any prog that failed read-only lock")
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      85782e03
    • Daniel Borkmann's avatar
      bpf, s390: fix potential memleak when later bpf_jit_prog fails · f605ce5e
      Daniel Borkmann authored
      
      
      If we would ever fail in the bpf_jit_prog() pass that writes the
      actual insns to the image after we got header via bpf_jit_binary_alloc()
      then we also need to make sure to free it through bpf_jit_binary_free()
      again when bailing out. Given we had prior bpf_jit_prog() passes to
      initially probe for clobbered registers, program size and to fill in
      addrs arrray for jump targets, this is more of a theoretical one,
      but at least make sure this doesn't break with future changes.
      
      Fixes: 05462310 ("s390/bpf: Add s390x eBPF JIT compiler backend")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      f605ce5e
    • Daniel Borkmann's avatar
      bpf, arm32: fix to use bpf_jit_binary_lock_ro api · 18d405af
      Daniel Borkmann authored
      
      
      Any eBPF JIT that where its underlying arch supports ARCH_HAS_SET_MEMORY
      would need to use bpf_jit_binary_{un,}lock_ro() pair instead of the
      set_memory_{ro,rw}() pair directly as otherwise changes to the former
      might break. arm32's eBPF conversion missed to change it, so fix this
      up here.
      
      Fixes: 39c13c20 ("arm: eBPF JIT compiler")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      18d405af
  3. Jun 29, 2018
  4. Jun 26, 2018
  5. Jun 25, 2018
    • Jakub Kicinski's avatar
      nfp: bpf: don't stop offload if replace failed · 68d676a0
      Jakub Kicinski authored
      
      
      Stopping offload completely if replace of program failed dates
      back to days of transparent offload.  Back then we wanted to
      silently fall back to the in-driver processing.  Today we mark
      programs for offload when they are loaded into the kernel, so
      the transparent offload is no longer a reality.
      
      Flags check in the driver will only allow replace of a driver
      program with another driver program or an offload program with
      another offload program.
      
      When driver program is replaced stopping offload is a no-op,
      because driver program isn't offloaded.  When replacing
      offloaded program if the offload fails the entire operation
      will fail all the way back to user space and we should continue
      using the old program.  IOW when replacing a driver program
      stopping offload is unnecessary and when replacing offloaded
      program - it's a bug, old program should continue to run.
      
      In practice this bug would mean that if offload operation was to
      fail (either due to FW communication error, kernel OOM or new
      program being offloaded but for a different netdev) driver
      would continue reporting that previous XDP program is offloaded
      but in fact no program will be loaded in hardware.  The failure
      is fairly unlikely (found by inspection, when working on the code)
      but it's unpleasant.
      
      Backport note: even though the bug was introduced in commit
      cafa92ac ("nfp: bpf: add support for XDP_FLAGS_HW_MODE"),
      this fix depends on commit 441a3303 ("net: xdp: don't allow
      device-bound programs in driver mode"), so this fix is sufficient
      only in v4.15 or newer.  Kernels v4.13.x and v4.14.x do need to
      stop offload if it was transparent/opportunistic, i.e. if
      XDP_FLAGS_HW_MODE was not set on running program.
      
      Fixes: cafa92ac ("nfp: bpf: add support for XDP_FLAGS_HW_MODE")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      68d676a0
  6. Jun 22, 2018
  7. Jun 21, 2018
  8. Jun 20, 2018