linux-kernel - Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

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] [day] [month] [year] [list]

Message-ID: <CAMj1kXHGfTSv+95NJF1BPS76M6-6FF9GQk24L2LLG9Epx4FpfA@mail.gmail.com>
Date:   Fri, 3 Sep 2021 19:47:12 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Felix Fietkau <nbd@....name>
Cc:     Arnd Bergmann <arnd@...db.de>, Bert Vermeulen <bert@...t.com>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Russell King <linux@...linux.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        John Crispin <john@...ozen.org>,
        YiFei Zhu <yifeifz2@...inois.edu>,
        Mike Rapoport <rppt@...nel.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

On Fri, 3 Sept 2021 at 18:20, Felix Fietkau <nbd@....name> wrote:
>
>
> On 2021-08-01 18:44, Ard Biesheuvel wrote:
> > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@...db.de> wrote:
> >>
> >> Why is this needed?
> >>
> >> Note also the comment directly above it exlaining
> >> # Text offset. This list is sorted numerically by address in order to
> >> # provide a means to avoid/resolve conflicts in multi-arch kernels.
> >>
> >
> > Yes, please drop this - it is a horrible hack and it's already quite
> > disappointing that we are stuck with it for the foreseeable future.
> >
> > So I assume the purpose of this is to protect the first 128k of DRAM
> > to be protected from being overwritten by the decompressor?
> >
> > It would be best to move this reserved region elsewhere, but I can
> > understand that this is no longer an option. So the alternatives are
> > - omit this window from the /memory node, and rely on Geert's recent
> > decompressor changes which make it discover the usable memory from the
> > DT, or
> > - better would be to use a /memreserve/ here (which you may already
> > have?), and teach the newly added decompressor code to take those into
> > account when choosing the target window for decompressing the kernel.
> I looked into this issue myself and found that this approach has a
> significant drawback: 2 MiB of RAM is permanently wasted for something
> that only needs to be preserved during boot time.
>

How so? If that memory region carries your PSCI implementation, it
should be preserved permanently. So at least the 512k are permanently
reserved.

> If the first 256 or 512 KiB of RAM are reserved in the decompressor, it
> means that the first 2 MiB need to be reserved, because that's the
> granularity for the kernel page mapping when the MMU is turned on.
>

Indeed.

> If we reserve it, we also need to need to take it out of the physical
> RAM address range, so there's no way to reclaim it later.
>
> On the other hand, with the simple textofs solution, I believe it gets
> freed in a late initcall, making it usable.
>
> So what's the right approach to deal with this?
>

The right solution here is to fix your firmware/bootloader so that the
PSCI reserved region is moved to the top of memory. Adding more
TEXT_OFFSET hacks is really not the right approach here.