linux-kernel - Re: [PATCH] ARM: mach-qcom: fix support for ipq806x

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]

Date:   Sat, 22 Oct 2022 16:21:28 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Russell King <linux@...linux.org.uk>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Arnd Bergmann <arnd@...db.de>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Nick Hawkins <nick.hawkins@....com>,
        John Crispin <john@...ozen.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH] ARM: mach-qcom: fix support for ipq806x

On Fri, Oct 21, 2022 at 11:55 PM Christian Marangi <ansuelsmth@...il.com> wrote:
> On Fri, Oct 21, 2022 at 11:44:56PM +0200, Linus Walleij wrote:

> > Is it not possible to use Geert's linux,usable-memory-range in
> > the chosen node to make the kernel stay off the memory?
> > (See examples by grep usable-memory in the kernel.)
> >
>
> Hi,
> just to confirm this is one of the example you are suggesting?
>
> chosen {
>                 bootargs = "console=ttyS0,115200 earlycon";
>                 stdout-path = "serial0:115200n8";
>                 linux,usable-memory-range = <0x80200000 0x1fe00000>;
>         };

Yep that thing!

> Main problem here is that uboot in some case doesn't support dt and pass
> wrong ATAGS (with the memory not reserved) and AUTO_ZRELADDR calculate
> the wrong addr I assume?

You do have a DTB right, just that it is attached, and then the kernel
uses the ATAGs to augment the memory?

In that case what about disabling ARM_ATAG_DTB_COMPAT
and adding the actual valid memory to the top-level DTS
file? Just like that:

      memory {
                device_type = "memory";
                reg = <0x42000000 0xnnnnnnnn>;
        };


> I will test the usable-memory-range but isn't the same of declaring
> reserved space in the dts? Or the zimage decompressor checks
> linux,usable-memory-range bypassing atags?

As long as it just pass "too much" memory it should do the job,
I *think*.

Since I wrote this article:
https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses
Geert introduced some very elaborate low-level OF code and I
do think it kicks in and makes sure to reserve this memory even
before the decompressor goes to work (in difference from e.g.
"reserved memory nodes" that are not inspected until later).

See:
commit 48342ae751c797ac73ac9c894b3f312df18ffd21
"ARM: 9124/1: uncompress: Parse "linux,usable-memory-range" DT property"

Then if the memory node is in the DTB originally or patched in
by U-Boot shouldn't really matter, usable-memory-range should
kick in in either case.

It is described as used for kexec (which I never use) but I think it can
solve your problem too.

The DT property is (by agreement) an undocumented Linux extension,
so Geert knows the intended usecases better :)

Yours,
Linus Walleij