linux-kernel - [PATCH v2 3/5] MIPS: Jump to kernel linked address by PC relative way

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]

Message-Id: <1618230494-6207-4-git-send-email-hejinyang@loongson.cn>
Date:   Mon, 12 Apr 2021 20:28:12 +0800
From:   Jinyang He <hejinyang@...ngson.cn>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Paul Burton <paulburton@...nel.org>
Cc:     linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v2 3/5] MIPS: Jump to kernel linked address by PC relative way

Commit 15ad838d281b ("[MIPS] Always do the ARC64_TWIDDLE_PC thing.")
gives the kernel a chance to jump to the address the kernel is linked to.
It can be seen from the old records that this situation is usually a jump
from XPHYS to KSEG0. For example, kdump operation, kexec_start_address is
usually in XPHYS on Loongson64 platform. Jumping from XPHYS to KSEG0 is a
big jump. With the relocation, there may be small jumps. As follows,

			+-----------+
			|           |
			|___________|
			|           |
			|  _kernel  |
			|           |
			|_\0:       |
			|   jr t0   |---+
			| la t0, \0 |   |
			|___________|   |
			|           |   |
			|           |   |
			|___________|   |
			|           |   |
			|  kernel   |   |
			|           |   |
			|\0:        |<--+
			|   jr t0   |
			| la t0, \0 |
			|           |
			|___________|
			|           |
			+-----------+

_kernel is same as kernel, only the loaded address is different. They are
all in KSEG0. For kernel, `jr t0` is right operation and PC will jump to
\0. For _kernel, `jr t0` is dangerous operation and PC will not jump to
_\0 because `la t0, \0` target address is not PC relative.

This patch get the PC address by fixed `1:` (t0) and dynamic ra at
`1:` (t1). t0 determines the PC Region of the address where the kernel is
linked to. t1 determines the offset relative to the PC Region.

Signed-off-by: Jinyang He <hejinyang@...ngson.cn>
---
 arch/mips/kernel/head.S | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index a25af1d..0186285 100644
--- a/arch/mips/kernel/head.S
+++ b/arch/mips/kernel/head.S
@@ -79,6 +79,9 @@ FEXPORT(__kernel_entry)
 	j	kernel_entry
 #endif /* CONFIG_BOOT_RAW */

+#define PC_REGION_SHIFT 28
+#define PC_REGION_MASK (~(1 << PC_REGION_SHIFT - 1))
+
 	__REF

 NESTED(kernel_entry, 16, sp)			# kernel entry point
@@ -89,9 +92,17 @@ NESTED(kernel_entry, 16, sp)			# kernel entry point

 	/* We might not get launched at the address the kernel is linked to,
 	   so we jump there.  */
-	PTR_LA	t0, 0f
-	jr	t0
-0:
+	PTR_LA	t0, 1f
+	bal		1f
+1:	move	t1, ra
+	PTR_LI	t2, PC_REGION_MASK
+	and		t0, t2
+	PTR_LI	t2, ~PC_REGION_MASK
+	and		t1, t2
+	or		t0, t1
+	PTR_ADDIU	t0, 2f-1b
+	jr		t0
+2:

 	PTR_LA		t0, __bss_start		# clear .bss
 	LONG_S		zero, (t0)
-- 
2.1.0