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: > > On Thu, Jun 9, 2016 at 9:14 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > 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