From: Baoquan He <bhe@redhat.com>
To: tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
keescook@chromium.org, yinghai@kernel.org, bp@suse.de,
thgarnie@google.com, kuleshovmail@gmail.com, luto@kernel.org,
mcgrof@kernel.org, anderson@redhat.com, dyoung@redhat.com,
Baoquan He <bhe@redhat.com>
Subject: [PATCH v3 0/3] Determine kernel image mapping size at runtime for x86_64
Date: Wed, 4 Jan 2017 16:37:30 +0800 [thread overview]
Message-ID: <1483519053-23402-1-git-send-email-bhe@redhat.com> (raw)
Kernel behaviour is inconsistent between KASLR code is not compiled in
with CONFIG_RANDOMIZE_BASE disabled and user specifies "nokaslr" when
KASLR code compiled in with CONFIG_RANDOMIZE_BASE enabled. As long as
CONFIG_RANDOMIZE_BASE is enabled, kernel mapping size will be extended
up another 512M to 1G though "nokaslr" is specified explicitly. This is
buggy. CONFIG_RANDOMIZE_BASE should only decide if KASLR code need be
compiled in. If user specify "nokaslr", the kernel have to behave as no
KASLR code compiled in at all as expected.
The root cause of the inconsistency is the size of kernel image mapping
area is fixed at compiling time, and is changed from 512M to 1G as long
as CONFIG_RANDOMIZE_BASE is enabled.
So in this patchset, change to determine the size of kernel image mapping
area at runtime. Though KASLR code compiled in, if "nokaslr" specified,
still make kernel mapping size be 512M.
v1->v2:
Kbuild test threw build warning because of code bug.
v2->v3:
Boris pointed out patch log is not good for reviewing and understanding.
So split the old patch 2/2 into 2 parts and rewrite the patch log,
patch 2/3 is introducing the new constant KERNEL_MAPPING_SIZE which
differs from the old KERNEL_IMAGE_SIZE, patch 3/3 gets the kernel mapping
size at runtime.
Baoquan He (3):
x86/64: Make kernel text mapping always take one whole page table in
early boot code
x86/64: Introduce a new constant KERNEL_MAPPING_SIZE
x86/64/KASLR: Determine the kernel mapping size at run time
arch/x86/boot/compressed/kaslr.c | 20 +++++++++++++++-----
arch/x86/include/asm/kaslr.h | 1 +
arch/x86/include/asm/page_64_types.h | 20 ++++++++++++--------
arch/x86/include/asm/pgtable_64_types.h | 2 +-
arch/x86/kernel/head64.c | 11 ++++++-----
arch/x86/kernel/head_64.S | 16 +++++++++-------
arch/x86/mm/dump_pagetables.c | 3 ++-
arch/x86/mm/init_64.c | 2 +-
arch/x86/mm/physaddr.c | 6 +++---
9 files changed, 50 insertions(+), 31 deletions(-)
--
2.5.5
next reply other threads:[~2017-01-04 8:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 8:37 Baoquan He [this message]
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
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=1483519053-23402-1-git-send-email-bhe@redhat.com \
--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