All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: mingo@redhat.com
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	keescook@chromium.org, tglx@linutronix.de, hpa@zytor.com,
	yinghai@kernel.org, bp@suse.de, anderson@redhat.com,
	luto@kernel.org, thgarnie@google.com, kuleshovmail@gmail.com
Subject: Re: [PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally
Date: Sat, 4 Mar 2017 22:26:02 +0800	[thread overview]
Message-ID: <20170304142602.GC12083@x1> (raw)
In-Reply-To: <1486040077-3719-1-git-send-email-bhe@redhat.com>

Hi Ingo,

Ping!

Could you please help have a look at thie patchset and give comments or
any suggestion?

Checked the git history, you have been taking care of the
KERNEL_IMAGE_SIZE value changing. Now Kees added his Reviewed-by, Boris 
agreed on setting the size of space for kernel mapping to 1G by default
but he doesn't like the adding KERNEL_MAPPING_SIZE constant idea.

Your suggestion is much appreciated!

Thanks
Baoquan

On 02/02/17 at 08:54pm, Baoquan He wrote:
> This is v4 post.
> 
> In the previous 3 versions I tried to detect and determine kernel image
> mapping size at runtime for x86_64. With this the inconsistency between
> KASLR code is not compiled in by disabling CONFIG_RANDOMIZE_BASE and
> KASLR code is compiled in but add 'nokaslr' kernel option can be fixed.
> 
> When review v3 Boris suggested we should change kernel mapping size to
> 1G directly, but not an option. Kees explained he made kernel mapping
> size as an option mainly because he woried about kernel module space.
> He said it wasn't clear to him at the time if enough space remained for
> modules in all use-cases. Then Boris pointed out that practically kaslr
> will be enabled on the majority of the systems anyway, and the reduction
> of kernel modules mapping space has been there for a while now, if so we
> probably whould've heard complaints already. Kees agreed.
> 
> So in this version of post change kernel mapping size of x86 64 to 1G
> as Boris suggested. Then the inconsistency will naturally disappear.
> 
> And I still keep patch 1/3 which introduces the new constant
> KERNEL_MAPPING_SIZE. And let KERNEL_IMAGE_SIZE stay for restricting kernel
> image size during linking stage.
> 
> 
> v3->v4:
>     Change kernel mapping size to 1G unconditionally as Boris suggested.
> 
> 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.
> 
> v1->v2:
>     Kbuild test threw build warning because of code bug.
> 
> 
> Baoquan He (3):
>   x86: Introduce a new constant KERNEL_MAPPING_SIZE
>   x86/64/KASLR: Change kernel mapping size to 1G unconditionally
>   x86/64/doc: Update the ranges of kernel text and modules mapping
> 
>  Documentation/x86/x86_64/mm.txt         |  4 ++--
>  arch/x86/boot/compressed/kaslr.c        | 10 +++++-----
>  arch/x86/include/asm/page_32_types.h    |  6 ++++++
>  arch/x86/include/asm/page_64_types.h    | 17 ++++++++---------
>  arch/x86/include/asm/pgtable_64_types.h |  2 +-
>  arch/x86/kernel/head64.c                |  4 ++--
>  arch/x86/kernel/head_64.S               | 12 +++++-------
>  arch/x86/kernel/machine_kexec_64.c      |  2 +-
>  arch/x86/mm/init_64.c                   |  2 +-
>  arch/x86/mm/physaddr.c                  |  6 +++---
>  10 files changed, 34 insertions(+), 31 deletions(-)
> 
> -- 
> 2.5.5
> 

      parent reply	other threads:[~2017-03-04 14:26 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
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 [this message]

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=20170304142602.GC12083@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 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.