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] [day] [month] [year] [list]
Date:   Wed, 7 Jun 2017 17:17:29 +0900
From:   KOBAYASHI Yoshitake <yoshitake.kobayashi@...hiba.co.jp>
To:     Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:     richard@....at, dwmw2@...radead.org, computersforpeace@...il.com,
        marek.vasut@...il.com, cyrille.pitchen@...ev4u.fr,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next] mtd: nand: Add support for Toshiba BENAND (Built-in
 ECC NAND)

On 2017/06/07 6:11, Boris Brezillon wrote:
> On Mon, 5 Jun 2017 14:36:23 +0900
> KOBAYASHI Yoshitake <yoshitake.kobayashi@...hiba.co.jp> wrote:
> 
>> Hi Boris,
>>
>> Thank you very much for your detailed review.
>> I just comming back from busy week for conference and started to look it.
>>
>> I have a question regarding to the following comment.
>>
>>>>  static int toshiba_nand_init(struct nand_chip *chip)
>>>>  {
>>>> +	struct mtd_info *mtd = nand_to_mtd(chip);
>>>> +
>>>>  	if (nand_is_slc(chip))
>>>>  		chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
>>>>  
>>>> +	if (chip->ecc.mode == NAND_ECC_BENAND) {
>>>> +		chip->ecc.options = NAND_ECC_CUSTOM_PAGE_ACCESS;
>>>> +		chip->ecc.bytes = 0;  
>>>
>>> It should be set to 16 according to the datasheet. But I guess this is
>>> not exactly true. I'm pretty sure we can use some of these bytes to
>>> store real data. Assuming you're using BCH, only 13bytes are needed for
>>> 8bits/512bytes strength, and I guess the BBM region is also left
>>> untouched (first 2 bytes of the OOB region).  
>>
>> On BENAND, all OOB reginon can be used by user (driver). The calculated
>> ECC data stored into other isolated area which is ubable to access from user.
>> This is why chip->ecc.bytes = 0.
> 
> Oh, nice!
> 
>> To make sure this specification, I also checked the BENAND datasheet
>> but unfortunatelly it was undocumented. Sorry for this confusion.
> 
> No problem. Do you think you can update the datasheet (or ask someone
> who can) to clarify this aspect? As you said, it's really not clear
> that these ECC bytes are actually stored in a dedicated region that is
> invisible to users.

Thank you for your comment. I asked to the product department about this.
They say they are confirming whether they can update our product datasheet or not.

-- Yoshi


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