mbox series

[-next,0/3] replace open coded VA->PA calculation

Message ID 20211218085843.212497-1-cuigaosheng1@huawei.com
Headers show
Series replace open coded VA->PA calculation | expand

Message

Gaosheng Cui Dec. 18, 2021, 8:58 a.m. UTC
These patches replace an open coded calculation to obtain the physical
address of a far symbol with a call to the new ldr_l etc macro, and they
belong to the kaslr patch set of arm32.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest

Ard Biesheuvel (3):
  arm-soc: exynos: replace open coded VA->PA conversions
  arm-soc: mvebu: replace open coded VA->PA conversion
  arm-soc: various: replace open coded VA->PA calculation

 arch/arm/mach-exynos/headsmp.S     |  9 +--------
 arch/arm/mach-exynos/sleep.S       | 26 +++++---------------------
 arch/arm/mach-mvebu/coherency_ll.S |  8 +-------
 arch/arm/mach-spear/headsmp.S      | 11 +++--------
 arch/arm/plat-versatile/headsmp.S  |  9 +--------
 5 files changed, 11 insertions(+), 52 deletions(-)

Comments

Andrew Lunn Dec. 20, 2021, 6:06 p.m. UTC | #1
On Mon, Dec 20, 2021 at 04:39:43PM +0100, Arnd Bergmann wrote:
> On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
> >
> > These patches replace an open coded calculation to obtain the physical
> > address of a far symbol with a call to the new ldr_l etc macro, and they
> > belong to the kaslr patch set of arm32.
> >
> > Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
> >
> > Ard Biesheuvel (3):
> >   arm-soc: exynos: replace open coded VA->PA conversions
> >   arm-soc: mvebu: replace open coded VA->PA conversion
> >   arm-soc: various: replace open coded VA->PA calculation
> 
> Usually these patches should go through the respective platform
> maintainer trees,
> and from there into the soc tree, but time is a little short here.
> 
> I could apply them directly with the maintainer Acks

Sorry, but this is too low level for me to understand what is going
on, and so feel confident actually giving an ACK for the mvebu change.

Should the resulting assembly be exactly the same? Has the submitter
disassembled the object code and shown there is no actual difference
in the assembler output?

   Andrew
Gaosheng Cui Dec. 21, 2021, 1:41 a.m. UTC | #2
> 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.

Gaosheng.

在 2021/12/20 23:39, Arnd Bergmann 写道:
> On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1@huawei.com> wrote:
>> These patches replace an open coded calculation to obtain the physical
>> address of a far symbol with a call to the new ldr_l etc macro, and they
>> belong to the kaslr patch set of arm32.
>>
>> Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
>>
>> Ard Biesheuvel (3):
>>    arm-soc: exynos: replace open coded VA->PA conversions
>>    arm-soc: mvebu: replace open coded VA->PA conversion
>>    arm-soc: various: replace open coded VA->PA calculation
> Usually these patches should go through the respective platform
> maintainer trees,
> and from there into the soc tree, but time is a little short here.
>
> 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?
>
>         Arnd
> .
Arnd Bergmann Dec. 21, 2021, 9:15 a.m. UTC | #3
On Tue, Dec 21, 2021 at 2:41 AM cuigaosheng <cuigaosheng1@huawei.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
Linus Walleij Dec. 22, 2021, 2:31 a.m. UTC | #4
On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:

> 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

Yeah I'm still working on this series. The 4/4 split works pretty well,
but it breaks KASan and I was in the process of fixing that when I left
for parental leave.

The reason it breaks would be related to KASan not expecting
executable code in the vmalloc area, and since the shadowing
algorithm is a simple pointer offset, and since we go to lengths
to chisel shadow memory out of lowmem at a fixed offset from
TEXT_OFFSET, we have a problem.

The patch "KASAN horror" shows what I am trying to do to fix it,
it's "just" some hard work missing.

Yours,
Linus Walleij
Linus Walleij Dec. 24, 2021, 4:05 a.m. UTC | #5
On Wed, Dec 22, 2021 at 10:30 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Wed, 22 Dec 2021 at 03:31, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Dec 21, 2021 at 10:16 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > > 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
> >
> > Yeah I'm still working on this series. The 4/4 split works pretty well,

Actually it's just kernel-in-vmalloc, 4/4 comes after that.

> > but it breaks KASan and I was in the process of fixing that when I left
> > for parental leave.
> >
> > The reason it breaks would be related to KASan not expecting
> > executable code in the vmalloc area, and since the shadowing
> > algorithm is a simple pointer offset, and since we go to lengths
> > to chisel shadow memory out of lowmem at a fixed offset from
> > TEXT_OFFSET, we have a problem.
> >
>
> Vmap'ed stacks actually has a similar problem, which is why it is
> disabled when KAsan is enabled. But this can be fixed by enabling arch
> support for KASAN_VMALLOC, and I suspect it may address the vmap'ed
> kernel as well.

Yep after seeing the other convo on the topic I realized that this
is indeed the same as I'm seeing. I can't disable KASAN just
because the kernel is in VMALLOC though, so I suppose when
I finally get back to this I have to fix KASAN_VMALLOC too
if noone beats me to it.

(It'd be great if someone could beat me to it...)

Yours,
Linus Walleij