linux-kernel - [PATCH 4/4] xen/acpi: Prep saved

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: <1350481786-4969-5-git-send-email-konrad.wilk@oracle.com>
Date:	Wed, 17 Oct 2012 09:49:46 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	lenb@...nel.org, linux-acpi@...r.kernel.org, hpa@...or.com,
	x86@...nel.org
Cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: [PATCH 4/4] xen/acpi: Prep saved_context cr3 values.

When save_processor_state is executed it executes a bunch of
pvops calls to save the CPU state values. When it comes back
from Xen's S3 (so acpi_enter_sleep_state, which ends up calling
xen_acpi_notify_hypervisor_state), it ends up back in the
assembler code in wakeup_[32|64].S. It skips the wakeup
calls (so wakeup_pmode_return and wakeup_long64) as that has
been done in the hypervisor. Instead it continues on in
the resume_point (64-bit) or ret_point (32-bit). Most of the
calls in there are safe to be executed except when it comes to
reloading of cr3 (which it only does on 64-bit kernels). Since
they are native assembler calls and Xen expects a PV kernel to
prep those to use machine address for cr3 that is what
we are going to do. Note: that it is not Machine Frame Numbers
(those are used in the MMUEXT_NEW_BASEPTR hypercall for cr3
installation) but the machine physical address.

When the assembler code executes this mov %ebx, cr3 it ends
end up trapped in the hypervisor (traps.c) which properly now
sets the cr3 value.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
---
 drivers/xen/acpi.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/acpi.c b/drivers/xen/acpi.c
index 119d42a..25e612c 100644
--- a/drivers/xen/acpi.c
+++ b/drivers/xen/acpi.c
@@ -35,6 +35,13 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>

+#include <xen/page.h>
+
+#ifdef CONFIG_X86_64
+#include <asm/suspend_64.h>
+extern struct saved_context saved_context;
+#endif
+
 int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 				     u32 pm1a_cnt, u32 pm1b_cnt)
 {
@@ -56,7 +63,25 @@ int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 		     pm1a_cnt, pm1b_cnt);
 		return -1;
 	}
+#ifdef CONFIG_X86_64
+	/* We do not need to anything for 32-bit kernels as the
+	 * low-level calls (write to cr3) is done in the wakup code
+	 * which we never execute when running under Xen.
+	 */
+	{
+		unsigned long mfn;

+		/* resume_point in wakeup_64.s barrels through and does:
+		 * movq    saved_context_cr3(%rax), %rbx
+		 * movq    %rbx, %cr3
+		 * so lets prep the values so they are OK with the
+		 * hypervisor. */
+		mfn = pfn_to_mfn(PFN_DOWN(saved_context.cr3));
+		/* and back to a physical address */
+		mfn = PFN_PHYS(mfn);
+		saved_context.cr3 = mfn;
+	}
+#endif
 	HYPERVISOR_dom0_op(&op);
 	return 1;
 }
-- 
1.7.7.6

--
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/