Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1572338 > unrolled thread

[PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally

Back to article view | Back to linux.kernel

Contents

  [PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally Baoquan He <bhe@redhat.com> - 2017-02-02 14:00 +0100
    Re: [PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally Kees Cook <keescook@chromium.org> - 2017-02-02 20:50 +0100

#1572338 — [PATCH v4 0/3] x86/64/KASLR: Change kernel mapping size to 1G unconditionally

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

[toc] | [next] | [standalone]

#1572709

On Thu, Feb 2, 2017 at 4:54 AM, Baoquan He <bhe@redhat.com> 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.

This looks good to me.

Reviewed-by: Kees Cook <keescook@chromium.org>

-Kees

>
> 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
>



-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web