linux-kernel - [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Sep 2020 17:26:41 +0800
From:   Zhen Lei <thunder.leizhen@...wei.com>
To:     Russell King <linux@...linux.org.uk>,
        Ard Biesheuvel <ardb@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
CC:     Zhen Lei <thunder.leizhen@...wei.com>,
        Libin <huawei.libin@...wei.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>
Subject: [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel

mov	r4, pc
and	r4, r4, #0xf8000000	//truncated to 128MiB boundary
add	r4, r4, #TEXT_OFFSET	//PA(_start)

Currently, the decompressed kernel must be placed at the position: 128MiB
boundary + TEXT_OFFSET. This limitation is just because we masked PC with
0xf80000000. Actually, we can directly obtain PA(_start) by using formula
: VA(_start) + (PHYS_OFFSET - PAGE_OFFSET).

So the "PA(_start) - TEXT_OFFSET" can be 2MiB boundary, 1MiB boundary,
and so on.

Signed-off-by: Zhen Lei <thunder.leizhen@...wei.com>
---
 arch/arm/boot/compressed/head.S | 33 ++++++++++++++-------------------
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 434a16982e344fe..e5ba2ad2ea4700f 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -255,26 +255,16 @@ not_angel:
 
 #ifdef CONFIG_AUTO_ZRELADDR
 		/*
-		 * Find the start of physical memory.  As we are executing
-		 * without the MMU on, we are in the physical address space.
-		 * We just need to get rid of any offset by aligning the
-		 * address.
-		 *
-		 * This alignment is a balance between the requirements of
-		 * different platforms - we have chosen 128MB to allow
-		 * platforms which align the start of their physical memory
-		 * to 128MB to use this feature, while allowing the zImage
-		 * to be placed within the first 128MB of memory on other
-		 * platforms.  Increasing the alignment means we place
-		 * stricter alignment requirements on the start of physical
-		 * memory, but relaxing it means that we break people who
-		 * are already placing their zImage in (eg) the top 64MB
-		 * of this range.
+		 * Find ZRELADDR (Address where the decompressed kernel was
+		 * placed, usually == PHYS_OFFSET + TEXT_OFFSET). That's the
+		 * start physical address of the text section, PA(_start).
+		 * As we are executing without the MMU on, we are in the
+		 * physical address space.
 		 */
-		mov	r4, pc
-		and	r4, r4, #0xf8000000
-		/* Determine final kernel image address. */
-		add	r4, r4, #TEXT_OFFSET
+		adr	r0, LC2
+		ldmia	r0, {r3-r4}
+		sub	r3, r0, r3		@ PHYS_OFFSET - PAGE_OFFSET
+		add	r4, r4, r3		@ PA(_start)
 #else
 		ldr	r4, =zreladdr
 #endif
@@ -660,6 +650,11 @@ LC1:		.word	.L_user_stack_end - LC1	@ sp
 		.word	_edata - LC1		@ r6
 		.size	LC1, . - LC1
 
+		.align	2
+		.type	LC2, #object
+LC2:		.word	LC2
+		.word	_start			@ start VA of text section
+
 .Lheadroom:
 		.word	_end - restart + 16384 + 1024*1024
 
-- 
1.8.3