[PATCH -next 0/3] replace open coded VA->PA calculation

[PATCH -next 0/3] replace open coded VA->PA calculation

[Gaosheng Cui]

These patches replace an open coded calculation to obtain the physical
address of a far symbol with a call to the new ldr_l etc macro, and they
belong to the kaslr patch set of arm32.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest

Ard Biesheuvel (3):
  arm-soc: exynos: replace open coded VA->PA conversions
  arm-soc: mvebu: replace open coded VA->PA conversion
  arm-soc: various: replace open coded VA->PA calculation

 arch/arm/mach-exynos/headsmp.S     |  9 +--------
 arch/arm/mach-exynos/sleep.S       | 26 +++++---------------------
 arch/arm/mach-mvebu/coherency_ll.S |  8 +-------
 arch/arm/mach-spear/headsmp.S      | 11 +++--------
 arch/arm/plat-versatile/headsmp.S  |  9 +--------
 5 files changed, 11 insertions(+), 52 deletions(-)

-- 
2.30.0

[PATCH -next 0/3] replace open coded VA->PA calculation

[Gaosheng Cui]

These patches replace an open coded calculation to obtain the physical
address of a far symbol with a call to the new ldr_l etc macro, and they
belong to the kaslr patch set of arm32.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest

Ard Biesheuvel (3):
  arm-soc: exynos: replace open coded VA->PA conversions
  arm-soc: mvebu: replace open coded VA->PA conversion
  arm-soc: various: replace open coded VA->PA calculation

 arch/arm/mach-exynos/headsmp.S     |  9 +--------
 arch/arm/mach-exynos/sleep.S       | 26 +++++---------------------
 arch/arm/mach-mvebu/coherency_ll.S |  8 +-------
 arch/arm/mach-spear/headsmp.S      | 11 +++--------
 arch/arm/plat-versatile/headsmp.S  |  9 +--------
 5 files changed, 11 insertions(+), 52 deletions(-)

-- 
2.30.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH -next 1/3] arm-soc: exynos: replace open coded VA->PA conversions

[Gaosheng Cui]

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This replaces a couple of open coded calculations to obtain the
physical address of a far symbol with calls to the new adr_l etc
macros.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
 arch/arm/mach-exynos/headsmp.S |  9 +--------
 arch/arm/mach-exynos/sleep.S   | 26 +++++---------------------
 2 files changed, 6 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S
index 0ac2cb9a7355..be7cd0eebe1d 100644
--- a/arch/arm/mach-exynos/headsmp.S
+++ b/arch/arm/mach-exynos/headsmp.S
@@ -19,10 +19,7 @@ ENTRY(exynos4_secondary_startup)
 ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	and	r0, r0, #15
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
+	adr_l	r6, exynos_pen_release
 pen:	ldr	r7, [r6]
 	cmp	r7, r0
 	bne	pen
@@ -33,7 +30,3 @@ pen:	ldr	r7, [r6]
 	 */
 	b	secondary_startup
 ENDPROC(exynos4_secondary_startup)
-
-	.align 2
-1:	.long	.
-	.long	exynos_pen_release
diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S
index ed93f91853b8..ed27515a4458 100644
--- a/arch/arm/mach-exynos/sleep.S
+++ b/arch/arm/mach-exynos/sleep.S
@@ -8,6 +8,7 @@
 
 #include <linux/linkage.h>
 #include <asm/asm-offsets.h>
+#include <asm/assembler.h>
 #include <asm/hardware/cache-l2x0.h>
 #include "smc.h"
 
@@ -54,19 +55,13 @@ ENTRY(exynos_cpu_resume_ns)
 	cmp	r0, r1
 	bne	skip_cp15
 
-	adr	r0, _cp15_save_power
-	ldr	r1, [r0]
-	ldr	r1, [r0, r1]
-	adr	r0, _cp15_save_diag
-	ldr	r2, [r0]
-	ldr	r2, [r0, r2]
+	ldr_l	r1, cp15_save_power
+	ldr_l	r2, cp15_save_diag
 	mov	r0, #SMC_CMD_C15RESUME
 	dsb
 	smc	#0
 #ifdef CONFIG_CACHE_L2X0
