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:   Wed, 20 Dec 2017 13:48:56 +0100
From:   Linus Walleij <>
To:     Arnd Bergmann <>,
        Russell King <>,
        Jonas Jensen <>
Cc:     Lukasz Majewski <>,
        Alexander Sverdlin <>,
        Hartley Sweeten <>,
        Linux ARM <>,
        Linux Kernel Mailing List <>,
        Olof Johansson <>
Subject: Re: [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board

On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <> wrote:
> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <> wrote:
>>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <>
>>> wrote:
>>> >> >> We also need to think about upholding support in GCC for
>>> >> >> ARMv4(t) for the foreseeable future if there is a big web of
>>> >> >> random deeply embedded systems out there that will need
>>> >> >> updates.
>>> >> >
>>> >> > But we should definitely preserve at least what we have.
>>> >>
>>> >> Plain ARMv4 (and earlier) support in gcc is already marked
>>> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
>>> >> of last week). ARMv4T is going to be around for a while, and you
>>> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
>>> >> linking with 'ld --fix-v4bx'.
>>> >
>>> > I think that we shall start complaining on the gcc-devel mailing
>>> > list now.
>>> >
>>> > I would be hard to wake up in 2 years time and realise that we don't
>>> > have a modern compiler.
>>> It would also be helpful
>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>> working binaries for you, in that case you could report to the gcc
>>> developers that the removal of armv4 can continue but that
>>> the --fix-v4bx option in ld needs to stay around.
>> I may ask this issue on OE/Yocto mailing list as well....
> To clarify, the only  affected platforms are those based on either
> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
> FootBridge, RPC, SA1100, Moxart and Gemini.

It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/

Even is still up and kicking.

Some of it may be nostalgia and platform-hugging with regards to
SA110 and SA1100 systems, I am certainly aware of such tendencies
in myself. And I understand if GCC drops support for old systems
that only have a bunch of elderly gentlemen running it for the fun of it.

What really worries me is if there are widely deployed SA110,
SA1100, FA526 or similar embedded systems using plain ARMv4
and doing regular kernel builds and userspaces for them, in
items with 20+ years support cycles.

With reports in the media about things like nuclear powerplants running
unsupported versions of Windows NT or 95, I want to make sure
that we're not creating a similar situation somewhere for deeply
embedded Linux. Sadly these users mostly seem to come out
of the shadows after-the-fact.

My own experiments with an upgraded Gemini platform are mostly
related to the fact that home routers using this ARMv4 SoC are still
being sold and deployed, using a v2.6 kernel (contributing to the
world of botnets I suppose). The hardware-accelerated gigabit ethernet
on these routers for the home make them still fully usable despite the
ARMv4 core, but securitywise they are a nightmare.

Linus Walleij

Powered by blists - more mailing lists