linux-kernel - Re: [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXGK8x4eBL55mLMWVQWpFZKa+FSCaQj9_gieWCQSgG=xAQ@mail.gmail.com>
Date:   Mon, 28 Sep 2020 12:14:27 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Zhen Lei <thunder.leizhen@...wei.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     Russell King <linux@...linux.org.uk>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Libin <huawei.libin@...wei.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>
Subject: Re: [PATCH 2/2] ARM: decompressor: relax the loading restriction of
 the decompressed kernel

On Mon, 28 Sep 2020 at 11:27, Zhen Lei <thunder.leizhen@...wei.com> wrote:
>
> mov     r4, pc
> and     r4, r4, #0xf8000000     //truncated to 128MiB boundary
> add     r4, r4, #TEXT_OFFSET    //PA(_start)
>
> Currently, the decompressed kernel must be placed at the position: 128MiB
> boundary + TEXT_OFFSET. This limitation is just because we masked PC with
> 0xf80000000. Actually, we can directly obtain PA(_start) by using formula
> : VA(_start) + (PHYS_OFFSET - PAGE_OFFSET).
>
> So the "PA(_start) - TEXT_OFFSET" can be 2MiB boundary, 1MiB boundary,
> and so on.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@...wei.com>

No, this won't work.

The whole reason for rounding to a multiple of 128 MB is that we
cannot infer the start of DRAM from the placement of the zImage (which
provides _start).

There are patches on the list by Geert [0] to obtain the start of DRAM
from the device tree directly, to work around this masking. And when
booting via EFI (which is supported by u-boot too these days), the
zImage could be anywhere in [32-bit addressable] memory, and the start
of DRAM is obtained from the EFI memory map.

Note to Geert: this is a followup to an effort by Zhen Lei and myself
[1] to lower the minimum alignment of PHYS_OFFSET from 16 MiB to 2
MiB, and this affects your patch as well.


[0] https://lore.kernel.org/linux-arm-kernel/20200902153606.13652-1-geert+renesas@glider.be/
[1] https://lore.kernel.org/linux-arm-kernel/20200921154117.757-1-ardb@kernel.org/


> ---
>  arch/arm/boot/compressed/head.S | 33 ++++++++++++++-------------------
>  1 file changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 434a16982e344fe..e5ba2ad2ea4700f 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -255,26 +255,16 @@ not_angel:
>
>  #ifdef CONFIG_AUTO_ZRELADDR
>                 /*
> -                * Find the start of physical memory.  As we are executing
> -                * without the MMU on, we are in the physical address space.
> -                * We just need to get rid of any offset by aligning the
> -                * address.
> -                *
> -                * This alignment is a balance between the requirements of
> -                * different platforms - we have chosen 128MB to allow
> -                * platforms which align the start of their physical memory
> -                * to 128MB to use this feature, while allowing the zImage
> -                * to be placed within the first 128MB of memory on other
> -                * platforms.  Increasing the alignment means we place
> -                * stricter alignment requirements on the start of physical
> -                * memory, but relaxing it means that we break people who
> -                * are already placing their zImage in (eg) the top 64MB
> -                * of this range.
> +                * Find ZRELADDR (Address where the decompressed kernel was
> +                * placed, usually == PHYS_OFFSET + TEXT_OFFSET). That's the
> +                * start physical address of the text section, PA(_start).
> +                * As we are executing without the MMU on, we are in the
> +                * physical address space.
>                  */
> -               mov     r4, pc
> -               and     r4, r4, #0xf8000000
> -               /* Determine final kernel image address. */
> -               add     r4, r4, #TEXT_OFFSET
> +               adr     r0, LC2
> +               ldmia   r0, {r3-r4}
> +               sub     r3, r0, r3              @ PHYS_OFFSET - PAGE_OFFSET
> +               add     r4, r4, r3              @ PA(_start)
>  #else
>                 ldr     r4, =zreladdr
>  #endif
> @@ -660,6 +650,11 @@ LC1:               .word   .L_user_stack_end - LC1 @ sp
>                 .word   _edata - LC1            @ r6
>                 .size   LC1, . - LC1
>
> +               .align  2
> +               .type   LC2, #object
> +LC2:           .word   LC2
> +               .word   _start                  @ start VA of text section
> +
>  .Lheadroom:
>                 .word   _end - restart + 16384 + 1024*1024
>
> --
> 1.8.3
>
>