]> git.baikalelectronics.ru Git - kernel.git/commit
arm64/mm: Inhibit huge-vmap with ptdump
authorMark Rutland <mark.rutland@arm.com>
Tue, 14 May 2019 09:00:06 +0000 (14:30 +0530)
committerWill Deacon <will.deacon@arm.com>
Thu, 16 May 2019 10:24:09 +0000 (11:24 +0100)
commit645f79c07dd158885eb417e97b4a4387b0cc6790
treeb36aacc082ff58f9e75b73c46ddcc7bdd88b58c1
parentbe6304303172f9dc7b4aea4a00453fa5581eb0e1
arm64/mm: Inhibit huge-vmap with ptdump

The arm64 ptdump code can race with concurrent modification of the
kernel page tables. At the time this was added, this was sound as:

* Modifications to leaf entries could result in stale information being
  logged, but would not result in a functional problem.

* Boot time modifications to non-leaf entries (e.g. freeing of initmem)
  were performed when the ptdump code cannot be invoked.

* At runtime, modifications to non-leaf entries only occurred in the
  vmalloc region, and these were strictly additive, as intermediate
  entries were never freed.

However, since commit:

  commit 44cbdfd83dd3 ("arm64: add support for ioremap() block mappings")

... it has been possible to create huge mappings in the vmalloc area at
runtime, and as part of this existing intermediate levels of table my be
removed and freed.

It's possible for the ptdump code to race with this, and continue to
walk tables which have been freed (and potentially poisoned or
reallocated). As a result of this, the ptdump code may dereference bogus
addresses, which could be fatal.

Since huge-vmap is a TLB and memory optimization, we can disable it when
the runtime ptdump code is in use to avoid this problem.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Fixes: 44cbdfd83dd36b69 ("arm64: add support for ioremap() block mappings")
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arch/arm64/mm/mmu.c