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-next>] [day] [month] [year] [list]
Message-ID: <CACQ1gAhNFTdG_2OCTnsOCaBozHnGb9EwAGHT5+f=cARRpC_WBg@mail.gmail.com>
Date:	Tue, 8 Oct 2013 12:44:16 +0200
From:	Richard Genoud <richard.genoud@...il.com>
To:	Nicolas Ferre <nicolas.ferre@...el.com>,
	Mark Brown <broonie@...nel.org>,
	Wenyou Yang <wenyou.yang@...el.com>
Cc:	linux-spi@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [BUG] spi/spi-atmel: DMA rx buffer corruption with SPI_IOC_MESSAGE

Hi all,

I finally found the bug I saw months ago, before "[PATCH v8 3/8]
spi/spi-atmel: add dmaengine support" was merged.

Here it is:

When the ioctl SPI_IOC_MESSAGE is used with small and big buffers,
the big RX buffer is corrupted with bytes from the big TX buffer.
(Small means size < DMA_MIN_BYTES, Big means size > DMA_MIN_BYTES)

I'm attaching the test software that I used ( ./spi_test /dev/spidevx.x )

It fills 3 TX buffers with 0xAA pattern: a small, a big and a small again.
It reads in return 3 RX buffers.
The MISO pin has to be on 3.3v.

It checks if the received buffers are filled with 0xFF (they should
be, as MISO is high).
And I've got a lot of buffers filled partially with 0xAA bytes.

BUT, if you apply this patch:
---8<----
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 83cf609..cde42a4 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -187,7 +187,7 @@
 /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
  * cache operations; better heuristics consider wordsize and bitrate.
  */
-#define DMA_MIN_BYTES  16
+#define DMA_MIN_BYTES  0

 struct atmel_spi_dma {
        struct dma_chan                 *chan_rx;
---8<----
There's no error any more.
So there's something wrong happening when switching from/to pio
transfer to/from DMA.

We didn't saw that at the time of the merge because we did the test
with a loop on MISO/MOSI,
so the RX buffer was corrupted with identical bytes.

Best regards,
Richard.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