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]
Date:	Thu, 14 Oct 2010 02:39:59 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alex Dubov <oakad@...oo.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Results of my work on memorystick subsystem

Hi,

Here is a result of lot of work I did improving the memorystick
subsystem and its drivers.

patch #1 add common code to memorystick core that makes card drivers easier
to understand

patch #2 just add a driver for my card reader

patch #3 reworks the Jmicron driver.
I can write a novel about the problems I had to go through with this device
(mostly hardware bugs I belive).
So I refactored the driver (pretty much rewritten large chunks of it)
Added a lot of debug output too to help future users.
Currently both MS and MSPro work fine.

patch #4 adds support for lagacy memorysticks.
Everything just works, not a single corruption this far.

patch #5, is what I did recently.
I rewrote large chunks on mspro_blk.c to make it much cleaner
and use the common code I added in patch #1.
I also added lot of debug code, comments.

and patch #6 contines adds even more cleanups, and makes whole
memctick subsystem look nice and clean.
Many non obivous functions were removen.
Now register window changes are completely hidden and automatic.
Functions that state machines call are explictly marked as so,
and that assumption is tested.

Code is tested with 2 mspro cards and one MS card.

Thanks again to Alex for his work.

***Appendix***

Jmicron hardware bugs (the novel):

#1: FIFO write ready bit in INT status register is stuck to 1.
   It is stuck forever as soon as fifo
   is used for writing even once.
   Therefore if interrupt is shared (and here it is), its easy
   to 'service' the device while it doesn't need any service


#2: Its not possible to stuff the FIFO before TPC transfer.
   One really have to wait for write ready interrupt, even though the write ready status is stuck.


#3: TPCs with non 4 aligned length woes:
   Facts:

   * non 4 aligned DMA write hangs the system hard, maybe on bus level.

   * PIO read succedes but controller truncates the data stored in the FIFO to closest 4 byte boundary.
   That is if you read 26 bytes, it will save 24 bytes in the FIFO

   * TPC_P0, TPC_P1 not aligned transfters work just fine despite a statement in the datasheet
   (only mention of this problem)


#4: As soon as write PIO is used, then later write DMA fails.
   Facts:

   * This is triggered only by PIO write of registers
   (only happens in ms_block.c when it writes param + oob. Thats why mspro_blk isn't affected)
   Doing short DMA writes is a nice workaround.

   * Doing PIO writes in h_msb_read_page don't cause the problem.
     Therefore the bug causing sequence should be similiar to h_msb_write_block:

       1. PIO write of param + extra (10 bytes) or even padded to 12 or 16 bytes
       2. inline write (TPC_P0) of MS_CMD_BLOCK_WRITE + wait for int
       3. read of INT register via STATUS
       3. DMA write of MS_TPC_WRITE_LONG_DATA
       4. DMA write of MS_TPC_WRITE_LONG_DATA
           ---------timeout-----------
 
   * In fact first DMA write succedes, but next one fails, and so do all following writes

   * The problem persits till reboot, and shows up even if PIO isn't used again.
   Other way to "fix" it, is to put device in D3 and back to D0

   * Serial/parallel mode don't affect anything.

   After bug reproduction:

    * DMA writes stop working completely, therefore mspro_blk looses writes as well

    * PIO still works just fine. Its possible just to load the driver without dma support, and it works correctly.

    * DMA reads work just fine.

#5: Auto_Get_INT feature just doesn't work.
   Datasheet says that intreg is placed to TPC_P0, but that doesn't happen....


Best regards,
	Maxim Levitsky

--
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