-	adr	r0, 1f
-	ldr	r2, [r0]
-	add	r0, r2, r0
+	adr_l	r0, l2x0_saved_regs
 
 	/* Check that the address has been initialised. */
 	ldr	r1, [r0, #L2X0_R_PHY_BASE]
@@ -85,9 +80,7 @@ ENTRY(exynos_cpu_resume_ns)
 	smc	#0
 
 	/* Reload saved regs pointer because smc corrupts registers. */
-	adr	r0, 1f
-	ldr	r2, [r0]
-	add	r0, r2, r0
+	adr_l	r0, l2x0_saved_regs
 
 	ldr	r1, [r0, #L2X0_R_PWR_CTRL]
 	ldr	r2, [r0, #L2X0_R_AUX_CTRL]
@@ -106,15 +99,6 @@ skip_cp15:
 	b	cpu_resume
 ENDPROC(exynos_cpu_resume_ns)
 
-	.align
-_cp15_save_power:
-	.long	cp15_save_power - .
-_cp15_save_diag:
-	.long	cp15_save_diag - .
-#ifdef CONFIG_CACHE_L2X0
-1:	.long	l2x0_saved_regs - .
-#endif /* CONFIG_CACHE_L2X0 */
-
 	.data
 	.align	2
 	.globl cp15_save_diag
-- 
2.30.0

[PATCH -next 1/3] arm-soc: exynos: replace open coded VA->PA conversions

[Gaosheng Cui]

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This replaces a couple of open coded calculations to obtain the
physical address of a far symbol with calls to the new adr_l etc
macros.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
 arch/arm/mach-exynos/headsmp.S |  9 +--------
 arch/arm/mach-exynos/sleep.S   | 26 +++++---------------------
 2 files changed, 6 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S
index 0ac2cb9a7355..be7cd0eebe1d 100644
--- a/arch/arm/mach-exynos/headsmp.S
+++ b/arch/arm/mach-exynos/headsmp.S
@@ -19,10 +19,7 @@ ENTRY(exynos4_secondary_startup)
 ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	and	r0, r0, #15
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
+	adr_l	r6, exynos_pen_release
 pen:	ldr	r7, [r6]
 	cmp	r7, r0
 	bne	pen
@@ -33,7 +30,3 @@ pen:	ldr	r7, [r6]
 	 */
 	b	secondary_startup
 ENDPROC(exynos4_secondary_startup)
-
-	.align 2
-1:	.long	.
-	.long	exynos_pen_release
diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S
index ed93f91853b8..ed27515a4458 100644
--- a/arch/arm/mach-exynos/sleep.S
+++ b/arch/arm/mach-exynos/sleep.S
@@ -8,6 +8,7 @@
 
 #include <linux/linkage.h>
 #include <asm/asm-offsets.h>
+#include <asm/assembler.h>
 #include <asm/hardware/cache-l2x0.h>
 #include "smc.h"
 
@@ -54,19 +55,13 @@ ENTRY(exynos_cpu_resume_ns)
 	cmp	r0, r1
 	bne	skip_cp15
 
-	adr	r0, _cp15_save_power
-	ldr	r1, [r0]
-	ldr	r1, [r0, r1]
-	adr	r0, _cp15_save_diag
-	ldr	r2, [r0]
-	ldr	r2, [r0, r2]
+	ldr_l	r1, cp15_save_power
+	ldr_l	r2, cp15_save_diag
 	mov	r0, #SMC_CMD_C15RESUME
 	dsb
 	smc	#0
 #ifdef CONFIG_CACHE_L2X0
-	adr	r0, 1f
-	ldr	r2, [r0]
-	add	r0, r2, r0
+	adr_l	r0, l2x0_saved_regs
 
 	/* Check that the address has been initialised. */
 	ldr	r1, [r0, #L2X0_R_PHY_BASE]
@@ -85,9 +80,7 @@ ENTRY(exynos_cpu_resume_ns)
 	smc	#0
 
 	/* Reload saved regs pointer because smc corrupts registers. */
-	adr	r0, 1f
-	ldr	r2, [r0]
-	add	r0, r2, r0
+	adr_l	r0, l2x0_saved_regs
 
 	ldr	r1, [r0, #L2X0_R_PWR_CTRL]
 	ldr	r2, [r0, #L2X0_R_AUX_CTRL]
@@ -106,15 +99,6 @@ skip_cp15:
 	b	cpu_resume
 ENDPROC(exynos_cpu_resume_ns)
 
-	.align
-_cp15_save_power:
-	.long	cp15_save_power - .
-_cp15_save_diag:
-	.long	cp15_save_diag - .
-#ifdef CONFIG_CACHE_L2X0
-1:	.long	l2x0_saved_regs - .
-#endif /* CONFIG_CACHE_L2X0 */
-
 	.data
 	.align	2
 	.globl cp15_save_diag
-- 
2.30.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH -next 2/3] arm-soc: mvebu: replace open coded VA->PA conversion

[Gaosheng Cui]

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This replaces an open coded calculation to obtain the physical
address of a far symbol with a call to the new ldr_l etc macro.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
 arch/arm/mach-mvebu/coherency_ll.S | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index a3a64bf97250..9ae65b1e9745 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -37,9 +37,7 @@ ENTRY(ll_get_coherency_base)
 	 * MMU is disabled, use the physical address of the coherency
 	 * base address, (or 0x0 if the coherency fabric is not mapped)
 	 */
-	adr	r1, 3f
-	ldr	r3, [r1]
-	ldr	r1, [r1, r3]
+	ldr_l	r1, coherency_phys_base
 	b	2f
 1:
 	/*
@@ -155,7 +153,3 @@ ENTRY(ll_disable_coherency)
 	dsb
 	ret	lr
 ENDPROC(ll_disable_coherency)
-
-	.align 2
-3:
-	.long	coherency_phys_base - .
-- 
2.30.0

[PATCH -next 2/3] arm-soc: mvebu: replace open coded VA->PA conversion

[Gaosheng Cui]

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This replaces an open coded calculation to obtain the physical
address of a far symbol with a call to the new ldr_l etc macro.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
 arch/arm/mach-mvebu/coherency_ll.S | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index a3a64bf97250..9ae65b1e9745 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -37,9 +37,7 @@ ENTRY(ll_get_coherency_base)
 	 * MMU is disabled, use the physical address of the coherency
 	 * base address, (or 0x0 if the coherency fabric is not mapped)
 	 */
-	adr	r1, 3f
-	ldr	r3, [r1]
-	ldr	r1, [r1, r3]
+	ldr_l	r1, coherency_phys_base
 	b	2f
 1:
 	/*
@@ -155,7 +153,3 @@ ENTRY(ll_disable_coherency)
 	dsb
 	ret	lr
 ENDPROC(ll_disable_coherency)
-
-	.align 2
-3:
-	.long	coherency_phys_base - .
-- 
2.30.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH -next 3/3] arm-soc: various: replace open coded VA->PA calculation

[Gaosheng Cui]

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This replaces a few copies of the open coded calculations of the
physical address in the secondary startup code of a couple of
platforms. This ensures these quantities are invariant under
runtime relocation.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
 arch/arm/mach-spear/headsmp.S     | 11 +++--------
 arch/arm/plat-versatile/headsmp.S |  9 +--------
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-spear/headsmp.S b/arch/arm/mach-spear/headsmp.S
index 96f89436ccf6..32ffc75ff332 100644
--- a/arch/arm/mach-spear/headsmp.S
+++ b/arch/arm/mach-spear/headsmp.S
@@ -10,6 +10,8 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 
+#include <asm/assembler.h>
+
 	__INIT
 
 /*
@@ -20,10 +22,7 @@
 ENTRY(spear13xx_secondary_startup)
 	mrc	p15, 0, r0, c0, c0, 5
 	and	r0, r0, #15
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
+	adr_l	r6, spear_pen_release
 pen:	ldr	r7, [r6]
 	cmp	r7, r0
 	bne	pen
@@ -37,8 +36,4 @@ pen:	ldr	r7, [r6]
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-
-	.align
-1:	.long	.
-	.long	spear_pen_release
 ENDPROC(spear13xx_secondary_startup)
diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
index 09d9fc30c8ca..cec71853b0b3 100644
--- a/arch/arm/plat-versatile/headsmp.S
+++ b/arch/arm/plat-versatile/headsmp.S
@@ -18,10 +18,7 @@ ENTRY(versatile_secondary_startup)
  ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	bic	r0, #0xff000000
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
+	adr_l	r6, versatile_cpu_release
 pen:	ldr	r7, [r6]
 	cmp	r7, r0
 	bne	pen
@@ -31,8 +28,4 @@ pen:	ldr	r7, [r6]
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-
-	.align
-1:	.long	.
-	.long	versatile_cpu_release
 ENDPROC(versatile_secondary_startup)
-- 
2.30.0

[PATCH -next 3/3] arm-soc: various: replace open coded VA->PA calculation

[Gaosheng Cui]

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This replaces a few copies of the open coded calculations of the
physical address in the secondary startup code of a couple of
platforms. This ensures these quantities are invariant under
runtime relocation.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
 arch/arm/mach-spear/headsmp.S     | 11 +++--------
 arch/arm/plat-versatile/headsmp.S |  9 +--------
 2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-spear/headsmp.S b/arch/arm/mach-spear/headsmp.S
index 96f89436ccf6..32ffc75ff332 100644
--- a/arch/arm/mach-spear/headsmp.S
+++ b/arch/arm/mach-spear/headsmp.S
@@ -10,6 +10,8 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 
+#include <asm/assembler.h>
+
 	__INIT
 
 /*
@@ -20,10 +22,7 @@
 ENTRY(spear13xx_secondary_startup)
 	mrc	p15, 0, r0, c0, c0, 5
 	and	r0, r0, #15
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
+	adr_l	r6, spear_pen_release
 pen:	ldr	r7, [r6]
 	cmp	r7, r0
 	bne	pen
@@ -37,8 +36,4 @@ pen:	ldr	r7, [r6]
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-
-	.align
-1:	.long	.
-	.long	spear_pen_release
 ENDPROC(spear13xx_secondary_startup)
diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
index 09d9fc30c8ca..cec71853b0b3 100644
--- a/arch/arm/plat-versatile/headsmp.S
+++ b/arch/arm/plat-versatile/headsmp.S
@@ -18,10 +18,7 @@ ENTRY(versatile_secondary_startup)
  ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	bic	r0, #0xff000000
-	adr	r4, 1f
-	ldmia	r4, {r5, r6}
-	sub	r4, r4, r5
-	add	r6, r6, r4
+	adr_l	r6, versatile_cpu_release
 pen:	ldr	r7, [r6]
 	cmp	r7, r0
 	bne	pen
@@ -31,8 +28,4 @@ pen:	ldr	r7, [r6]
 	 * should now contain the SVC stack for this core
 	 */
 	b	secondary_startup
-
-	.align
-1:	.long	.
-	.long	versatile_cpu_release
 ENDPROC(versatile_secondary_startup)
-- 
2.30.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Arnd Bergmann]

On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
>
> These patches replace an open coded calculation to obtain the physical
> address of a far symbol with a call to the new ldr_l etc macro, and they
> belong to the kaslr patch set of arm32.
>
> Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
>
> Ard Biesheuvel (3):
>   arm-soc: exynos: replace open coded VA->PA conversions
>   arm-soc: mvebu: replace open coded VA->PA conversion
>   arm-soc: various: replace open coded VA->PA calculation

Usually these patches should go through the respective platform
maintainer trees,
and from there into the soc tree, but time is a little short here.

I could apply them directly with the maintainer Acks, but I don't understand
the significance of you sending them now. Is something broken without the
three patches? Are these the only ones missing from Ard's original series,
or is this preparation? Would you expect the patches to get backported to
stable kernels?

       Arnd

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Arnd Bergmann]

On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
>
> These patches replace an open coded calculation to obtain the physical
> address of a far symbol with a call to the new ldr_l etc macro, and they
> belong to the kaslr patch set of arm32.
>
> Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
>
> Ard Biesheuvel (3):
>   arm-soc: exynos: replace open coded VA->PA conversions
>   arm-soc: mvebu: replace open coded VA->PA conversion
>   arm-soc: various: replace open coded VA->PA calculation

Usually these patches should go through the respective platform
maintainer trees,
and from there into the soc tree, but time is a little short here.

I could apply them directly with the maintainer Acks, but I don't understand
the significance of you sending them now. Is something broken without the
three patches? Are these the only ones missing from Ard's original series,
or is this preparation? Would you expect the patches to get backported to
stable kernels?

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Andrew Lunn]

On Mon, Dec 20, 2021 at 04:39:43PM +0100, Arnd Bergmann wrote:
> On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
> >
> > These patches replace an open coded calculation to obtain the physical
> > address of a far symbol with a call to the new ldr_l etc macro, and they
> > belong to the kaslr patch set of arm32.
> >
> > Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
> >
> > Ard Biesheuvel (3):
> >   arm-soc: exynos: replace open coded VA->PA conversions
> >   arm-soc: mvebu: replace open coded VA->PA conversion
> >   arm-soc: various: replace open coded VA->PA calculation
> 
> Usually these patches should go through the respective platform
> maintainer trees,
> and from there into the soc tree, but time is a little short here.
> 
> I could apply them directly with the maintainer Acks

Sorry, but this is too low level for me to understand what is going
on, and so feel confident actually giving an ACK for the mvebu change.

Should the resulting assembly be exactly the same? Has the submitter
disassembled the object code and shown there is no actual difference
in the assembler output?

   Andrew

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Andrew Lunn]

On Mon, Dec 20, 2021 at 04:39:43PM +0100, Arnd Bergmann wrote:
> On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
> >
> > These patches replace an open coded calculation to obtain the physical
> > address of a far symbol with a call to the new ldr_l etc macro, and they
> > belong to the kaslr patch set of arm32.
> >
> > Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
> >
> > Ard Biesheuvel (3):
> >   arm-soc: exynos: replace open coded VA->PA conversions
> >   arm-soc: mvebu: replace open coded VA->PA conversion
> >   arm-soc: various: replace open coded VA->PA calculation
> 
> Usually these patches should go through the respective platform
> maintainer trees,
> and from there into the soc tree, but time is a little short here.
> 
> I could apply them directly with the maintainer Acks

Sorry, but this is too low level for me to understand what is going
on, and so feel confident actually giving an ACK for the mvebu change.

Should the resulting assembly be exactly the same? Has the submitter
disassembled the object code and shown there is no actual difference
in the assembler output?

   Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Ard Biesheuvel]

