1. 25 8月, 2021 3 次提交
  2. 03 8月, 2021 2 次提交
    • M
      arm64: kasan: mte: remove redundant mte_report_once logic · 76721503
      Mark Rutland 提交于
      We have special logic to suppress MTE tag check fault reporting, based
      on a global `mte_report_once` and `reported` variables. These can be
      used to suppress calling kasan_report() when taking a tag check fault,
      but do not prevent taking the fault in the first place, nor does they
      affect the way we disable tag checks upon taking a fault.
      
      The core KASAN code already defaults to reporting a single fault, and
      has a `multi_shot` control to permit reporting multiple faults. The only
      place we transiently alter `mte_report_once` is in lib/test_kasan.c,
      where we also the `multi_shot` state as the same time. Thus
      `mte_report_once` and `reported` are redundant, and can be removed.
      
      When a tag check fault is taken, tag checking will be disabled by
      `do_tag_recovery` and must be explicitly re-enabled if desired. The test
      code does this by calling kasan_enable_tagging_sync().
      
      This patch removes the redundant mte_report_once() logic and associated
      variables.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NAndrey Konovalov <andreyknvl@gmail.com>
      Tested-by: NAndrey Konovalov <andreyknvl@gmail.com>
      Link: https://lore.kernel.org/r/20210714143843.56537-4-mark.rutland@arm.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      76721503
    • M
      arm64: kasan: mte: use a constant kernel GCR_EL1 value · 82868247
      Mark Rutland 提交于
      When KASAN_HW_TAGS is selected, KASAN is enabled at boot time, and the
      hardware supports MTE, we'll initialize `kernel_gcr_excl` with a value
      dependent on KASAN_TAG_MAX. While the resulting value is a constant
      which depends on KASAN_TAG_MAX, we have to perform some runtime work to
      generate the value, and have to read the value from memory during the
      exception entry path. It would be better if we could generate this as a
      constant at compile-time, and use it as such directly.
      
      Early in boot within __cpu_setup(), we initialize GCR_EL1 to a safe
      value, and later override this with the value required by KASAN. If
      CONFIG_KASAN_HW_TAGS is not selected, or if KASAN is disabeld at boot
      time, the kernel will not use IRG instructions, and so the initial value
      of GCR_EL1 is does not matter to the kernel. Thus, we can instead have
      __cpu_setup() initialize GCR_EL1 to a value consistent with
      KASAN_TAG_MAX, and avoid the need to re-initialize it during hotplug and
      resume form suspend.
      
      This patch makes arem64 use a compile-time constant KERNEL_GCR_EL1
      value, which is compatible with KASAN_HW_TAGS when this is selected.
      This removes the need to re-initialize GCR_EL1 dynamically, and acts as
      an optimization to the entry assembly, which no longer needs to load
      this value from memory. The redundant initialization hooks are removed.
      
      In order to do this, KASAN_TAG_MAX needs to be visible outside of the
      core KASAN code. To do this, I've moved the KASAN_TAG_* values into
      <linux/kasan-tags.h>.
      
      There should be no functional change as a result of this patch.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Peter Collingbourne <pcc@google.com>
      Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NAndrey Konovalov <andreyknvl@gmail.com>
      Tested-by: NAndrey Konovalov <andreyknvl@gmail.com>
      Link: https://lore.kernel.org/r/20210714143843.56537-3-mark.rutland@arm.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      82868247
  3. 21 7月, 2021 1 次提交
  4. 09 7月, 2021 1 次提交
    • M
      set_memory: allow querying whether set_direct_map_*() is actually enabled · 6d47c23b
      Mike Rapoport 提交于
      On arm64, set_direct_map_*() functions may return 0 without actually
      changing the linear map.  This behaviour can be controlled using kernel
      parameters, so we need a way to determine at runtime whether calls to
      set_direct_map_invalid_noflush() and set_direct_map_default_noflush() have
      any effect.
      
      Extend set_memory API with can_set_direct_map() function that allows
      checking if calling set_direct_map_*() will actually change the page
      table, replace several occurrences of open coded checks in arm64 with the
      new function and provide a generic stub for architectures that always
      modify page tables upon calls to set_direct_map APIs.
      
      [arnd@arndb.de: arm64: kfence: fix header inclusion ]
      
      Link: https://lkml.kernel.org/r/20210518072034.31572-4-rppt@kernel.orgSigned-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Christopher Lameter <cl@linux.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Elena Reshetova <elena.reshetova@intel.com>
      Cc: Hagen Paul Pfeifer <hagen@jauu.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Bottomley <jejb@linux.ibm.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Palmer Dabbelt <palmerdabbelt@google.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tycho Andersen <tycho@tycho.ws>
      Cc: Will Deacon <will@kernel.org>
      Cc: kernel test robot <lkp@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6d47c23b
  5. 01 7月, 2021 5 次提交
  6. 25 6月, 2021 1 次提交
  7. 22 6月, 2021 1 次提交
  8. 15 6月, 2021 2 次提交
  9. 09 6月, 2021 1 次提交
  10. 07 6月, 2021 1 次提交
  11. 05 6月, 2021 1 次提交
  12. 04 6月, 2021 1 次提交
  13. 02 6月, 2021 3 次提交
  14. 27 5月, 2021 1 次提交
  15. 26 5月, 2021 13 次提交
  16. 25 5月, 2021 1 次提交
    • J
      arm64: mm: don't use CON and BLK mapping if KFENCE is enabled · e6901240
      Jisheng Zhang 提交于
      When we added KFENCE support for arm64, we intended that it would
      force the entire linear map to be mapped at page granularity, but we
      only enforced this in arch_add_memory() and not in map_mem(), so
      memory mapped at boot time can be mapped at a larger granularity.
      
      When booting a kernel with KFENCE=y and RODATA_FULL=n, this results in
      the following WARNING at boot:
      
      [    0.000000] ------------[ cut here ]------------
      [    0.000000] WARNING: CPU: 0 PID: 0 at mm/memory.c:2462 apply_to_pmd_range+0xec/0x190
      [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc1+ #10
      [    0.000000] Hardware name: linux,dummy-virt (DT)
      [    0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO BTYPE=--)
      [    0.000000] pc : apply_to_pmd_range+0xec/0x190
      [    0.000000] lr : __apply_to_page_range+0x94/0x170
      [    0.000000] sp : ffffffc010573e20
      [    0.000000] x29: ffffffc010573e20 x28: ffffff801f400000 x27: ffffff801f401000
      [    0.000000] x26: 0000000000000001 x25: ffffff801f400fff x24: ffffffc010573f28
      [    0.000000] x23: ffffffc01002b710 x22: ffffffc0105fa450 x21: ffffffc010573ee4
      [    0.000000] x20: ffffff801fffb7d0 x19: ffffff801f401000 x18: 00000000fffffffe
      [    0.000000] x17: 000000000000003f x16: 000000000000000a x15: ffffffc01060b940
      [    0.000000] x14: 0000000000000000 x13: 0098968000000000 x12: 0000000098968000
      [    0.000000] x11: 0000000000000000 x10: 0000000098968000 x9 : 0000000000000001
      [    0.000000] x8 : 0000000000000000 x7 : ffffffc010573ee4 x6 : 0000000000000001
      [    0.000000] x5 : ffffffc010573f28 x4 : ffffffc01002b710 x3 : 0000000040000000
      [    0.000000] x2 : ffffff801f5fffff x1 : 0000000000000001 x0 : 007800005f400705
      [    0.000000] Call trace:
      [    0.000000]  apply_to_pmd_range+0xec/0x190
      [    0.000000]  __apply_to_page_range+0x94/0x170
      [    0.000000]  apply_to_page_range+0x10/0x20
      [    0.000000]  __change_memory_common+0x50/0xdc
      [    0.000000]  set_memory_valid+0x30/0x40
      [    0.000000]  kfence_init_pool+0x9c/0x16c
      [    0.000000]  kfence_init+0x20/0x98
      [    0.000000]  start_kernel+0x284/0x3f8
      
      Fixes: 840b2398 ("arm64, kfence: enable KFENCE for ARM64")
      Cc: <stable@vger.kernel.org> # 5.12.x
      Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NMarco Elver <elver@google.com>
      Tested-by: NMarco Elver <elver@google.com>
      Link: https://lore.kernel.org/r/20210525104551.2ec37f77@xhacker.debianSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      e6901240
  17. 15 5月, 2021 1 次提交
  18. 14 5月, 2021 1 次提交
新手
引导
客服 返回
顶部