1. 30 Jan, 2021 2 commits
    • Andrey Konovalov's avatar
      kasan: don't run tests in async mode · a546d2fd
      Andrey Konovalov authored and Vincenzo Frascino's avatar Vincenzo Frascino committed
      Asynchronous KASAN mode doesn't guarantee that a tag fault will be
      detected immediately and causes tests to fail. Forbid running them
      in asynchronous mode.
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
    • Vincenzo Frascino's avatar
      kasan: Add KASAN mode kernel parameter · 0fee07e2
      Vincenzo Frascino authored
      Architectures supported by KASAN_HW_TAGS can provide a sync or async mode
      of execution. On an MTE enabled arm64 hw for example this can be identified
      with the synchronous or asynchronous tagging mode of execution.
      In synchronous mode, an exception is triggered if a tag check fault occurs.
      In asynchronous mode, if a tag check fault occurs, the TFSR_EL1 register is
      updated asynchronously. The kernel checks the corresponding bits
      KASAN requires a specific kernel command line parameter to make use of this
      hw features.
      Add KASAN HW execution mode kernel command line parameter.
      Note: This patch adds the kasan.mode kernel parameter and the
      sync/async kernel command line options to enable the described features.
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Reviewed-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: Vincenzo Frascino's avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      [ Add a new var instead of exposing kasan_arg_mode to be consistent with
        flags for other command line arguments. ]
      Signed-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
  2. 28 Jan, 2021 11 commits
  3. 22 Dec, 2020 1 commit
  4. 02 Nov, 2020 1 commit
  5. 14 Oct, 2020 2 commits
  6. 07 Aug, 2020 4 commits
  7. 04 Jun, 2020 1 commit
    • Daniel Axtens's avatar
      kasan: stop tests being eliminated as dead code with FORTIFY_SOURCE · adb72ae1
      Daniel Axtens authored
      Patch series "Fix some incompatibilites between KASAN and FORTIFY_SOURCE", v4.
      3 KASAN self-tests fail on a kernel with both KASAN and FORTIFY_SOURCE:
      memchr, memcmp and strlen.
      When FORTIFY_SOURCE is on, a number of functions are replaced with
      fortified versions, which attempt to check the sizes of the operands.
      However, these functions often directly invoke __builtin_foo() once they
      have performed the fortify check.  The compiler can detect that the
      results of these functions are not used, and knows that they have no other
      side effects, and so can eliminate them as dead code.
      Why are only memchr, memcmp and strlen affected?
      Of string and string-like functions, kasan_test tests:
       * strchr  ->  not affected, no fortified version
       * strrchr ->  likewise
       * strcmp  ->  likewise
       * strncmp ->  likewise
       * strnlen ->  not affected, the fortify source implementation calls the
                     underlying strnlen implementation which is instrumented, not
                     a builtin
       * strlen  ->  affected, the fortify souce implementation calls a __builtin
                     version which the compiler can determine is dead.
       * memchr  ->  likewise
       * memcmp  ->  likewise
       * memset ->   not affected, the compiler knows that memset writes to its
      	       first argument and therefore is not dead.
      Why does this not affect the functions normally?
      In string.h, these functions are not marked as __pure, so the compiler
      cannot know that they do not have side effects.  If relevant functions are
      marked as __pure in string.h, we see the following warnings and the
      functions are elided:
      lib/test_kasan.c: In function `kasan_memchr':
      lib/test_kasan.c:606:2: warning: statement with no effect [-Wunused-value]
        memchr(ptr, '1', size + 1);
      lib/test_kasan.c: In function `kasan_memcmp':
      lib/test_kasan.c:622:2: warning: statement with no effect [-Wunused-value]
        memcmp(ptr, arr, size+1);
      lib/test_kasan.c: In function `kasan_strings':
      lib/test_kasan.c:645:2: warning: statement with no effect [-Wunused-value]
        strchr(ptr, '1');
      This annotation would make sense to add and could be added at any point,
      so the behaviour of test_kasan.c should change.
      The fix
      Make all the functions that are pure write their results to a global,
      which makes them live.  The strlen and memchr tests now pass.
      The memcmp test still fails to trigger, which is addressed in the next
      [dja@axtens.net: drop patch 3]
        Link: http://lkml.kernel.org/r/20200424145521.8203-2-dja@axtens.net
      Fixes: 0c96350a
       ("lib/test_kasan.c: add tests for several string/memory API functions")
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Tested-by: default avatarDavid Gow <davidgow@google.com>
      Reviewed-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Link: http://lkml.kernel.org/r/20200423154503.5103-1-dja@axtens.net
      Link: http://lkml.kernel.org/r/20200423154503.5103-2-dja@axtens.net
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 02 Apr, 2020 1 commit
  9. 31 Jan, 2020 1 commit
  10. 01 Dec, 2019 1 commit
  11. 24 Sep, 2019 1 commit
  12. 12 Jul, 2019 2 commits
  13. 19 Jun, 2019 1 commit
  14. 06 Mar, 2019 1 commit
  15. 26 Oct, 2018 1 commit
  16. 11 Apr, 2018 1 commit
  17. 07 Feb, 2018 4 commits
  18. 18 Nov, 2017 1 commit
  19. 01 Apr, 2017 1 commit
  20. 25 Feb, 2017 1 commit
    • Greg Thelen's avatar
      kasan: add memcg kmem_cache test · 0386bf38
      Greg Thelen authored
      Make a kasan test which uses a SLAB_ACCOUNT slab cache.  If the test is
      run within a non default memcg, then it uncovers the bug fixed by
      "kasan: drain quarantine of memcg slab objects"[1].
      If run without fix [1] it shows "Slab cache still has objects", and the
      kmem_cache structure is leaked.
      Here's an unpatched kernel test:
       $ dmesg -c > /dev/null
       $ mkdir /sys/fs/cgroup/memory/test
       $ echo $$ > /sys/fs/cgroup/memory/test/tasks
       $ modprobe test_kasan 2> /dev/null
       $ dmesg | grep -B1 still
       [ 123.456789] kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
       [ 124.456789] kmem_cache_destroy test_cache: Slab cache still has objects
      Kernels with fix [1] don't have the "Slab cache still has objects"
      warning or the underlying leak.
      The new test runs and passes in the default (root) memcg, though in the
      root memcg it won't uncover the problem fixed by [1].
      Link: http://lkml.kernel.org/r/1482257462-36948-2-git-send-email-gthelen@google.com
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Reviewed-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  21. 01 Dec, 2016 1 commit