On Mon, 20 Dec 2021 at 19:06, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Dec 20, 2021 at 04:39:43PM +0100, Arnd Bergmann wrote:
> > On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
> > >
> > > These patches replace an open coded calculation to obtain the physical
> > > address of a far symbol with a call to the new ldr_l etc macro, and they
> > > belong to the kaslr patch set of arm32.
> > >
> > > Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
> > >
> > > Ard Biesheuvel (3):
> > >   arm-soc: exynos: replace open coded VA->PA conversions
> > >   arm-soc: mvebu: replace open coded VA->PA conversion
> > >   arm-soc: various: replace open coded VA->PA calculation
> >
> > Usually these patches should go through the respective platform
> > maintainer trees,
> > and from there into the soc tree, but time is a little short here.
> >
> > I could apply them directly with the maintainer Acks
>
> Sorry, but this is too low level for me to understand what is going
> on, and so feel confident actually giving an ACK for the mvebu change.
>
> Should the resulting assembly be exactly the same? Has the submitter
> disassembled the object code and shown there is no actual difference
> in the assembler output?
>

The assembly does not stay the same, that is really the point of these
patches: to replace hard to understand pointer arithmetic with simple
position independent macro invocations.

However, I don't think it really makes sense at this point to merge
these: the KASLR patches are ancient and never constituted more than a
proof of concept, so grabbing bits and pieces of it arbitrarily seems
rather pointless. Note that there is an effort underway to implement a
4/4 VM split for ARM, which has a huge impact on KASLR, and so those
changes need a lot of work and discussion before we can proceed with
them.

