linux-kernel - Re: [PATCH v5 1/3] can: length: fix bitstuffing count

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: <ZIrC6DpjjtmpIsI9@corigine.com>
Date:   Thu, 15 Jun 2023 09:51:04 +0200
From:   Simon Horman <simon.horman@...igine.com>
To:     HMS Incident Management <Incidentmanagement@....se>
Cc:     "mkl@...gutronix.de" <mkl@...gutronix.de>,
        "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        "Thomas.Kopp@...rochip.com" <Thomas.Kopp@...rochip.com>,
        "socketcan@...tkopp.net" <socketcan@...tkopp.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "marex@...x.de" <marex@...x.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mailhol.vincent@...adoo.fr" <mailhol.vincent@...adoo.fr>
Subject: Re: [PATCH v5 1/3] can: length: fix bitstuffing count

On Wed, Jun 14, 2023 at 08:40:42PM +0000, HMS Incident Management wrote:
> [You don't often get email from incidentmanagement@....se. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> **We apologize for the delay in delivering this email, which was caused by a mail incident that occurred over the weekend on June 10th. This email was originally sent from vincent.mailhol@...il.com on 06/11/2023 02:58:08
> 
> The Stuff Bit Count is always coded on 4 bits [1]. Update the Stuff
> Bit Count size accordingly.
> 
> In addition, the CRC fields of CAN FD Frames contain stuff bits at
> fixed positions called fixed stuff bits [2]. The CRC field starts with
> a fixed stuff bit and then has another fixed stuff bit after each
> fourth bit [2], which allows us to derive this formula:
> 
>   FSB count = 1 + round_down(len(CRC field)/4)
> 
> The length of the CRC field is [1]:
> 
>   len(CRC field) = len(Stuff Bit Count) + len(CRC)
>                  = 4 + len(CRC)
> 
> with len(CRC) either 17 or 21 bits depending of the payload length.
> 
> In conclusion, for CRC17:
> 
>   FSB count = 1 + round_down((4 + 17)/4)
>             = 6
> 
> and for CRC 21:
> 
>   FSB count = 1 + round_down((4 + 21)/4)
>             = 7
> 
> Add a Fixed Stuff bits (FSB) field with above values and update
> CANFD_FRAME_OVERHEAD_SFF and CANFD_FRAME_OVERHEAD_EFF accordingly.
> 
> [1] ISO 11898-1:2015 section 10.4.2.6 "CRC field":
> 
>   The CRC field shall contain the CRC sequence followed by a recessive
>   CRC delimiter. For FD Frames, the CRC field shall also contain the
>   stuff count.
> 
>   Stuff count
> 
>   If FD Frames, the stuff count shall be at the beginning of the CRC
>   field. It shall consist of the stuff bit count modulo 8 in a 3-bit
>   gray code followed by a parity bit [...]
> 
> [2] ISO 11898-1:2015 paragraph 10.5 "Frame coding":
> 
>   In the CRC field of FD Frames, the stuff bits shall be inserted at
>   fixed positions; they are called fixed stuff bits. There shall be a
>   fixed stuff bit before the first bit of the stuff count, even if the
>   last bits of the preceding field are a sequence of five consecutive
>   bits of identical value, there shall be only the fixed stuff bit,
>   there shall not be two consecutive stuff bits. A further fixed stuff
>   bit shall be inserted after each fourth bit of the CRC field [...]
> 
> Fixes: 85d99c3e2a13 ("can: length: can_skb_get_frame_len(): introduce function to get data length of frame in data link layer")
> Suggested-by: Thomas Kopp
> Signed-off-by: Vincent Mailhol
> Reviewed-by: Thomas Kopp

Hi,

Some feedback from my side, in the hope that it is useful.

I guess this patch-set has had a bit of a journey, email-wise.
Unfortunately on it's trip the email addresses for the tags above got lost,
which by itself leads me to think it should be resent.

Also, I think it would be best if the From address of the email
was from a human, who features in the Signed-off-by tags of the patches.
But perhaps this is also an artifact of the journey.

It is also unclear to me where this applies - f.e. it doesn't
apply to the main branch of linux-can-next.

Lastly, I'm not a CAN maintainer. But I think it's usual to separate
fixes and enhancements into different series, likely the former
targeting the can tree while the latter targets the can-next tree
(I could be way off here).

If on the other hand, the patches in this series are not bug fixes,
then it is probably best to drop the 'fixes' language.