netdev - Re: [net-next 6/6] can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register

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: <20220622081939.b4ev2k4b3i3fo6an@pengutronix.de>
Date:   Wed, 22 Jun 2022 10:19:39 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Thomas.Kopp@...rochip.com
Cc:     pavel.modilaynen@...vocars.com, drew@...gleboard.org,
        linux-can@...r.kernel.org, menschel.p@...teo.de,
        netdev@...r.kernel.org, will@...china.cc
Subject: Re: [net-next 6/6] can: mcp251xfd: mcp251xfd_regmap_crc_read(): work
 around broken CRC on TBC register

On 21.06.2022 16:25:15, Marc Kleine-Budde wrote:
> > Thanks for the data. I've looked into this and it seems that the
> > second bit being set in your case does not depend on the SPI-Rate (or
> > the quirks for that matter) but it seems to be hardware setup related.
> > 
> > I'm fine with changing the driver so that it ignores set LSBs but
> > would limit it to 2 or 3 bits:
> > 
> > (buf_rx->data[0] == 0x0 || buf_rx->data[0] == 0x80))
> > becomes
> > ((buf_rx->data[0] & 0xf8) == 0x0 || (buf_rx->data[0] & 0xf8) == 0x80)) {
> > 
> > The action also needs to be changed and the flip back of the bit
> > needs to be removed. In this case the flipped databit that produces
> > a matching CRC is actually correct (i.e. consistent with the 7 LSBs
> > in that byte.)

The mcp2517fd errata says the transmitted data is okay, but the CRC is
calculated on wrong data:

| It is possible that there is a mismatch between the transmitted CRC
| and the actual CRC for the transmitted data when data are updated at a
| specific time during the SPI READ_CRC command. In these cases, the
| transmitted CRC is wrong. The data transmitted are correct.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)