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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220726141458.GY25951@gate.crashing.org>
Date:   Tue, 26 Jul 2022 09:14:58 -0500
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Regression: Linux v5.15+ does not boot on Freescale P2020

On Tue, Jul 26, 2022 at 04:01:00PM +0200, Pali Rohár wrote:
> On Tuesday 26 July 2022 08:44:05 Segher Boessenkool wrote:
> > And the architecture says
> >   Programming Note
> >   Warning: On some processors that comply with versions of the
> >   architecture that precede Version 2.00
> 
> But e500v2 is 2.03 and not older than 2.00...

Yes.  And it does not implement reserved fields in instructions (*any*
reserved fields in instructions, apparently!) correctly at all.

> >   e500v1/v2 based chips will treat any reserved field being set in an
> >   opcode as illegal.
> > 
> > while the architecture says
> > 
> >   Reserved fields in instructions are ignored by the processor.
> > 
> > Whoops :-)  We need fixes for processor implementation bugs all the
> > time of course, but this is a massive *design* bug.
> 
> I looked also in e500v2 and P2020 errata documents there is nothing
> mentioned about eh flag. But it looks like a bug.

The bug is if it does this for any reserved field (and it apparently
does it for all even).

> > Also people using an SMP kernel on older cores should see the problem,
> > no?
> 
> Probably yes.
> 
> But most people on these machines are using stable LTS kernels and do
> not upgrade too often.

Yeah.

> So you need to wait longer time to see people starting reporting such
> bugs. Need to wait at least when v4.14 and v4.19 LTS versions stops
> receiving updates. v4.19 is used in Debian 10 (oldstable) and v5.4 is
> used by current OpenWRT. Both distributions are still supported, so
> users have not migrated to new v5.15 problematic kernel yet.

That's not a reasonable timeline for kernel development of course.

We see the same thing with the compiler...  Although GCC has a much
slower release cadence (one new major version every year), it often
takes two or three or more years before we get bug reports that
something was broken.  If stuff isn't tested, we cannot really support
it at all.


Segher

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