So in summary, NACK for this series.

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Ard Biesheuvel]

On Mon, 20 Dec 2021 at 19:06, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Dec 20, 2021 at 04:39:43PM +0100, Arnd Bergmann wrote:
> > On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
> > >
> > > These patches replace an open coded calculation to obtain the physical
> > > address of a far symbol with a call to the new ldr_l etc macro, and they
> > > belong to the kaslr patch set of arm32.
> > >
> > > Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
> > >
> > > Ard Biesheuvel (3):
> > >   arm-soc: exynos: replace open coded VA->PA conversions
> > >   arm-soc: mvebu: replace open coded VA->PA conversion
> > >   arm-soc: various: replace open coded VA->PA calculation
> >
> > Usually these patches should go through the respective platform
> > maintainer trees,
> > and from there into the soc tree, but time is a little short here.
> >
> > I could apply them directly with the maintainer Acks
>
> Sorry, but this is too low level for me to understand what is going
> on, and so feel confident actually giving an ACK for the mvebu change.
>
> Should the resulting assembly be exactly the same? Has the submitter
> disassembled the object code and shown there is no actual difference
> in the assembler output?
>

The assembly does not stay the same, that is really the point of these
patches: to replace hard to understand pointer arithmetic with simple
position independent macro invocations.

However, I don't think it really makes sense at this point to merge
these: the KASLR patches are ancient and never constituted more than a
proof of concept, so grabbing bits and pieces of it arbitrarily seems
rather pointless. Note that there is an effort underway to implement a
4/4 VM split for ARM, which has a huge impact on KASLR, and so those
changes need a lot of work and discussion before we can proceed with
them.

