Messages in this thread | | | From | Kees Cook <> | Date | Fri, 10 Jun 2016 11:18:47 -0700 | Subject | Re: PROBLEM: Resume form hibernate broken by setting NX on gap |
| |
On Fri, Jun 10, 2016 at 11:16 AM, Logan Gunthorpe <logang@deltatee.com> wrote: > Hey, > > On 10/06/16 12:09 PM, Kees Cook wrote: >>> 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). > > Is that not what I printed? If not, can you give me a better hint as to
Oh, whoops, sorry, I saw "restore_code" in the pr_info and "relocate_restore_code" in the memcpy and didn't scan the right thing in the pr_info line. :)
> what you're looking for so I can spin another kernel? I'll also provide > the kernel_page_tables once I do that.
Cool, thanks.
> >> 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. > > Yeah this is definitely a baffling problem.
-Kees
-- Kees Cook Chrome OS & Brillo Security
| |