linux-kernel - Re: ARM: static kernel in vmalloc space

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]

Date:   Thu, 30 Jul 2020 12:17:52 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        afzal mohammed <afzal.mohd.ma@...il.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: ARM: static kernel in vmalloc space

On Thu, Jul 30, 2020 at 11:33 AM Linus Walleij <linus.walleij@...aro.org> wrote:
> On Fri, May 15, 2020 at 5:41 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> [Russell]
> > > There are some aliasing VIPT implementations on ARMv6, but I don't
> > > remember how common.
> >
> > I thought it was only realview-pb and omap2, but it seems there
> > are more, at least ast2500 is an important example.
> >
> > I could not find information about integrator-cp and picoxcell.
> (...)
> >   integrator CM1136JF-S core module: arm1136r?, 16kb non-aliasing VIPT
> > ? integrator CTB36 core tile: arm1136r?, ???
>
> These do exist, the Integrators have pluggable CPU core modules.
> What you do is populate the core module slot on the Integrator CP
> with a CM1136.

Here the question is really what the cache size would be. 16kb
caches are non-aliasing, while 32kb caches would be aliasing.
The particular core revision would tell you whether this is an ARMv6
(1136r0) or ARMv6k (1136r1) implementation.

> That said, I think I am the only user of the Integrator/CP actual
> hardware. And I don't have this core module. So I think it will be
> safe to drop support for that specific VIPT implementation by the
> token that if a tree falls in the forest and noone
> is there to hear it, it does not make a sound.
>
> As for physically existing VIPT 1136/1176 systems the Ambarella
> legacy SoCs that are not upstream is the big consumer of these.
>
> Ambarella's main customer is GoPro cameras and similar
> products. I have no idea if they ever upgrade kernels on these
> things though, I think not, but it would be great if someone knows
> them and can ask whether this is a concern for them. (They
> should be working with the community IMO, but is one of those
> companies that for some reason do not.)

It seems unlikely that there is still enough interest in the old
GoPro chips.

Apparently GoPro Hero3+ from 2013 already used a Cortex-A9
based Ambarella chip, and according to Wikipedia in 2017 they
started making their own SoCs rather using Ambarella's.

I found some source code for both the arm11 version [1] and
the Cortex-A9 based chips, the last update on either of those
that was in 2016. The boot log in [2] shows this is a nonaliasing
cache btw.

Anyway, as I said earlier, as long as AST2500 (or OMAP2) is used,
aliasing dcaches remain a concern for ARMv6-enabled kernels.

     Arnd

[1] https://github.com/evilwombat/gopro-linux/tree/master/arch/arm/mach-ambarella
[2] https://www.tapatalk.com/groups/goprouser/hero3-black-firmware-studies-physical-teardown-pho-t10016-s10.html#p58148