1. 16 11月, 2019 1 次提交
  2. 14 11月, 2019 1 次提交
  3. 11 11月, 2019 1 次提交
  4. 07 11月, 2019 1 次提交
  5. 03 11月, 2019 1 次提交
  6. 02 11月, 2019 2 次提交
    • M
      idr: Fix idr_get_next_ul race with idr_remove · 5a74ac4c
      Matthew Wilcox (Oracle) 提交于
      Commit 5c089fd0 ("idr: Fix idr_get_next race with idr_remove")
      neglected to fix idr_get_next_ul().  As far as I can tell, nobody's
      actually using this interface under the RCU read lock, but fix it now
      before anybody decides to use it.
      
      Fixes: 5c089fd0 ("idr: Fix idr_get_next race with idr_remove")
      Signed-off-by: NMatthew Wilcox (Oracle) <willy@infradead.org>
      5a74ac4c
    • D
      lib/list-test: add a test for the 'list' doubly linked list · ea2dd7c0
      David Gow 提交于
      Add a KUnit test for the kernel doubly linked list implementation in
      include/linux/list.h
      
      Each test case (list_test_x) is focused on testing the behaviour of the
      list function/macro 'x'. None of the tests pass invalid lists to these
      macros, and so should behave identically with DEBUG_LIST enabled and
      disabled.
      
      Note that, at present, it only tests the list_ types (not the
      singly-linked hlist_), and does not yet test all of the
      list_for_each_entry* macros (and some related things like
      list_prepare_entry).
      
      Ignoring checkpatch.pl spurious errors related to its handling of for_each
      and other list macros. checkpatch.pl expects anything with for_each in its
      name to be a loop and expects that the open brace is placed on the same
      line as for a for loop. In this case, test case naming scheme includes
      name of the macro it is testing, which results in the spurious errors.
      Commit message updated by Shuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NDavid Gow <davidgow@google.com>
      Reviewed-by: NBrendan Higgins <brendanhiggins@google.com>
      Tested-by: NBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      ea2dd7c0
  7. 23 10月, 2019 1 次提交
  8. 16 10月, 2019 1 次提交
  9. 15 10月, 2019 2 次提交
  10. 08 10月, 2019 1 次提交
  11. 07 10月, 2019 2 次提交
  12. 04 10月, 2019 2 次提交
  13. 01 10月, 2019 14 次提交
  14. 28 9月, 2019 1 次提交
  15. 27 9月, 2019 1 次提交
  16. 26 9月, 2019 8 次提交
    • A
      lib: untag user pointers in strn*_user · 903f433f
      Andrey Konovalov 提交于
      Patch series "arm64: untag user pointers passed to the kernel", v19.
      
      === Overview
      
      arm64 has a feature called Top Byte Ignore, which allows to embed pointer
      tags into the top byte of each pointer.  Userspace programs (such as
      HWASan, a memory debugging tool [1]) might use this feature and pass
      tagged user pointers to the kernel through syscalls or other interfaces.
      
      Right now the kernel is already able to handle user faults with tagged
      pointers, due to these patches:
      
      1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a
                   tagged pointer")
      2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged
      	      pointers")
      3. 276e9327 ("arm64: entry: improve data abort handling of tagged
      	      pointers")
      
      This patchset extends tagged pointer support to syscall arguments.
      
      As per the proposed ABI change [3], tagged pointers are only allowed to be
      passed to syscalls when they point to memory ranges obtained by anonymous
      mmap() or sbrk() (see the patchset [3] for more details).
      
      For non-memory syscalls this is done by untaging user pointers when the
      kernel performs pointer checking to find out whether the pointer comes
      from userspace (most notably in access_ok).  The untagging is done only
      when the pointer is being checked, the tag is preserved as the pointer
      makes its way through the kernel and stays tagged when the kernel
      dereferences the pointer when perfoming user memory accesses.
      
      The mmap and mremap (only new_addr) syscalls do not currently accept
      tagged addresses.  Architectures may interpret the tag as a background
      colour for the corresponding vma.
      
      Other memory syscalls (mprotect, etc.) don't do user memory accesses but
      rather deal with memory ranges, and untagged pointers are better suited to
      describe memory ranges internally.  Thus for memory syscalls we untag
      pointers completely when they enter the kernel.
      
      === Other approaches
      
      One of the alternative approaches to untagging that was considered is to
      completely strip the pointer tag as the pointer enters the kernel with
      some kind of a syscall wrapper, but that won't work with the countless
      number of different ioctl calls.  With this approach we would need a
      custom wrapper for each ioctl variation, which doesn't seem practical.
      
      An alternative approach to untagging pointers in memory syscalls prologues
      is to inspead allow tagged pointers to be passed to find_vma() (and other
      vma related functions) and untag them there.  Unfortunately, a lot of
      find_vma() callers then compare or subtract the returned vma start and end
      fields against the pointer that was being searched.  Thus this approach
      would still require changing all find_vma() callers.
      
      === Testing
      
      The following testing approaches has been taken to find potential issues
      with user pointer untagging:
      
      1. Static testing (with sparse [2] and separately with a custom static
         analyzer based on Clang) to track casts of __user pointers to integer
         types to find places where untagging needs to be done.
      
      2. Static testing with grep to find parts of the kernel that call
         find_vma() (and other similar functions) or directly compare against
         vm_start/vm_end fields of vma.
      
      3. Static testing with grep to find parts of the kernel that compare
         user pointers with TASK_SIZE or other similar consts and macros.
      
      4. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running
         a modified syzkaller version that passes tagged pointers to the kernel.
      
      Based on the results of the testing the requried patches have been added
      to the patchset.
      
      === Notes
      
      This patchset is meant to be merged together with "arm64 relaxed ABI" [3].
      
      This patchset is a prerequisite for ARM's memory tagging hardware feature
      support [4].
      
      This patchset has been merged into the Pixel 2 & 3 kernel trees and is
      now being used to enable testing of Pixel phones with HWASan.
      
      Thanks!
      
      [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
      
      [2] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060e0145f292
      
      [3] https://lkml.org/lkml/2019/6/12/745
      
      [4] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architecture-2018-developments-armv85a
      
      This patch (of 11)
      
      This patch is a part of a series that extends kernel ABI to allow to pass
      tagged user pointers (with the top byte set to something else other than
      0x00) as syscall arguments.
      
      strncpy_from_user and strnlen_user accept user addresses as arguments, and
      do not go through the same path as copy_from_user and others, so here we
      need to handle the case of tagged user addresses separately.
      
      Untag user pointers passed to these functions.
      
      Note, that this patch only temporarily untags the pointers to perform
      validity checks, but then uses them as is to perform user memory accesses.
      
      [andreyknvl@google.com: fix sparc4 build]
       Link: http://lkml.kernel.org/r/CAAeHK+yx4a-P0sDrXTUxMvO2H0CJZUFPffBrg_cU7oJOZyC7ew@mail.gmail.com
      Link: http://lkml.kernel.org/r/c5a78bcad3e94d6cda71fcaa60a423231ae71e4c.1563904656.git.andreyknvl@google.comSigned-off-by: NAndrey Konovalov <andreyknvl@google.com>
      Reviewed-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: NKhalid Aziz <khalid.aziz@oracle.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Eric Auger <eric.auger@redhat.com>
      Cc: Felix Kuehling <Felix.Kuehling@amd.com>
      Cc: Jens Wiklander <jens.wiklander@linaro.org>
      Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      903f433f
    • D
      lib/lzo/lzo1x_compress.c: fix alignment bug in lzo-rle · 09b35b41
      Dave Rodgman 提交于
      Fix an unaligned access which breaks on platforms where this is not
      permitted (e.g., Sparc).
      
      Link: http://lkml.kernel.org/r/20190912145502.35229-1-dave.rodgman@arm.comSigned-off-by: NDave Rodgman <dave.rodgman@arm.com>
      Cc: Dave Rodgman <dave.rodgman@arm.com>
      Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09b35b41
    • K
      bug: move WARN_ON() "cut here" into exception handler · a44f71a9
      Kees Cook 提交于
      The original clean up of "cut here" missed the WARN_ON() case (that does
      not have a printk message), which was fixed recently by adding an explicit
      printk of "cut here".  This had the downside of adding a printk() to every
      WARN_ON() caller, which reduces the utility of using an instruction
      exception to streamline the resulting code.  By making this a new BUGFLAG,
      all of these can be removed and "cut here" can be handled by the exception
      handler.
      
      This was very pronounced on PowerPC, but the effect can be seen on x86 as
      well.  The resulting text size of a defconfig build shows some small
      savings from this patch:
      
         text    data     bss     dec     hex filename
      19691167        5134320 1646664 26472151        193eed7 vmlinux.before
      19676362        5134260 1663048 26473670        193f4c6 vmlinux.after
      
      This change also opens the door for creating something like BUG_MSG(),
      where a custom printk() before issuing BUG(), without confusing the "cut
      here" line.
      
      Link: http://lkml.kernel.org/r/201908200943.601DD59DCE@keescook
      Fixes: 6b15f678 ("include/asm-generic/bug.h: fix "cut here" for WARN_ON for __WARN_TAINT architectures")
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reported-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Drew Davenport <ddavenport@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: YueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a44f71a9
    • M
      compiler: enable CONFIG_OPTIMIZE_INLINING forcibly · ac7c3e4f
      Masahiro Yamada 提交于
      Commit 9012d011 ("compiler: allow all arches to enable
      CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable this
      option.  A couple of build errors were reported by randconfig, but all of
      them have been ironed out.
      
      Towards the goal of removing CONFIG_OPTIMIZE_INLINING entirely (and it
      will simplify the 'inline' macro in compiler_types.h), this commit changes
      it to always-on option.  Going forward, the compiler will always be
      allowed to not inline functions marked 'inline'.
      
      This is not a problem for x86 since it has been long used by
      arch/x86/configs/{x86_64,i386}_defconfig.
      
      I am keeping the config option just in case any problem crops up for other
      architectures.
      
      The code clean-up will be done after confirming this is solid.
      
      Link: http://lkml.kernel.org/r/20190830034304.24259-1-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNick Desaulniers <ndesaulniers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ac7c3e4f
    • S
      lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds · 091cb099
      Stephen Boyd 提交于
      I'm seeing a bunch of debug prints from a user of print_hex_dump_bytes()
      in my kernel logs, but I don't have CONFIG_DYNAMIC_DEBUG enabled nor do I
      have DEBUG defined in my build.  The problem is that
      print_hex_dump_bytes() calls a wrapper function in lib/hexdump.c that
      calls print_hex_dump() with KERN_DEBUG level.  There are three cases to
      consider here
      
        1. CONFIG_DYNAMIC_DEBUG=y  --> call dynamic_hex_dum()
        2. CONFIG_DYNAMIC_DEBUG=n && DEBUG --> call print_hex_dump()
        3. CONFIG_DYNAMIC_DEBUG=n && !DEBUG --> stub it out
      
      Right now, that last case isn't detected and we still call
      print_hex_dump() from the stub wrapper.
      
      Let's make print_hex_dump_bytes() only call print_hex_dump_debug() so that
      it works properly in all cases.
      
      Case #1, print_hex_dump_debug() calls dynamic_hex_dump() and we get same
      behavior.  Case #2, print_hex_dump_debug() calls print_hex_dump() with
      KERN_DEBUG and we get the same behavior.  Case #3, print_hex_dump_debug()
      is a nop, changing behavior to what we want, i.e.  print nothing.
      
      Link: http://lkml.kernel.org/r/20190816235624.115280-1-swboyd@chromium.orgSigned-off-by: NStephen Boyd <swboyd@chromium.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      091cb099
    • V
      lib/extable.c: add missing prototypes · 8e72a7a4
      Valdis Kletnieks 提交于
      When building with W=1, a number of warnings are issued:
      
        CC      lib/extable.o
      lib/extable.c:63:6: warning: no previous prototype for 'sort_extable' [-Wmissing-prototypes]
         63 | void sort_extable(struct exception_table_entry *start,
            |      ^~~~~~~~~~~~
      lib/extable.c:75:6: warning: no previous prototype for 'trim_init_extable' [-Wmissing-prototypes]
         75 | void trim_init_extable(struct module *m)
            |      ^~~~~~~~~~~~~~~~~
      lib/extable.c:115:1: warning: no previous prototype for 'search_extable' [-Wmissing-prototypes]
        115 | search_extable(const struct exception_table_entry *base,
            | ^~~~~~~~~~~~~~
      
      Add the missing #include for the prototypes.
      
      Link: http://lkml.kernel.org/r/45574.1565235784@turing-policeSigned-off-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8e72a7a4
    • V
      lib/generic-radix-tree.c: make 2 functions static inline · e3f4faa4
      Valdis Kletnieks 提交于
      When building with W=1, we get some warnings:
      
      l  CC      lib/generic-radix-tree.o
      lib/generic-radix-tree.c:39:10: warning: no previous prototype for 'genradix_root_to_depth' [-Wmissing-prototypes]
         39 | unsigned genradix_root_to_depth(struct genradix_root *r)
            |          ^~~~~~~~~~~~~~~~~~~~~~
      lib/generic-radix-tree.c:44:23: warning: no previous prototype for 'genradix_root_to_node' [-Wmissing-prototypes]
         44 | struct genradix_node *genradix_root_to_node(struct genradix_root *r)
            |                       ^~~~~~~~~~~~~~~~~~~~~
      
      They're not used anywhere else, so make them static inline.
      
      Link: http://lkml.kernel.org/r/46923.1565236485@turing-policeSigned-off-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: Kent Overstreet <kent.overstreet@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e3f4faa4
    • K
      strscpy: reject buffer sizes larger than INT_MAX · 9a156466
      Kees Cook 提交于
      As already done for snprintf(), add a check in strscpy() for giant (i.e.
      likely negative and/or miscalculated) copy sizes, WARN, and error out.
      
      Link: http://lkml.kernel.org/r/201907260928.23DE35406@keescookSigned-off-by: NKees Cook <keescook@chromium.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Stephen Kitt <steve@sk2.org>
      Cc: Jann Horn <jannh@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a156466
反馈
建议
客服 返回
顶部