So in summary, NACK for this series.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[cuigaosheng]

> I could apply them directly with the maintainer Acks, but I don't understand
> the significance of you sending them now. Is something broken without the
> three patches? Are these the only ones missing from Ard's original series,
> or is this preparation? Would you expect the patches to get backported to
> stable kernels?

Thanks for your reply.

This is preparation work for arm32 kaslr,and I want to continue to improve
the solution based on the work of Ard. These patches are relatively
independent, so I submit these patches first.

Gaosheng.

在 2021/12/20 23:39, Arnd Bergmann 写道:
> On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
>> These patches replace an open coded calculation to obtain the physical
>> address of a far symbol with a call to the new ldr_l etc macro, and they
>> belong to the kaslr patch set of arm32.
>>
>> Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
>>
>> Ard Biesheuvel (3):
>>    arm-soc: exynos: replace open coded VA->PA conversions
>>    arm-soc: mvebu: replace open coded VA->PA conversion
>>    arm-soc: various: replace open coded VA->PA calculation
> Usually these patches should go through the respective platform
> maintainer trees,
> and from there into the soc tree, but time is a little short here.
>
> I could apply them directly with the maintainer Acks, but I don't understand
> the significance of you sending them now. Is something broken without the
> three patches? Are these the only ones missing from Ard's original series,
> or is this preparation? Would you expect the patches to get backported to
> stable kernels?
>
>         Arnd
> .

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[cuigaosheng]

