Skip to contentSkip to conversation

arm64: avoid TLB conflict with CONFIG_RANDOMIZE_BASE

PATCH New Mark Rutland 4 participants 4 messages Aug 24, 2016 – Aug 25, 2016

Subsystems (2)
Stable branch arm64
lore
Share & tools
lore

Mark Rutland

author reviewer
#0 lore raw

PATCH 1/1 arm64: avoid TLB conflict with CONFIG_RANDOMIZE_BASE

When CONFIG_RANDOMIZE_BASE is selected, we modify the page tables to remap the kernel at a newly-chosen VA range. We do this with the MMU disabled, but do not invalidate TLBs prior to re-enabling the MMU with the new tables. Thus the old mappings entries may still live in TLBs, and we risk violating Break-Before-Make requirements, leading to TLB conflicts and/or other issues.

We invalidate TLBs when we uninsall the idmap in early setup code, but prior to this we are subject to issues relating to the Break-Before-Make violation.

Avoid these issues by invalidating the TLBs before the new mappings can be used by the hardware.

Fixes f80fb3a3d50843a4 ("arm64: add support for kernel ASLR")
Signed-off-by Mark Rutland <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc stable at vger.kernel.org
---
 arch/arm64/kernel/head.S | 3 +++
 1 file changed, 3 insertions(+)
arch/arm64/kernel/head.S +3 -0
index b77f583..3e7b050 100644
@@ -757,6 +757,9 @@ ENTRY(__enable_mmu)
 	isb
 	bl	__create_page_tables		// recreate kernel mapping
 
+	tlbi	vmalle1				// Remove any stale TLB entries
+	dsb	nsh
+
 	msr	sctlr_el1, x19			// re-enable the MMU
 	isb
 	ic	iallu				// flush instructions fetched
Signature · 1 line
2.7.4
#1 lore raw

PATCH 1/1 arm64: avoid TLB conflict with CONFIG_RANDOMIZE_BASE

Quoted 12 lines · Mark Rutland

When CONFIG_RANDOMIZE_BASE is selected, we modify the page tables to remap the kernel at a newly-chosen VA range. We do this with the MMU disabled, but do not invalidate TLBs prior to re-enabling the MMU with the new tables. Thus the old mappings entries may still live in TLBs, and we risk violating Break-Before-Make requirements, leading to TLB conflicts and/or other issues.

We invalidate TLBs when we uninsall the idmap in early setup code, but prior to this we are subject to issues relating to the Break-Before-Make violation.

Avoid these issues by invalidating the TLBs before the new mappings can be used by the hardware.

Quoted 6 lines
Fixes f80fb3a3d50843a4 ("arm64: add support for kernel ASLR")
Signed-off-by Mark Rutland <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc stable at vger.kernel.org

Ah yes, brown paper bag time for me.

Acked-by Ard Biesheuvel <[email protected]>
Quoted 21 lines
---
 arch/arm64/kernel/head.S | 3 +++
 1 file changed, 3 insertions(+)
arch/arm64/kernel/head.S +3 -1
index b77f583..3e7b050 100644
@@ -757,6 +757,9 @@ ENTRY(__enable_mmu)
        isb
        bl      __create_page_tables            // recreate kernel mapping
 
+       tlbi    vmalle1                         // Remove any stale TLB entries
+       dsb     nsh
+
        msr     sctlr_el1, x19                  // re-enable the MMU
        isb
        ic      iallu                           // flush instructions fetched
--

2.7.4

#2 lore raw

PATCH 1/1 arm64: avoid TLB conflict with CONFIG_RANDOMIZE_BASE

In reply to Mark Rutland
Quoted 18 lines · Mark Rutland

When CONFIG_RANDOMIZE_BASE is selected, we modify the page tables to remap the kernel at a newly-chosen VA range. We do this with the MMU disabled, but do not invalidate TLBs prior to re-enabling the MMU with the new tables. Thus the old mappings entries may still live in TLBs, and we risk violating Break-Before-Make requirements, leading to TLB conflicts and/or other issues.

We invalidate TLBs when we uninsall the idmap in early setup code, but prior to this we are subject to issues relating to the Break-Before-Make violation.

Avoid these issues by invalidating the TLBs before the new mappings can be used by the hardware.

Fixes f80fb3a3d50843a4 ("arm64: add support for kernel ASLR")
Signed-off-by Mark Rutland <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc stable at vger.kernel.org
Quoted 3 lines
---
 arch/arm64/kernel/head.S | 3 +++
 1 file changed, 3 insertions(+)
Acked-by Will Deacon <[email protected]>

Although I do wonder whether it would be cleaner to do the local TLBI in __create_page_tables after zeroing swapper, and then moving the TLBI out of __cpu_setup and onto the secondary boot path. I suppose it doesn't really matter...

Will

Quoted 17 lines
arch/arm64/kernel/head.S +3 -0
index b77f583..3e7b050 100644
@@ -757,6 +757,9 @@ ENTRY(__enable_mmu)
 	isb
 	bl	__create_page_tables		// recreate kernel mapping
 
+	tlbi	vmalle1				// Remove any stale TLB entries
+	dsb	nsh
+
 	msr	sctlr_el1, x19			// re-enable the MMU
 	isb
 	ic	iallu				// flush instructions fetched
Signature · 1 line
2.7.4
maintainer Applied
#3 lore raw

PATCH 1/1 arm64: avoid TLB conflict with CONFIG_RANDOMIZE_BASE

In reply to Mark Rutland
Quoted 12 lines · Mark Rutland

When CONFIG_RANDOMIZE_BASE is selected, we modify the page tables to remap the kernel at a newly-chosen VA range. We do this with the MMU disabled, but do not invalidate TLBs prior to re-enabling the MMU with the new tables. Thus the old mappings entries may still live in TLBs, and we risk violating Break-Before-Make requirements, leading to TLB conflicts and/or other issues.

We invalidate TLBs when we uninsall the idmap in early setup code, but prior to this we are subject to issues relating to the Break-Before-Make violation.

Avoid these issues by invalidating the TLBs before the new mappings can be used by the hardware.

Quoted 6 lines
Fixes f80fb3a3d50843a4 ("arm64: add support for kernel ASLR")
Signed-off-by Mark Rutland <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc stable at vger.kernel.org

Applied to arm64 fixes/core.

Signature · 1 line
Catalin