From: Andy Lutomirski <luto@amacapital.net>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com,
x86@kernel.org, keescook@chromium.org, vgoyal@redhat.com,
whissi@whissi.de
Subject: Re: [PATCH 0/6] randomize kernel physical address and virtual address separately
Date: Tue, 20 Jan 2015 20:19:36 -0800 [thread overview]
Message-ID: <54BF28D8.70107@amacapital.net> (raw)
In-Reply-To: <1421811437-2787-1-git-send-email-bhe@redhat.com>
On 01/20/2015 07:37 PM, Baoquan He wrote:
> Currently kaslr only randomize physical address of kernel loading, then add the delta
> to virtual address of kernel text mapping. Because kernel virtual address can only be
> from __START_KERNEL_map to LOAD_PHYSICAL_ADDR+CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely
> [0xffffffff80000000, 0xffffffffc0000000], so physical address can only be randomized
> in region [LOAD_PHYSICAL_ADDR, CONFIG_RANDOMIZE_BASE_MAX_OFFSET], namely [16M, 1G].
>
> So hpa and Vivek suggested the randomization should be done separately for both physical
> and virtual address. In this patchset I tried it. And after randomization, relocation
> handling only depends on virtual address changing, means I only check whether virtual
> address is randomized to other position, if yes relocation need be handled, if no just
> skip the relocation handling though physical address is randomized to different place.
> Now physical address can be randomized from 16M to 4G, virtual address offset can be
> from 16M to 1G.
>
> Leftover problem:
> hpa want to see the physical randomization can cover the whole physical memory. I
> checked code and found it's hard to do. Because in arch/x86/boot/compressed/head_64.S
> an identity mapping of 4G is built and then kaslr and decompressing are done. The #PF
> handler solution which he suggested is only available after jump into decompressed
> kernel, namely in arch/x86/kernel/head_64.S. I didn't think of a way to do the whole
> memory covering for physical address randomization, any suggestion or idea?
>
I have no idea what the #PF thing you're referring to is, but I have
code to implement a #PF handler in boot/compressed if it would be
helpful. It's two patches:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=sync_rand_seed&id=89476ea6a2becbaee4f45c3b6689ff31b6aa959a
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=sync_rand_seed&id=142d86921e6f271261584016fc8cfa5cdbf455ba
You can't recover from a page fault in my version of this code, but that
would be straightforward to add.
--Andy
next prev parent reply other threads:[~2015-01-21 4:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 3:37 [PATCH 0/6] randomize kernel physical address and virtual address separately Baoquan He
2015-01-21 3:37 ` [PATCH 1/6] remove a unused function parameter Baoquan He
2015-01-21 3:37 ` [PATCH 2/6] a bug that relocation can not be handled when kernel is loaded above 2G Baoquan He
2015-01-21 3:37 ` [PATCH 3/6] Introduce a function to randomize the kernel text mapping address Baoquan He
2015-01-21 3:37 ` [PATCH 4/6] adapt choose_kernel_location to add the kernel virtual address randomzation Baoquan He
2015-01-21 3:37 ` [PATCH 5/6] change the relocations behavior for kaslr on x86_64 Baoquan He
2015-01-21 3:37 ` [PATCH 6/6] extend the upper limit of kernel physical address randomization to 4G Baoquan He
2015-01-21 4:19 ` Andy Lutomirski [this message]
2015-01-21 4:46 ` [PATCH 0/6] randomize kernel physical address and virtual address separately Baoquan He
2015-02-01 8:10 ` Baoquan He
2015-02-01 13:13 ` Andy Lutomirski
2015-02-02 9:34 ` Baoquan He
2015-02-02 12:10 ` Baoquan He
2015-01-21 6:18 ` Kees Cook
2015-02-02 16:42 ` H. Peter Anvin
2015-02-03 15:30 ` Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54BF28D8.70107@amacapital.net \
--to=luto@amacapital.net \
--cc=bhe@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=whissi@whissi.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.