> I could apply them directly with the maintainer Acks, but I don't understand
> the significance of you sending them now. Is something broken without the
> three patches? Are these the only ones missing from Ard's original series,
> or is this preparation? Would you expect the patches to get backported to
> stable kernels?

Thanks for your reply.

This is preparation work for arm32 kaslr,and I want to continue to improve
the solution based on the work of Ard. These patches are relatively
independent, so I submit these patches first.

Gaosheng.

在 2021/12/20 23:39, Arnd Bergmann 写道:
> On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
>> These patches replace an open coded calculation to obtain the physical
>> address of a far symbol with a call to the new ldr_l etc macro, and they
>> belong to the kaslr patch set of arm32.
>>
>> Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
>>
>> Ard Biesheuvel (3):
>>    arm-soc: exynos: replace open coded VA->PA conversions
>>    arm-soc: mvebu: replace open coded VA->PA conversion
>>    arm-soc: various: replace open coded VA->PA calculation
> Usually these patches should go through the respective platform
> maintainer trees,
> and from there into the soc tree, but time is a little short here.
>
> I could apply them directly with the maintainer Acks, but I don't understand
> the significance of you sending them now. Is something broken without the
> three patches? Are these the only ones missing from Ard's original series,
> or is this preparation? Would you expect the patches to get backported to
> stable kernels?
>
>         Arnd
> .

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Arnd Bergmann]

