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]

Message-ID: <CAMj1kXFK+HoouMMBbHxEgm-zQqKa6QMS6keeZmhpXTc4FCy8fQ@mail.gmail.com>
Date:   Sun, 1 Aug 2021 18:44:08 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     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>,
        Felix Fietkau <nbd@....name>
Subject: Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@...db.de> wrote:
>
> On Fri, Jul 30, 2021 at 3:45 PM Bert Vermeulen <bert@...t.com> wrote:
> >
> > From: John Crispin <john@...ozen.org>
> >
> > EN7523 is an armv7 based silicon used inside broadband access type devices
> > such as xPON and xDSL. It shares various silicon blocks with MediaTek
> > silicon such as the MT7622.
> >
> > Signed-off-by: John Crispin <john@...ozen.org>
> > Signed-off-by: Bert Vermeulen <bert@...t.com>
>
> It's always nice to see a new SoC family.
>
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -580,6 +580,20 @@ config ARCH_VIRT
> >         select HAVE_ARM_ARCH_TIMER
> >         select ARCH_SUPPORTS_BIG_ENDIAN
> >
> > +config ARCH_ECONET
> > +       bool "Econet SoC Support"
> > +       depends on ARCH_MULTI_V7
> > +       select ARM_AMBA
> > +       select ARM_GIC
> > +       select ARM_GIC_V3
> > +       select ARM_DMA_USE_IOMMU
> > +       select ARM_PSCI
> > +       select HAVE_ARM_ARCH_TIMER
> > +       select IOMMU_DMA
> > +       select COMMON_CLK
> > +       help
> > +         Support for Econet EN7523 SoCs
>
> Given how closely related this probably is to MT7623/MT7622, should this
> perhaps just be part of arch/arm/mach-mediatek? According to
> https://wikidevi.wi-cat.ru/MediaTek#xPON, the older (mips based) MT752x
> chips are apparently just rebranded to EN752x after the business unit
> was spun off, but I guess they are still in the same family.
>
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 173da685a52e..1bff0aa29c07 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -152,6 +152,7 @@ textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> >  textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >  textofs-$(CONFIG_ARCH_MESON) := 0x00208000
> >  textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
> > +textofs-$(CONFIG_ARCH_ECONET) := 0x00088000
>
> 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.

--
Ard.