From: Baoquan He <bhe@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, x86@kernel.org, ak@linux.intel.com,
ebiederm@xmission.com, kexec@lists.infradead.org,
whissi@whissi.de, kumagai-atsushi@mxc.nes.nec.co.jp,
stable@vger.kernel.org
Subject: Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed
Date: Tue, 28 Oct 2014 13:04:48 +0800 [thread overview]
Message-ID: <20141028050448.GB15783@dhcp-16-105.nay.redhat.com> (raw)
In-Reply-To: <20141015033701.GD16068@dhcp-16-116.nay.redhat.com>
On 10/15/14 at 11:37am, Baoquan He wrote:
> On 10/14/14 at 08:49am, Vivek Goyal wrote:
> > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> > > Agreed. On x86_64, we should be able to randomize virtual address space
> > > and physical address space independently. And in that case whole of
> > > the physical memory should be available for a possible location for
> > > kernel. (As opposed to a small limit (I guess 1GB) now)
>
> It can be done to randomize virtual address space and physical address
> space independently. But limited by the 2G of kernel text mapping and
> module mapping virtual address space, virtual address can be randomized
> in (0x1000000, 1G) range. While physical address can be randomized in
> (0x1000000, 4G) according to the identity mapping of normal kernel. Then
> phys_base still stores an relative value, a different offset than before.
>
> This can be easily implement. One thing is still there's a limit for
> physical addr randomization, only below 4G. So I am wondering if we can
> extend the identify mapping to complete mapping of 48 bit, using 1G page
> frame. This can make physical addr be randomized to anywhere.
>
> So now there may be 3 options:
Hi hpa,
About kaslr, do you have a suggestion or plan? Should we fix bug based
on current code, or any other solutions?
Thanks
Baoquan
>
> 1) Fix this bug in current kaslr. Since when randomize the new kernel
> location in choose_kernel_location(), cmdline options has been checked
> strictly, e.g if nokaslr is specified, it's safe to do the kernel
> location randomization. Then in handle_relocations(), we only need to
> check if the kernel location is changed, comparing with kernel loaded
> addr. If changed, kaslr is done, let's do the relocation handling. If
> not changed, no kaslr id done, just skip the relocation handling like
> before.
>
> 2) randomize the virtual addr space and physical addr space
> independently. But physical addr space must be below 4G.
>
> 3) extend the identity mapping to 48bit of addr space. Then we can
> randomized the virtual addr space in (0x1000000, 1G) and physical addr
> space in (0x1000000, real physical memory end).
>
> If option 3 is doable, it's the best. If not, I think bug fix should be
> better.
>
next prev parent reply other threads:[~2014-10-28 5:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 7:08 [resend Patch v3 1/2] kaslr: check if kernel location is changed Baoquan He
2014-09-30 7:08 ` [resend Patch v3 2/2] export the kernel image size KERNEL_IMAGE_SIZE Baoquan He
2015-02-02 7:32 ` Baoquan He
2015-02-09 20:18 ` Kees Cook
2014-09-30 21:21 ` [resend Patch v3 1/2] kaslr: check if kernel location is changed H. Peter Anvin
2014-10-01 13:52 ` Vivek Goyal
2014-10-08 15:09 ` H. Peter Anvin
2014-10-08 19:27 ` Vivek Goyal
2014-10-11 3:14 ` Baoquan He
2014-10-11 10:34 ` H. Peter Anvin
2014-10-11 12:38 ` Baoquan He
2014-10-11 12:44 ` Baoquan He
2014-10-13 12:52 ` Vivek Goyal
2014-10-13 15:19 ` Vivek Goyal
2014-10-13 15:43 ` H. Peter Anvin
2014-10-13 17:22 ` Vivek Goyal
2014-10-14 12:49 ` Vivek Goyal
2014-10-15 3:37 ` Baoquan He
2014-10-15 20:22 ` Vivek Goyal
2014-10-15 20:32 ` H. Peter Anvin
2014-10-15 23:55 ` Baoquan He
2014-10-15 23:58 ` Baoquan He
2014-10-28 5:04 ` Baoquan He [this message]
2014-10-08 14:40 ` Baoquan He
2015-01-09 2:09 ` 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=20141028050448.GB15783@dhcp-16-105.nay.redhat.com \
--to=bhe@redhat.com \
--cc=ak@linux.intel.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).