linux-kernel - Re: [PATCH v2 00/16] DocG3 fixes and write support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EBED0B8.1030307@newsguy.com>
Date:	Sat, 12 Nov 2011 12:02:00 -0800
From:	Mike Dunn <mikedunn@...sguy.com>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
CC:	dwmw2@...radead.org, dedekind1@...il.com,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/16] DocG3 fixes and write support

On 11/10/2011 12:05 AM, Robert Jarzmik wrote:
> nandtest/nanddump/nandwrite testing has been
> done, with and without bitflipped data.

Yay!

> Moreover, 3 new patches have been added:
>  - fix reading oob+data without correction
>    This was triggered by the bitflipped pages tests, and
>    fixes cases where we want to read corrupted data.
>  - add docg3 modes support
>    This actually fixes the read part, as we now read in
>    "normal" mode by default rather than in "reliable"
>    mode. This is mandatory for nandtest to work, because of
>    the "even/odd pages logical AND".
>  - add protection support
>    This is an evolution to be able to access the whole chip
>    in protected chips, as they are in smartphones.

How did you figure out these operating modes and the protected part stuff?  From
reverse-engineering a disassembled binary?  I'm impressed.  You don't get that
level of detail from just monitoring cpu accesses to the device during normal
operation.

BTW, I'm coming around to your thinking that the nand interface is not
appropriate for these chips.  Even though they are nand, the lack of any
standard nand interface means the nand base does not do much for you except
obfuscate.  Memory based bbt maintenance is handled in nand base, maybe a couple
other minor things.  I hope I change my mind; otherwise I'll have to rework the
G4 driver :-(

This would also eliminate my main argument for combining G3/G4 drivers: to keep
the nand interface code consistent.  That and more device differences seen in
your latest patches argue against combining.  I still strongly suspect that the
G3 is very similiar to the P3 in my Treo 650.  At some point down the road I'll
test it out on the P3.  Device capacity might be the only difference between the
two devices.  If so, the G3 driver might even work on the P3 right out of the box.

Thanks,
Mike

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