linux-kernel - Re: [PATCH 0/2] make kASLR vs hibernation boot-time selectable

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]

Date:	Sat, 14 Jun 2014 00:37:49 -0700
From:	Kees Cook <keescook@...omium.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Pavel Machek <pavel@....cz>, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>, Len Brown <len.brown@...el.com>,
	Wei Yongjun <yongjun_wei@...ndmicro.com.cn>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/2] make kASLR vs hibernation boot-time selectable

On Fri, Jun 13, 2014 at 5:39 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Friday, June 13, 2014 05:08:21 PM Kees Cook wrote:
>> On Fri, Jun 13, 2014 at 5:14 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> > On Friday, June 13, 2014 03:59:57 PM Kees Cook wrote:
>> >> On Fri, Jun 13, 2014 at 3:54 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> >> > On Friday, June 13, 2014 03:07:19 PM Kees Cook wrote:
>> >
>> > [cut]
>> >
>> >> > I'll have a closer look at that shortly (it's been quite some time since
>> >> > I wrote that code).
>> >>
>> >> Thanks; I'm trying to get a test environment instrumented too so I can
>> >> look at this. (At the very least, it sounds like we'll still need my
>> >> patch series for other architectures.)
>> >
>> > How can I obtain a kernel address of the beginning of a given page
>> > (as represented by struct page) on x86_64 today?
>>
>> I don't know off the top of my head. I've used virt_to_phys, but
>> things like PFN_PHYS(page_to_pfn(page)) maybe? I'm not entirely clear
>> which you need, but mm.h seems to have the bulk of what I've seen.
>
> OK, I'm not sure how much sense this makes, but at least it should
> illustrate the direction. :-)
>
> ---
>  arch/x86/power/hibernate_64.c |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> Index: linux-pm/arch/x86/power/hibernate_64.c
> ===================================================================
> --- linux-pm.orig/arch/x86/power/hibernate_64.c
> +++ linux-pm/arch/x86/power/hibernate_64.c
> @@ -115,7 +115,7 @@ struct restore_data_record {
>         unsigned long magic;
>  };
>
> -#define RESTORE_MAGIC  0x0123456789ABCDEFUL
> +#define RESTORE_MAGIC  0x0123456789ABCDF0UL
>
>  /**
>   *     arch_hibernation_header_save - populate the architecture specific part
> @@ -128,7 +128,8 @@ int arch_hibernation_header_save(void *a
>
>         if (max_size < sizeof(struct restore_data_record))
>                 return -EOVERFLOW;
> -       rdr->jump_address = restore_jump_address;
> +
> +       rdr->jump_address = virt_to_phys((void *)restore_jump_address);
>         rdr->cr3 = restore_cr3;
>         rdr->magic = RESTORE_MAGIC;
>         return 0;
> @@ -143,7 +144,7 @@ int arch_hibernation_header_restore(void
>  {
>         struct restore_data_record *rdr = addr;
>
> -       restore_jump_address = rdr->jump_address;
> +       restore_jump_address = (unsigned long)phys_to_virt(rdr->jump_address);
>         restore_cr3 = rdr->cr3;
>         return (rdr->magic == RESTORE_MAGIC) ? 0 : -EINVAL;
>  }
>

Hrm, well, at least for me, it doesn't look to be that simple. I tried
phys_to_virt, page_to_virt, and pfn_to_virt -- but it always fell
over. Is jump_address page aligned? Does the translation happen after
the image page tables have been flushed?

It seems to me like we do actually want to virtual address, so this
should already work without changes -- we want the image's expected
entry point, which has already been read out of the saved image? I
suspect there's some other assumption in the code that isn't jumping
out at me yet.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/