From: Baoquan He <bhe@redhat.com>
To: Boris Petkov <bp@suse.de>, keescook@chromium.org
Cc: tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com,
linux-kernel@vger.kernel.org, x86@kernel.org, yinghai@kernel.org,
thgarnie@google.com, kuleshovmail@gmail.com, luto@kernel.org,
mcgrof@kernel.org, anderson@redhat.com, dyoung@redhat.com
Subject: Re: [PATCH v3 1/3] x86/64: Make kernel text mapping always take one whole page table in early boot code
Date: Thu, 5 Jan 2017 11:28:00 +0800 [thread overview]
Message-ID: <20170105032800.GE6937@x1> (raw)
In-Reply-To: <E0D4D4C8-F4BE-437B-B1A4-EE033074FAE7@suse.de>
On 01/04/17 at 03:00pm, Boris Petkov wrote:
> On January 4, 2017 10:37:31 AM GMT+02:00, Baoquan He <bhe@redhat.com> wrote:
> >In early boot code level2_kernel_pgt is used to map kernel text. And
> >its
> >size varies with KERNEL_IMAGE_SIZE and fixed at compiling time. In fact
> >we can make it always take 512 entries of one whole page table, because
> >later function cleanup_highmap will clean up the unused entries. With
> >the
> >help of this change kernel text mapping size can be decided at runtime
> >later, 512M if kaslr is disabled, 1G if kaslr is enabled.
> Question: so why are we even having that distinction? Why aren't we making
> text mapping size 1G by default and be done with it?
Yes, good question, thanks!
Possibly people worry more that no enough space left for kernel modules
mapping whthin 1G, just a guess. I am fine with making text mapping size
1G by default. Kees must know more about the 1G only if kaslr enabled.
Hi Kees,
Could you help check if there is any risk making kernel mapping size 1G by
default as Boris suggested?
Thanks
Baoquan
next prev parent reply other threads:[~2017-01-05 3:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 8:37 [PATCH v3 0/3] Determine kernel image mapping size at runtime for x86_64 Baoquan He
2017-01-04 8:37 ` [PATCH v3 1/3] x86/64: Make kernel text mapping always take one whole page table in early boot code Baoquan He
2017-01-04 13:00 ` Boris Petkov
2017-01-05 3:28 ` Baoquan He [this message]
2017-01-05 14:01 ` Borislav Petkov
2017-01-05 19:35 ` Kees Cook
2017-01-05 20:52 ` Borislav Petkov
2017-01-06 9:35 ` Baoquan He
2017-01-04 8:37 ` [PATCH v3 2/3] x86/64: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He
2017-01-04 8:37 ` [PATCH v3 3/3] x86/64/KASLR: Determine the kernel mapping size at run time 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=20170105032800.GE6937@x1 \
--to=bhe@redhat.com \
--cc=anderson@redhat.com \
--cc=bp@suse.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kuleshovmail@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mcgrof@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;
as well as URLs for NNTP newsgroup(s).