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-next>] [day] [month] [year] [list]
Message-Id: <20060821095328.3132.40575.sendpatchset@cherry.local>
Date:	Mon, 21 Aug 2006 18:54:16 +0900 (JST)
From:	Magnus Damm <magnus@...inux.co.jp>
To:	fastboot@...ts.osdl.org, linux-kernel@...r.kernel.org
Cc:	Magnus Damm <magnus@...inux.co.jp>, ebiederm@...ssion.com,
	ak@...e.de
Subject: [PATCH][RFC] x86_64: Reload CS when startup_64 is used.

x86_64: Reload CS when startup_64 is used.

The current x86_64 startup code never reloads CS during the early boot process
if the 64-bit function startup_64 is used as entry point. The 32-bit entry 
point startup_32 does the right thing and reloads CS, and this is what most 
people are using if they use bzImage.

This patch fixes the case when the Linux kernel is booted into using kexec
under Xen. The Xen hypervisor is using large CS values which makes the x86_64
kernel fail - but only if vmlinux is booted, bzImage works well because it
is using the 32-bit entry point.

The main question is if we require that the boot loader should setup CS
to some certain offset to be able to boot the kernel. The sane solution IMO
should be that the kernel requires that the loaded descriptors are correct, 
but that the exact offset within the GDT the boot loader is using should not 
matter. This is the way the i386 boot works if I understand things correctly.

Signed-off-by: Magnus Damm <magnus@...inux.co.jp>
---

 Applies on top of 2.6.18-rc4

 head.S |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

--- 0001/arch/x86_64/kernel/head.S
+++ work/arch/x86_64/kernel/head.S	2006-08-21 18:22:57.000000000 +0900
@@ -165,6 +165,25 @@ startup_64:
 	 */
 	lgdt	cpu_gdt_descr
 
+	/* Reload CS with a value that is within our GDT. We need to do this
+	 * if we were loaded by a 64 bit bootloader that happened to use a 
+	 * CS that is larger than the GDT limit. This is true if we came here
+	 * from kexec running under Xen.
+	 */
+	movq	%rsp, %rdx
+	movq	$__KERNEL_DS, %rax
+	pushq	%rax /* SS */
+	pushq	%rdx /* RSP */
+	movq	$__KERNEL_CS, %rax
+	movq	$cs_reloaded, %rdx
+	pushq	%rax /* CS */
+	pushq	%rdx /* RIP */
+	lretq
+	
+cs_reloaded:			
+	/* Setup the boot time stack again */
+	movq init_rsp(%rip),%rsp
+	
 	/* 
 	 * Setup up a dummy PDA. this is just for some early bootup code
 	 * that does in_interrupt() 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