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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 13 Nov 2011 11:41:49 +0100
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Mike Dunn <mikedunn@...sguy.com>
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

Mike Dunn <mikedunn@...sguy.com> writes:

> 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.
Retro-engineering and the nandwrite tests.
You see nandtest did not work. I could see why, and made some additionnal
tests. The result was that writting to page 0 and page 1 gave back the AND of
these both pages.

And from there, I checked what was the difference between DOCG3 IPL and SPL, and
landed on the "mode" register.

> 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 :-(
I don't know for G4, but I'm more convinced for G3 as well, as NAND interface
provides some state machine in the chip (where the last seek occured, ...).

> 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.
And if not right out of the box, I'll bet on :
 - adding a DOC_CHIPID_P3 ...
 - and if the chip is bigger, amend doc_setup_addr_sector(0 and
 doc_setup_writeaddr_sector() to input another byte of address (ie. add a line
 with doc_flash_address(docg3, (sector >> 24) & 0xff).

Cheers.

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