On Tue, Dec 21, 2021 at 2:41 AM cuigaosheng <cuigaosheng1@huawei.com> wrote:
>
> > I could apply them directly with the maintainer Acks, but I don't understand
> > the significance of you sending them now. Is something broken without the
> > three patches? Are these the only ones missing from Ard's original series,
> > or is this preparation? Would you expect the patches to get backported to
> > stable kernels?
>
> Thanks for your reply.
>
> This is preparation work for arm32 kaslr,and I want to continue to improve
> the solution based on the work of Ard. These patches are relatively
> independent, so I submit these patches first.

The approach of merging support incrementally is good in principle, but in this
case I think we first need to agree on the overall direction first.
How far have you
come rebasing Ard's patches, do you have KASLR working yet? This is information
that should go into the [PATCH 0/3] cover letter.

Do you have a particular target platform in mind?

I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
memory model, which in turn depends on having the kernel in vmalloc space, as
implemented by Linus Walleij in
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1

With this work, the randomization will look quite different, on the one hand it
leaves less room for relocating the kernel within the smaller 256MB vmalloc
space, while on the other hand it does open the possibility of complete
randomization by scrambling the virt-to-phys mapping in vmalloc space,
using linear virtual addresses to refer to a randomized set of
physical addresses.
(this is just a wild idea that one could implement, nobody has actual plans for
it at the moment, and it comes with additional runtime overhead).

        Arnd

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Arnd Bergmann]

On Tue, Dec 21, 2021 at 2:41 AM cuigaosheng <cuigaosheng1@huawei.com> wrote:
>
> > I could apply them directly with the maintainer Acks, but I don't understand
> > the significance of you sending them now. Is something broken without the
> > three patches? Are these the only ones missing from Ard's original series,
> > or is this preparation? Would you expect the patches to get backported to
> > stable kernels?
>
> Thanks for your reply.
>
> This is preparation work for arm32 kaslr,and I want to continue to improve
> the solution based on the work of Ard. These patches are relatively
> independent, so I submit these patches first.

The approach of merging support incrementally is good in principle, but in this
case I think we first need to agree on the overall direction first.
How far have you
come rebasing Ard's patches, do you have KASLR working yet? This is information
that should go into the [PATCH 0/3] cover letter.

Do you have a particular target platform in mind?

I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
memory model, which in turn depends on having the kernel in vmalloc space, as
implemented by Linus Walleij in
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1

With this work, the randomization will look quite different, on the one hand it
leaves less room for relocating the kernel within the smaller 256MB vmalloc
space, while on the other hand it does open the possibility of complete
randomization by scrambling the virt-to-phys mapping in vmalloc space,
using linear virtual addresses to refer to a randomized set of
physical addresses.
(this is just a wild idea that one could implement, nobody has actual plans for
it at the moment, and it comes with additional runtime overhead).

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Linus Walleij]

On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:

> I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
> memory model, which in turn depends on having the kernel in vmalloc space, as
> implemented by Linus Walleij in
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1

Yeah I'm still working on this series. The 4/4 split works pretty well,
but it breaks KASan and I was in the process of fixing that when I left
for parental leave.

The reason it breaks would be related to KASan not expecting
executable code in the vmalloc area, and since the shadowing
algorithm is a simple pointer offset, and since we go to lengths
to chisel shadow memory out of lowmem at a fixed offset from
TEXT_OFFSET, we have a problem.

The patch "KASAN horror" shows what I am trying to do to fix it,
it's "just" some hard work missing.

Yours,
Linus Walleij

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Linus Walleij]

On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:

> I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
> memory model, which in turn depends on having the kernel in vmalloc space, as
> implemented by Linus Walleij in
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1

Yeah I'm still working on this series. The 4/4 split works pretty well,
but it breaks KASan and I was in the process of fixing that when I left
for parental leave.

The reason it breaks would be related to KASan not expecting
executable code in the vmalloc area, and since the shadowing
algorithm is a simple pointer offset, and since we go to lengths
to chisel shadow memory out of lowmem at a fixed offset from
TEXT_OFFSET, we have a problem.

The patch "KASAN horror" shows what I am trying to do to fix it,
it's "just" some hard work missing.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Ard Biesheuvel]

