netdev - Re: [PATCH v2 08/18] can: m_can: Write transmit header and data in one transaction

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:   Mon, 20 Feb 2023 06:31:00 +0100
From:   Markus Schneider-Pargmann <msp@...libre.com>
To:     Simon Horman <simon.horman@...igine.com>
Cc:     Marc Kleine-Budde <mkl@...gutronix.de>,
        Chandrasekar Ramakrishnan <rcsekar@...sung.com>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Vincent MAILHOL <mailhol.vincent@...adoo.fr>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 08/18] can: m_can: Write transmit header and data in
 one transaction

Hi Simon,

On Sat, Feb 04, 2023 at 02:05:57PM +0100, Simon Horman wrote:
> On Mon, Jan 30, 2023 at 09:04:19AM +0100, Markus Schneider-Pargmann wrote:
> > Hi Simon,
> > 
> > On Thu, Jan 26, 2023 at 09:04:56AM +0100, Simon Horman wrote:
> > > On Wed, Jan 25, 2023 at 08:50:49PM +0100, Markus Schneider-Pargmann wrote:
> > > > Combine header and data before writing to the transmit fifo to reduce
> > > > the overhead for peripheral chips.
> > > > 
> > > > Signed-off-by: Markus Schneider-Pargmann <msp@...libre.com>
> > > > ---
> > > >  drivers/net/can/m_can/m_can.c | 10 +++++-----
> > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> > > > index 78f6ed744c36..440bc0536951 100644
> > > > --- a/drivers/net/can/m_can/m_can.c
> > > > +++ b/drivers/net/can/m_can/m_can.c
> > > > @@ -1681,6 +1681,7 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev)
> > > >  		m_can_write(cdev, M_CAN_TXBAR, 0x1);
> > > >  		/* End of xmit function for version 3.0.x */
> > > >  	} else {
> > > > +		char buf[TXB_ELEMENT_SIZE];
> > > >  		/* Transmit routine for version >= v3.1.x */
> > > >  
> > > >  		txfqs = m_can_read(cdev, M_CAN_TXFQS);
> > > > @@ -1720,12 +1721,11 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev)
> > > >  		fifo_header.dlc = FIELD_PREP(TX_BUF_MM_MASK, putidx) |
> > > >  			FIELD_PREP(TX_BUF_DLC_MASK, can_fd_len2dlc(cf->len)) |
> > > >  			fdflags | TX_BUF_EFC;
> > > > -		err = m_can_fifo_write(cdev, putidx, M_CAN_FIFO_ID, &fifo_header, 2);
> > > > -		if (err)
> > > > -			goto out_fail;
> > > > +		memcpy(buf, &fifo_header, 8);
> > > > +		memcpy(&buf[8], &cf->data, cf->len);
> > > >  
> > > > -		err = m_can_fifo_write(cdev, putidx, M_CAN_FIFO_DATA,
> > > > -				       cf->data, DIV_ROUND_UP(cf->len, 4));
> > > > +		err = m_can_fifo_write(cdev, putidx, M_CAN_FIFO_ID,
> > > > +				       buf, 8 + DIV_ROUND_UP(cf->len, 4));
> > > 
> > > Perhaps I am missing something here, but my reading is that:
> > > 
> > > - 8 is a length in bytes
> > > - the 5th argument to m_can_fifo_write is the val_count parameter,
> > >   whose unit is 4-byte long values.
> > > 
> > >   By this logic, perhaps the correct value for this argument is:
> > > 
> > >   DIV_ROUND_UP(8 + cf->len, 4)
> > 
> > Thank you for spotting this. You are totally right, I will fix it for
> > the next version.
> 
> Thanks.
> 
> > > Also:
> > > 
> > > - If cf->len is not a multiple of 4, is there a possibility
> > >   that uninitialised trailing data in buf will be used
> > >   indirectly by m_can_fifo_write()?
> > 
> > Good point. I think this can only happen for 1, 2, 3, 5, 6, 7 bytes,
> > values above have to be multiple of 4 because of the CAN-FD
> > specification.
> > 
> > With 'buf' it should read garbage from the buffer which I think is not a
> > problem as the chip knows how much of the data to use. Also the tx
> > elemnt size is hardcoded to 64 byte in the driver, so we do not overwrite
> > the next element with that. The chip minimum size is 8 bytes for the
> > data field anyways. So I think this is fine.
> 
> I'm not the expert on the hw in question here, but intuitively
> I do feel that it may be unwise to send uninitialised data.
> While I'm happy to defer to you on this, I do wonder if it would be somehow
> better to use memcpy_and_pad() in place of memcpy().

Thank you, I think it is safe, but memcpy_and_pad seems like a good
solution here to make it even safer.

Best,
Markus