Thread (24 messages) flat view 24 messages, 2 authors, 2016-08-30
STALE3656d

[PATCH v2 4/9] arm64: head.S: move KASLR processing out of __enable_mmu()

From: mark.rutland@arm.com (Mark Rutland)
Date: 2016-08-24 20:46:54

On Wed, Aug 24, 2016 at 09:36:10PM +0100, Mark Rutland wrote:
On Wed, Aug 24, 2016 at 04:36:01PM +0200, Ard Biesheuvel wrote:
quoted
+__primary_switch:
+#ifdef CONFIG_RANDOMIZE_BASE
+	mov	x19, x0				// preserve new SCTLR_EL1 value
+	mrs	x20, sctlr_el1			// preserve old SCTLR_EL1 value
+#endif
+
+	adr	x27, 0f
+	b	__enable_mmu
As we do elsewhere, it's probably worth a comment on the line with the ADR into
x27, mentioning that __enable_mmu will branch there.

... or perhaps we should just have __enable_mmu return to the LR like a normal
AAPCS function, place the switch routines in the idmap, and use the idiomatic
sequence:

__thing_switch:
	bl	__enable_mmu
	ldr	xN, =__thing
	blr	xN
... and now I see that this is what subsequent patches do ;)

Is it possible to first AAPCS-ify __enable_mmu (with shuffling of callers as
above) in one patch, prior to this? That would avoid introducing the unusual 0f
label above, and the temporary x30 usage in a subsequent patch.

Thanks,
Mark.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help