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

Date:   Fri, 3 Sep 2021 18:20:23 +0200
From:   Felix Fietkau <nbd@....name>
To:     Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>
Cc:     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 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.

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.

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?

- Felix