On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> > I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
> > memory model, which in turn depends on having the kernel in vmalloc space, as
> > implemented by Linus Walleij in
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1
>
> Yeah I'm still working on this series. The 4/4 split works pretty well,
> but it breaks KASan and I was in the process of fixing that when I left
> for parental leave.
>
> The reason it breaks would be related to KASan not expecting
> executable code in the vmalloc area, and since the shadowing
> algorithm is a simple pointer offset, and since we go to lengths
> to chisel shadow memory out of lowmem at a fixed offset from
> TEXT_OFFSET, we have a problem.
>

Vmap'ed stacks actually has a similar problem, which is why it is
disabled when KAsan is enabled. But this can be fixed by enabling arch
support for KASAN_VMALLOC, and I suspect it may address the vmap'ed
kernel as well.

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Ard Biesheuvel]

On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> > I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
> > memory model, which in turn depends on having the kernel in vmalloc space, as
> > implemented by Linus Walleij in
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1
>
> Yeah I'm still working on this series. The 4/4 split works pretty well,
> but it breaks KASan and I was in the process of fixing that when I left
> for parental leave.
>
> The reason it breaks would be related to KASan not expecting
> executable code in the vmalloc area, and since the shadowing
> algorithm is a simple pointer offset, and since we go to lengths
> to chisel shadow memory out of lowmem at a fixed offset from
> TEXT_OFFSET, we have a problem.
>

Vmap'ed stacks actually has a similar problem, which is why it is
disabled when KAsan is enabled. But this can be fixed by enabling arch
support for KASAN_VMALLOC, and I suspect it may address the vmap'ed
kernel as well.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Linus Walleij]

On Wed, Dec 22, 2021 at 10:30 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
> > > memory model, which in turn depends on having the kernel in vmalloc space, as
> > > implemented by Linus Walleij in
> > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1
> >
> > Yeah I'm still working on this series. The 4/4 split works pretty well,

Actually it's just kernel-in-vmalloc, 4/4 comes after that.

> > but it breaks KASan and I was in the process of fixing that when I left
> > for parental leave.
> >
> > The reason it breaks would be related to KASan not expecting
> > executable code in the vmalloc area, and since the shadowing
> > algorithm is a simple pointer offset, and since we go to lengths
> > to chisel shadow memory out of lowmem at a fixed offset from
> > TEXT_OFFSET, we have a problem.
> >
>
> Vmap'ed stacks actually has a similar problem, which is why it is
> disabled when KAsan is enabled. But this can be fixed by enabling arch
> support for KASAN_VMALLOC, and I suspect it may address the vmap'ed
> kernel as well.

Yep after seeing the other convo on the topic I realized that this
is indeed the same as I'm seeing. I can't disable KASAN just
because the kernel is in VMALLOC though, so I suppose when
I finally get back to this I have to fix KASAN_VMALLOC too
if noone beats me to it.

(It'd be great if someone could beat me to it...)

Yours,
Linus Walleij

Re: [PATCH -next 0/3] replace open coded VA->PA calculation

[Linus Walleij]

On Wed, Dec 22, 2021 at 10:30 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
> > > memory model, which in turn depends on having the kernel in vmalloc space, as
> > > implemented by Linus Walleij in
> > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1
> >
> > Yeah I'm still working on this series. The 4/4 split works pretty well,

Actually it's just kernel-in-vmalloc, 4/4 comes after that.

> > but it breaks KASan and I was in the process of fixing that when I left
> > for parental leave.
> >
> > The reason it breaks would be related to KASan not expecting
> > executable code in the vmalloc area, and since the shadowing
> > algorithm is a simple pointer offset, and since we go to lengths
> > to chisel shadow memory out of lowmem at a fixed offset from
> > TEXT_OFFSET, we have a problem.
> >
>
> Vmap'ed stacks actually has a similar problem, which is why it is
> disabled when KAsan is enabled. But this can be fixed by enabling arch
> support for KASAN_VMALLOC, and I suspect it may address the vmap'ed
> kernel as well.

Yep after seeing the other convo on the topic I realized that this
is indeed the same as I'm seeing. I can't disable KASAN just
because the kernel is in VMALLOC though, so I suppose when
I finally get back to this I have to fix KASAN_VMALLOC too
if noone beats me to it.

(It'd be great if someone could beat me to it...)

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel