[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0aNoU693ft3pHCPJOcGubZ1dMFyOmWozO0N_8-F_JkLQ@mail.gmail.com>
Date: Tue, 21 Dec 2021 10:15:59 +0100
From: Arnd Bergmann <arnd@...db.de>
To: cuigaosheng <cuigaosheng1@...wei.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
Andrew Lunn <andrew@...n.ch>,
Gregory CLEMENT <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Viresh Kumar <vireshk@...nel.org>,
Shiraz Hashim <shiraz.linux.kernel@...il.com>,
SoC Team <soc@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Ard Biesheuvel <ardb@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES"
<linux-samsung-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
gongruiqi1@...wei.com, wangweiyang2@...wei.com
Subject: Re: [PATCH -next 0/3] replace open coded VA->PA calculation
On Tue, Dec 21, 2021 at 2:41 AM cuigaosheng <cuigaosheng1@...wei.com> wrote:
>
> > I could apply them directly with the maintainer Acks, but I don't understand
> > the significance of you sending them now. Is something broken without the
> > three patches? Are these the only ones missing from Ard's original series,
> > or is this preparation? Would you expect the patches to get backported to
> > stable kernels?
>
> Thanks for your reply.
>
> This is preparation work for arm32 kaslr,and I want to continue to improve
> the solution based on the work of Ard. These patches are relatively
> independent, so I submit these patches first.
The approach of merging support incrementally is good in principle, but in this
case I think we first need to agree on the overall direction first.
How far have you
come rebasing Ard's patches, do you have KASLR working yet? This is information
that should go into the [PATCH 0/3] cover letter.
Do you have a particular target platform in mind?
I think for CPUs that can use LPAE, we want to eventually move to the 4G:4G
memory model, which in turn depends on having the kernel in vmalloc space, as
implemented by Linus Walleij in
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.14-rc1
With this work, the randomization will look quite different, on the one hand it
leaves less room for relocating the kernel within the smaller 256MB vmalloc
space, while on the other hand it does open the possibility of complete
randomization by scrambling the virt-to-phys mapping in vmalloc space,
using linear virtual addresses to refer to a randomized set of
physical addresses.
(this is just a wild idea that one could implement, nobody has actual plans for
it at the moment, and it comes with additional runtime overhead).
Arnd
Powered by blists - more mailing lists