linux-arm-kernel.lists.infradead.org archive mirror
 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 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).