From: Baoquan He <bhe@redhat.com>
To: Borislav Petkov <bp@suse.de>
Cc: tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com,
linux-kernel@vger.kernel.org, x86@kernel.org,
keescook@chromium.org, yinghai@kernel.org, anderson@redhat.com,
luto@kernel.org, thgarnie@google.com, kuleshovmail@gmail.com
Subject: Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE
Date: Sun, 26 Feb 2017 12:09:08 +0800 [thread overview]
Message-ID: <20170226040908.GB14810@x1> (raw)
In-Reply-To: <20170214173217.3qtf6fhiklhgsmi5@pd.tnic>
Hi Boris,
Thanks a lot for your comments, sorry so late to reply!
On 02/14/17 at 06:32pm, Borislav Petkov wrote:
> > diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
> > index 9215e05..24c9098 100644
> > --- a/arch/x86/include/asm/page_64_types.h
> > +++ b/arch/x86/include/asm/page_64_types.h
> > @@ -50,16 +50,22 @@
> > #define __VIRTUAL_MASK_SHIFT 47
> >
> > /*
> > - * Kernel image size is limited to 1GiB due to the fixmap living in the
> > + * Kernel image size is limited to 512 MB. The kernel code+data+bss
>
> This is not what it said there before. With your change you have:
>
> - 0
> .
> .
> .
> - 512 - KERNEL_IMAGE_SIZE
> .
> .
> .
> - 1024 - KERNEL_MAPPING_SIZE
>
> and KERNEL_IMAGE_SIZE is not limited to 512Mb but it is "Use 512Mib by
> default". And we do enforce that in various places like in the linker
> script assertions but there's some headroom open in the upper 512Mib if
> needed.
Before below commit merged, it said:
* Kernel image size is limited to 512 MB (see level2_kernel_pgt in
* arch/x86/kernel/head_64.S), and it is mapped here:
*/
#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
commit 6145cfe3 ("x86, kaslr: Raise the maximum virtual address to -1
GiB on x86_64")
So you can see KERNEL_IMAGE_SIZE is a constant value and not optional.
Then Kees posted above commit, The default mentioned in "Use 512Mib by
default" should be KERNEL_IMAGE_SIZE in the case that kaslr code not
compiled in, 512M, which is relative to the case that kaslr code
compiled in, 1G. In fact, it's meaning the kernel mapping size defaults
to 512M, and will change to 1G if CONFIG_RANDOMIZE_BASE is chosen.
Seems in kernel only linker script checks kernel image size as below:
. = ASSERT((_end - _text <= KERNEL_IMAGE_SIZE),
"kernel image bigger than KERNEL_IMAGE_SIZE");
In arch/x86/kernel/head64.c, it's more likely checking the kernel
mapping size, just because they share the same constant,
KERNEL_IMAGE_SIZE.
About headroom, in boot/compressed/kaslr.c kernel iamge size is
considered, including head room. Here I am not quite sure. Do you mean:
KERNEL_IMAGE_SIZE use 512Mib by default, only kerel image size is
limited to 512M which is (_end - _text) since linker script will check
it. While with headroom, it could be bigger than 512M if needed.
Am I right on understanding it?
>
> KERNEL_MAPPING_SIZE OTOH is the one limited to 1G due to the fixmap L2
> PGT...
>
> > + * must not be bigger than that.
> > + */
> > +#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
> > +
> > +/*
> > + * Kernel mapping size is limited to 1GiB due to the fixmap living in the
> > * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
> > * 512MiB by default, leaving 1.5GiB for modules once the page tables
> > * are fully set up. If kernel ASLR is configured, it can extend the
> > * kernel page table mapping, reducing the size of the modules area.
> > */
> > #if defined(CONFIG_RANDOMIZE_BASE)
> > -#define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024)
> > +#define KERNEL_MAPPING_SIZE (1024 * 1024 * 1024)
> > #else
> > -#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
> > +#define KERNEL_MAPPING_SIZE (512 * 1024 * 1024)
> > #endif
>
> ... and since you're adding that define now, fixup the comments in this
> patch too, to explain what they mean.
Yes, agree, this makes it clearer. Will do.
>
> Also, I'd like for the text to say that both defines are dependent in
> the sense that IMAGE_SIZE <= MAPPING_SIZE so that people know what's
> going on and which is which.
It makes sense, will do.
Thanks for great suggestion!
next prev parent reply other threads:[~2017-02-26 4:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 12:54 [PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally Baoquan He
2017-02-02 12:54 ` [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He
2017-02-14 17:32 ` Borislav Petkov
2017-02-26 4:09 ` Baoquan He [this message]
2017-03-03 11:43 ` Borislav Petkov
2017-03-03 12:06 ` Baoquan He
2017-03-03 12:16 ` Borislav Petkov
2017-03-03 12:52 ` Baoquan He
2017-03-03 13:11 ` Baoquan He
2017-03-03 14:28 ` Borislav Petkov
2017-03-03 15:07 ` Baoquan He
2017-03-03 15:08 ` Baoquan He
2017-03-03 15:23 ` Borislav Petkov
2017-03-04 10:10 ` Baoquan He
2017-03-04 11:55 ` Borislav Petkov
2017-03-04 13:59 ` Baoquan He
2017-03-16 8:14 ` Ingo Molnar
2017-03-16 9:44 ` Baoquan He
2017-02-02 12:54 ` [PATCH v4 2/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally Baoquan He
2017-02-02 12:54 ` [PATCH v4 3/3] x86/64/doc: Update the ranges of kernel text and modules mapping Baoquan He
2017-02-02 19:40 ` [PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally Kees Cook
2017-03-04 14:26 ` 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=20170226040908.GB14810@x1 \
--to=bhe@redhat.com \
--cc=anderson@redhat.com \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kuleshovmail@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=x86@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox