linux-kernel - Re: [PATCH v3 1/2] spi: add support for DLN-2 USB-SPI adapter

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]

Date:	Wed, 19 Nov 2014 11:09:32 +0100
From:	Johan Hovold <johan@...nel.org>
To:	Laurentiu Palcu <laurentiu.palcu@...el.com>
Cc:	Johan Hovold <johan@...nel.org>, Mark Brown <broonie@...nel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Octavian Purdila <octavian.purdila@...el.com>,
	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] spi: add support for DLN-2 USB-SPI adapter

On Wed, Nov 19, 2014 at 11:53:44AM +0200, Laurentiu Palcu wrote:
> On Tue, Nov 18, 2014 at 06:06:27PM +0100, Johan Hovold wrote:
> > On Tue, Nov 18, 2014 at 02:09:58PM +0200, Laurentiu Palcu wrote:
> > 
> > > +/*
> > > + * Copy the data to DLN2 buffer and change the byte order to LE, requested by
> > > + * DLN2 module. SPI core makes sure that the data length is a multiple of word
> > > + * size.
> > > + */
> > > +static int dln2_spi_copy_to_buf(u8 *dln2_buf, const u8 *src, u16 len, u8 bpw)
> > > +{
> > > +#ifdef __LITTLE_ENDIAN
> > > +	memcpy(dln2_buf, src, len);
> > > +#else
> > > +	if (bpw <= 8) {
> > > +		memcpy(dln2_buf, src, len);
> > > +	} else if (bpw <= 16) {
> > > +		__le16 *d = (__le16 *)dln2_buf;
> > > +		u16 *s = (u16 *)src;
> > > +
> > > +		len = len / 2;
> > > +		while (len--)
> > > +			put_unaligned_le16(get_unaligned(s++), d++);
> > 
> > You said the dln2 buffer was properly aligned, right? Then you don't
> > need to use put_unaligned_lexx here...
>
> I know, and I was very close not to use it, but, as you said, others
> might not be as careful

That was in a different context. :)

> and if Diolan FW changes anything in the
> header's structure in the future, the alignment will be off. This is
> just a precaution. I know it's a little bit costly but this will affect
> only BE machines and only if bits-per-word is bigger than 8.

I don't think you should worry about hypothetical changes to the
protocol.

You verified the that headers are a multiple of four, so no need for the
unaligned macros.

> > > +	} else {
> > > +		__le32 *d = (__le32 *)dln2_buf;
> > > +		u32 *s = (u32 *)src;
> > > +
> > > +		len = len / 4;
> > > +		while (len--)
> > > +			put_unaligned_le32(get_unaligned(s++), d++);
> > > +	}
> > > +#endif
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +/*
> > > + * Copy the data from DLN2 buffer and convert to CPU byte order since the DLN2
> > > + * buffer is LE ordered. SPI core makes sure that the data length is a multiple
> > > + * of word size.
> > > + */
> > > +static int dln2_spi_copy_from_buf(u8 *dest, const u8 *dln2_buf, u16 len, u8 bpw)
> > > +{
> > > +#ifdef __LITTLE_ENDIAN
> > > +	memcpy(dest, dln2_buf, len);
> > > +#else
> > > +	if (bpw <= 8) {
> > > +		memcpy(dest, dln2_buf, len);
> > > +	} else if (bpw <= 16) {
> > > +		u16 *d = (u16 *)dest;
> > > +		__le16 *s = (__le16 *)dln2_buf;
> > > +
> > > +		len = len / 2;
> > > +		while (len--)
> > > +			put_unaligned(get_unaligned_le16(s++), d++)
> > 
> > ...or get_unaligned_lexx here.
> > 
> > > +	} else {
> > > +		u32 *d = (u32 *)dest;
> > > +		__le32 *s = (__le32 *)dln2_buf;
> > > +
> > > +		len = len / 4;
> > > +		while (len--)
> > > +			put_unaligned(get_unaligned_le32(s++), d++)
> > > +	}
> > > +#endif
> > > +
> > > +	return 0;
> > > +}
> > 
> > Did you check the alignment of the SPI buffers as well? I'd assume they
> > were DMA-able and thus properly aligned, and then you do not need to use
> > any unaligned helpers above at all.
>
> I did... The spi_transfer struct documentation says that those tx_buf
> and rx_buf buffers are dma-safe but, apparently, I found drivers that do
> not really use alligned buffers for transfers. Look, for example, at
> max1111.c. Those buffers don't look aligned to me...

That looks like a bug to me. DMA-buffers should never be allocated as
part of a larger structure.

> Well, this driver
> is probably not the best example since BPW is 8, but you got my point.
> Other drivers, indeed, use the ____cacheline_aligned attribute and
> should be dma-safe.

I think you can remove the unaligned macros altogether.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/