All of lore.kernel.org
 help / color / mirror / Atom feed
From: matthias.bgg@gmail.com (Matthias Brugger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
Date: Fri, 12 Feb 2016 21:10:29 +0100	[thread overview]
Message-ID: <56BE3C35.7070608@gmail.com> (raw)
In-Reply-To: <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>



On 12/02/16 20:47, Ard Biesheuvel wrote:
> On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg@gmail.com> wrote:
>> Hi Ard,
>>
>>
>> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>>
>>> At the request of Catalin, this series has been split off from my series
>>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>>> moving the kernel out of the linear mapping into the vmalloc area. This
>>> is a prerequisite for independent physical and virtual randomization of
>>> the kernel image. On top of that, considering that these changes allow
>>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
>>> should be an improvement in itself due to the fact that we can now choose
>>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>>
>>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
>>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
>>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
>>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>>>    __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
>>> quantity that allows efficient mapping.
>>>
>>> Note that of the entire KASLR series, this sub-series is the most likely
>>> to
>>> cause problems, and hence requires the most careful review and testing.
>>> This
>>> is due to the fact that, with these changes, the invariant __va(__pa(x))
>>> == x
>>> no longer holds, and any code that is based on that assumption needs to be
>>> updated.
>>>
>>> Changes since v4:
>>> - added Marc's ack to patch #6
>>> - round the kasan zero shadow region around the kernel image to swapper
>>> block
>>>     size (#7)
>>> - ensure that we don't clip the kernel image when clipping RAM to the
>>> linear
>>>     region size (#8)
>>>
>>> Patch #1 allows the low mark of memblocks discovered from the FDT to be
>>> overridden by the architecture.
>>>
>>> Patch #2 enables the huge-vmap generic feature for arm64. This should be
>>> an
>>> improvement in itself, but the significance for this series is that it
>>> allows
>>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>>> region,
>>> which may be partially mapped using block mappings.
>>>
>>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
>>> decoupling the kernel placement from PAGE_OFFSET
>>>
>>> Patch #4 implements some translation table accessors that operate on
>>> statically
>>> allocate translation tables before the linear mapping is up.
>>>
>>> Patch #5 decouples the fixmap initialization from the linear mapping, by
>>> using
>>> the accessors implemented by patch #4
>>>
>>> Patch #6 removes assumptions made my KVM regarding the placement of the
>>> kernel
>>> image inside the linear mapping.
>>>
>>> Patch #7 moves the kernel image from the base of the linear mapping to the
>>> base
>>> of the vmalloc area. The modules area, which sits right below the kernel
>>> image,
>>> is moved along and is put right before the start of the vmalloc area.
>>>
>>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
>>> mapping
>>> to cover all discovered memory, regardless of where the kernel image is
>>> located
>>> in it. This effectively allows the kernel to be loaded at any physical
>>> address
>>> (provided that the correct alignment is used)
>>>
>>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>>
>>> Ard Biesheuvel (8):
>>>     of/fdt: make memblock minimum physical address arch configurable
>>>     arm64: add support for ioremap() block mappings
>>>     arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>>     arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>     arm64: decouple early fixmap init from linear mapping
>>>     arm64: kvm: deal with kernel symbols outside of linear mapping
>>>     arm64: move kernel image to base of vmalloc area
>>>     arm64: allow kernel Image to be loaded anywhere in physical memory
>>>
>>
>> I bisected linux-next (20160212) with the following error on booting with an
>> initramfs:
>>   Failed to execute /init (error -8)
>>   request_module: runaway loop modprobe binfmt-464c
>>   Starting init: /sbin/init exists but couldn't execute it (error -8)
>>   request_module: runaway loop modprobe binfmt-464c
>>   Starting init: /bin/sh exists but couldn't execute it (error -8)
>>   Kernel panic - not syncing: No working init found.  Try passing init=
>> option to kernel. See Linux Documentation/init..
>>
>> I tracked down the error to patch 7 of this series. But I realized that
>> patch 7 does not compile, but from patch 8 onwards I observe the error.
>>
>> I use defconfig with an initramfs.cpio created with buildroot.
>> I tested this on my mt8173 eval board, but I suppose this can be reproduced
>> easily on other machines as well.
>>
>
> Thanks for the report. Does this help at all?
>
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645
>

I applied them on top of linux-next and this fixed the problem.

Thanks,
Matthias

>> Regards,
>> Matthias
>>
>>
>>>    Documentation/arm64/booting.txt                      |  20 ++-
>>>    Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>>>    arch/arm/include/asm/kvm_asm.h                       |   2 +
>>>    arch/arm/kvm/arm.c                                   |   8 +-
>>>    arch/arm64/Kconfig                                   |   1 +
>>>    arch/arm64/include/asm/boot.h                        |   6 +
>>>    arch/arm64/include/asm/kasan.h                       |   2 +-
>>>    arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>>>    arch/arm64/include/asm/kvm_asm.h                     |   2 +
>>>    arch/arm64/include/asm/kvm_host.h                    |   8 +-
>>>    arch/arm64/include/asm/memory.h                      |  44 ++++--
>>>    arch/arm64/include/asm/pgtable.h                     |  23 ++-
>>>    arch/arm64/kernel/head.S                             |   8 +-
>>>    arch/arm64/kernel/image.h                            |  13 +-
>>>    arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>>>    arch/arm64/kvm/hyp.S                                 |   6 +-
>>>    arch/arm64/mm/dump.c                                 |  12 +-
>>>    arch/arm64/mm/init.c                                 | 123
>>> ++++++++++++++--
>>>    arch/arm64/mm/kasan_init.c                           |  31 +++-
>>>    arch/arm64/mm/mmu.c                                  | 155
>>> +++++++++++++++-----
>>>    drivers/of/fdt.c                                     |   5 +-
>>>    21 files changed, 378 insertions(+), 109 deletions(-)
>>>
>>

  reply	other threads:[~2016-02-12 20:10 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 10:54 [PATCH v5sub1 0/8] arm64: split linear and kernel mappings Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 1/8] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings Ard Biesheuvel
2016-02-01 14:10   ` Mark Rutland
2016-02-01 14:56     ` Catalin Marinas
2016-02-01 10:54 ` [PATCH v5sub1 3/8] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 4/8] arm64: pgtable: implement static [pte|pmd|pud]_offset variants Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 5/8] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 6/8] arm64: kvm: deal with kernel symbols outside of " Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2016-02-01 12:24   ` Catalin Marinas
2016-02-01 12:27     ` Ard Biesheuvel
2016-02-01 13:41       ` Catalin Marinas
2016-02-01 14:32   ` Mark Rutland
2016-02-12 14:58   ` Catalin Marinas
2016-02-12 15:02     ` Ard Biesheuvel
2016-02-12 15:10       ` Catalin Marinas
2016-02-12 15:17         ` Ard Biesheuvel
2016-02-12 15:26           ` Catalin Marinas
2016-02-12 15:38             ` Sudeep Holla
2016-02-12 16:06               ` Catalin Marinas
2016-02-12 16:44                 ` Ard Biesheuvel
2016-02-15 14:28                 ` Andrey Ryabinin
2016-02-15 14:35                   ` Mark Rutland
2016-02-15 18:59                   ` Catalin Marinas
2016-02-16 12:59                     ` Andrey Ryabinin
2016-02-16 14:12                       ` Mark Rutland
2016-02-16 14:29                         ` Mark Rutland
2016-02-16 15:17                       ` Ard Biesheuvel
2016-02-16 15:36                         ` Andrey Ryabinin
2016-02-16 16:42                           ` Mark Rutland
2016-02-17  9:15                             ` Andrey Ryabinin
2016-02-17 10:10                               ` James Morse
2016-02-17 10:19                                 ` Catalin Marinas
2016-02-17 10:36                                   ` Catalin Marinas
2016-02-17 10:18                               ` Catalin Marinas
2016-02-17 10:48                                 ` Mark Rutland
2016-02-17 14:39                       ` Mark Rutland
2016-02-17 16:31                         ` Andrey Ryabinin
2016-02-17 19:35                           ` Mark Rutland
2016-02-17 17:01                         ` KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area) Mark Rutland
2016-02-17 17:56                           ` Mark Rutland
2016-02-17 19:16                             ` Mark Rutland
2016-02-18  8:06                               ` Ard Biesheuvel
2016-02-18  8:22                               ` KASAN issues with idle / hotplug area Andrey Ryabinin
2016-02-18  8:42                                 ` Andrey Ryabinin
2016-02-18  9:38                                 ` Andrey Ryabinin
2016-02-18 11:34                                   ` Mark Rutland
2016-02-18  9:39                                 ` Lorenzo Pieralisi
2016-02-18 11:38                                   ` Mark Rutland
2016-02-18 11:45                                   ` Andrey Ryabinin
2016-02-18 11:15                                 ` Mark Rutland
2016-02-18 11:46                                   ` Andrey Ryabinin
2016-02-18 12:08                                     ` Mark Rutland
2016-02-12 17:47   ` [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area James Morse
2016-02-12 18:01     ` Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2016-02-01 14:50   ` Mark Rutland
2016-02-01 16:28     ` Fu Wei
2016-02-16  8:55       ` Fu Wei
2016-02-01 15:06   ` Catalin Marinas
2016-02-01 15:13     ` Ard Biesheuvel
2016-02-01 16:31       ` Ard Biesheuvel
2016-02-01 17:31         ` Catalin Marinas
2016-02-01 17:57           ` Ard Biesheuvel
2016-02-01 18:02             ` Catalin Marinas
2016-02-01 18:30               ` [PATCH] arm64: move back to generic memblock_enforce_memory_limit() Ard Biesheuvel
2016-02-02 10:19                 ` Catalin Marinas
2016-02-02 10:28                   ` Ard Biesheuvel
2016-02-02 10:44                     ` Catalin Marinas
2016-02-12 19:45 ` [PATCH v5sub1 0/8] arm64: split linear and kernel mappings Matthias Brugger
2016-02-12 19:47   ` Ard Biesheuvel
2016-02-12 20:10     ` Matthias Brugger [this message]
2016-02-12 20:37       ` Ard Biesheuvel
2016-02-13 14:28       ` Ard Biesheuvel
2016-02-15 13:29         ` Matthias Brugger
2016-02-15 13:40           ` Will Deacon
2016-02-15 14:58           ` Ard Biesheuvel

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=56BE3C35.7070608@gmail.com \
    --to=matthias.bgg@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.