From: Baoquan He <bhe@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Vivek Goyal <vgoyal@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
lasse.collin@tukaani.org,
Andrew Morton <akpm@linux-foundation.org>,
Dave Young <dyoung@redhat.com>
Subject: Re: [PATCH v3 16/19] x86, kaslr: Randomize physical and virtual address of kernel separately
Date: Wed, 9 Mar 2016 21:40:09 +0800 [thread overview]
Message-ID: <20160309134009.GC2555@x1.redhat.com> (raw)
In-Reply-To: <CAGXu5j+bBFekt9sZ1zxgrnqKfQdn5SBV5wQV=c2Ct6c0ZdXR_Q@mail.gmail.com>
On 03/08/16 at 10:24am, Kees Cook wrote:
> On Mon, Mar 7, 2016 at 9:34 PM, Baoquan He <bhe@redhat.com> wrote:
> >> It seems like CONFIG_RANDOMIZE_BASE_MAX_OFFSET should have been
> >> eliminated when the on-demand page table code was added. Once that was
> >> added, there's no physical max any more. And virtual randomization
> >> should have no max at all.
> > For physically random, yes, CONFIG_RANDOMIZE_BASE_MAX_OFFSET is not
> > needed anymore. But for virtually random,
> > CONFIG_RANDOMIZE_BASE_MAX_OFFSET is still mandatory since kernel text
> > mapping and kernel module mapping share the 2G virtual address space as
> > follows. Though kaslr increase kernel text mapping from 512M to 1G, it's
> > still limited, can't exceed CONFIG_RANDOMIZE_BASE_MAX_OFFSET.
> >
> > [0xffffffff80000000, 0xffffffffffffffff]
> >
> > But now as you suggested, I would like to change
> > CONFIG_RANDOMIZE_BASE_MAX_OFFSET to another name because it's only
> > valid for virtual randomization. A more specific name is better.
>
> Yes, right, the virtual has a 1G max, but I meant that it doesn't need
> to be a CONFIG item any more. Physical can use physical memory max as
> its max, and virtual max can now be calculated from the existing text
> mapping size.
Got it, it should be KERNEL_IMAGE_SIZE instead, right?
next prev parent reply other threads:[~2016-03-09 13:40 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 16:24 [PATCH v3 00/19] x86, boot: kaslr cleanup and 64bit kaslr support Baoquan He
2016-03-04 16:24 ` [PATCH v3 01/19] x86, kaslr: Remove not needed parameter for choose_kernel_location Baoquan He
2016-03-07 22:28 ` Kees Cook
2016-03-04 16:25 ` [PATCH v3 02/19] x86, boot: Move compressed kernel to end of buffer before decompressing Baoquan He
2016-03-07 22:35 ` Kees Cook
2016-03-08 4:50 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 03/19] x86, boot: Move z_extract_offset calculation to header.S Baoquan He
2016-03-04 16:25 ` [PATCH v3 04/19] x86, kaskr: Update the description for decompressor worst case Baoquan He
2016-03-04 16:25 ` [PATCH v3 05/19] x86, boot: Fix run_size calculation Baoquan He
2016-03-07 23:10 ` Kees Cook
2016-03-08 4:57 ` Baoquan He
2016-03-08 18:05 ` Kees Cook
2016-03-04 16:25 ` [PATCH v3 06/19] x86, kaslr: Clean up useless code related to run_size Baoquan He
2016-03-07 23:12 ` Kees Cook
2016-03-08 5:00 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 07/19] x86, kaslr: Get correct max_addr for relocs pointer Baoquan He
2016-03-07 23:16 ` Kees Cook
2016-03-08 5:13 ` Baoquan He
2016-03-08 18:16 ` Kees Cook
2016-03-09 13:46 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 08/19] x86, kaslr: Consolidate mem_avoid array filling Baoquan He
2016-03-07 23:28 ` Kees Cook
2016-03-08 5:21 ` Baoquan He
2016-03-08 18:17 ` Kees Cook
2016-03-09 13:42 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 09/19] x86, boot: Split kernel_ident_mapping_init to another file Baoquan He
2016-03-04 16:25 ` [PATCH v3 10/19] x86, 64bit: Set ident_mapping for kaslr Baoquan He
2016-03-07 23:34 ` Kees Cook
2016-03-08 5:25 ` Baoquan He
2016-03-21 7:50 ` Baoquan He
2016-03-21 19:48 ` Kees Cook
2016-03-04 16:25 ` [PATCH v3 11/19] x86, boot: Add checking for memcpy Baoquan He
2016-03-07 23:36 ` Kees Cook
2016-03-08 5:30 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 12/19] x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G Baoquan He
2016-03-07 23:30 ` Kees Cook
2016-03-08 5:22 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 13/19] x86, kaslr: Introduce struct slot_area to manage randomization slot info Baoquan He
2016-03-04 16:25 ` [PATCH v3 14/19] x86, kaslr: Add two functions which will be used later Baoquan He
2016-03-04 16:25 ` [PATCH v3 15/19] x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text mapping address Baoquan He
2016-03-04 16:25 ` [PATCH v3 16/19] x86, kaslr: Randomize physical and virtual address of kernel separately Baoquan He
2016-03-07 23:51 ` Kees Cook
2016-03-08 5:34 ` Baoquan He
2016-03-08 18:24 ` Kees Cook
2016-03-09 13:40 ` Baoquan He [this message]
2016-03-09 18:07 ` Kees Cook
2016-03-10 15:15 ` Baoquan He
2016-03-04 16:25 ` [PATCH v3 17/19] x86, kaslr: Add support of kernel physical address randomization above 4G Baoquan He
2016-03-04 16:25 ` [PATCH v3 18/19] x86, kaslr: Remove useless codes Baoquan He
2016-03-04 16:25 ` [PATCH v3 19/19] x86, kaslr: Allow random address to be below loaded address Baoquan He
2016-03-05 11:35 ` [PATCH v3 00/19] x86, boot: kaslr cleanup and 64bit kaslr support 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=20160309134009.GC2555@x1.redhat.com \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=lasse.collin@tukaani.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=vgoyal@redhat.com \
--cc=yinghai@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.