All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 0/2] arm64: permit KASLR in linear region even VArange == PArange
Date: Thu, 16 Dec 2021 19:32:29 +0800	[thread overview]
Message-ID: <84475e94-368b-1963-1916-4e7870294c80@huawei.com> (raw)
In-Reply-To: <CAMj1kXEMY7J2NL0-sNjUisr_3_1B=Xs78o=QQSJKiTC+mZNVYQ@mail.gmail.com>


On 2021/12/16 16:56, Ard Biesheuvel wrote:
> (+ Marc)
>
> On Thu, 16 Dec 2021 at 08:37, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> On 2021/12/15 22:52, Ard Biesheuvel wrote:
>>> Kefeng reports in [0] that using PArange to size the randomized linear
>>> region offset leads to cases where randomization is no longer possible
>>> even if the actual placement of DRAM in memory would otherwise have
>>> permitted it.
>>>
>>> Instead of using CONFIG_MEMORY_HOTPLUG to choose at build time between
>>> to different behaviors in this regard, let's try addressing this by
>>> reducing the minimum relative aligment between VA and PA in the linear
>>> region, and taking advantage of the space at the base of physical memory
>>> below the first memblock to permit some randomization of the placement
>>> of physical DRAM in the virtual address map.
>> VArange == PArange is ok, but our case is Va=39/Pa=48, this is still not
>> works :(
>>
>> Could we add a way(maybe cmdline) to set max parange, then we could make
>>
>> randomization works, or some other way?
>>
> We could, but it is not a very elegant way to recover this
> randomization range. You would need to reduce the PArange to 36 bits
> (which is the next valid option below 40) in order to ensure that a
> 39-bit VA kernel has some room for randomization, but this would not
> work on many systems because they require 40-bit physical addressing,
> due to the placement of DRAM in the PA space, not the DRAM size.
Yes, cmdline is not elegant, we can't find a better way to fix this.
> Android 5.10 is in the same boat (and needs CONFIG_MEMORY_HOTPLUG=y)
> so I agree we need something better here.

It's not only Android, some embedded system with not too much memory, they

need KASLR/MEMORY_HOTPLUG.


>
>
>
>>> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>
>>> [0] https://lore.kernel.org/linux-arm-kernel/20211104062747.55206-1-wangkefeng.wang@huawei.com/
>>>
>>> Ard Biesheuvel (2):
>>>     arm64: simplify rules for defining ARM64_MEMSTART_ALIGN
>>>     arm64: kaslr: take free space at start of DRAM into account
>>>
>>>    arch/arm64/include/asm/kernel-pgtable.h | 27 +++-----------------
>>>    arch/arm64/mm/init.c                    |  3 ++-
>>>    2 files changed, 6 insertions(+), 24 deletions(-)
>>>
> .

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-12-16 12:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 14:52 [PATCH 0/2] arm64: permit KASLR in linear region even VArange == PArange Ard Biesheuvel
2021-12-15 14:52 ` [PATCH 1/2] arm64: simplify rules for defining ARM64_MEMSTART_ALIGN Ard Biesheuvel
2021-12-15 14:52 ` [PATCH 2/2] arm64: kaslr: take free space at start of DRAM into account Ard Biesheuvel
2021-12-16  7:37 ` [PATCH 0/2] arm64: permit KASLR in linear region even VArange == PArange Kefeng Wang
2021-12-16  8:56   ` Ard Biesheuvel
2021-12-16 11:32     ` Kefeng Wang [this message]
2022-02-15  2:09     ` Kefeng Wang

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=84475e94-368b-1963-1916-4e7870294c80@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=will@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.