On Friday, June 10, 2016 11:27:29 PM Rafael J. Wysocki wrote:

On Friday, June 10, 2016 11:09:22 AM Kees Cook wrote:

quoted

On Thu, Jun 9, 2016 at 9:14 PM, Logan Gunthorpe [off-list ref] wrote:

quoted

Hey,

I've still be trying to figure this out as I have time.

I tried printing a couple restore addresses and nothing I can find seems
anywhere near the rodata/ex_table boundary.

I tried with the (badly formatted) below and got the following. Nothing too
surprising. I've attached a kallsyms that matches the kernel for reference.

restore_code: ffff880157c3b000
jump_addr: ffffffff81446be0

diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index 009947d..6efedb7 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c

@@ -92,6 +92,9 @@ int swsusp_arch_resume(void)
        memcpy(relocated_restore_code, &core_restore_code,
               &restore_registers - &core_restore_code);

+       pr_info("restore_code: %p\n", relocated_restore_code);
+       pr_info("jump_addr: %lx\n", restore_jump_address);
+

Also interesting would be the "relocated_restore_code" address, as
well as a dump of /sys/kernel/debug/kernel_page_tables (from
CONFIG_X86_PTDUMP).

I'm baffled by the problem, but the best I can understand is the the
relocated_restore_code range isn't executable (which should be visible
from finding it in /sys/kernel/debug/kernel_page_tables), but I don't
see how to solve that since my original patch didn't work.

Rafael, is this something you have time to look at quickly?

Well, not really, but I'll do my best to look at it in the next few days.

OK, I have a theory, but I need a bit of help.

This may be a dumb question, but I don't quite remember the answer readily.

Given a physical address, how do I get the corresponding virtual one under
the kernel identity mapping?

Thanks,
Rafael