linux-kernel - Re: 回信: Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already found flash

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: <dcd4e64f-348c-fadd-1044-61c7b6fa93c8@microchip.com>
Date:   Wed, 23 Jun 2021 08:33:15 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <jaimeliao@...c.com.tw>, <michael@...le.cc>
CC:     <bbrezillon@...nel.org>, <esben@...nix.com>,
        <frieder.schrempf@...tron.de>, <linux@...musvillemoes.dk>,
        <linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
        <masonccyang@...c.com.tw>, <p.yadav@...com>, <ycllin@...c.com.tw>,
        <zhengxunli@...c.com.tw>
Subject: Re: 回信: Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already found flash_info

On 6/23/21 10:17 AM, jaimeliao@...c.com.tw wrote:
> You don't often get email from jaimeliao@...c.com.tw. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> Hi Michael and Rasmus
> 
> 
>>
>> Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already
>> found flash_info
>>
>> [+ some people from MXIC as they are ones who posted to the ML
>> lately. Feel free to forward this mail to the corresponding people.]
>>
>> Am 2021-06-21 17:23, schrieb Rasmus Villemoes:
>>> Macronix engineers, in their infinite wisdom, have a habit of reusing
>>> JEDEC ids for different chips. There's already one
>>> workaround (MX25L25635F v MX25L25635E), but the same problem exists
>>> for MX25L3205D v MX25L3233F, the latter of which is not currently
>>> supported by linux.
>>>
>>> AFAICT, that case cannot really be handled with any of the ->fixup
>>> machinery: The correct entry for the MX25L3233F would read
>>>
>>>         { "mx25l3233f",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K |
>>> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ ) },
>>>
>>> while the existing one is
>>>
>>>    { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>>>
>>> So in spi_nor_init_params(), we won't even try reading the sfdp
>>> info (i.e. call spi_nor_sfdp_init_params), and hence
>>> spi_nor_post_sfdp_fixups() has no way of distinguishing the
>>> chips.
>>>
>>> Replacing the existing entry with the mx25l3233f one to coerce the
>>> core into issuing the SPINOR_OP_RDSFDP is also not really an option,
>>> because the data sheet for the mx25l3205d explicitly says not to issue
>>> any commands not listed ("It is not recommended to adopt any other
>>> code not in the command definition table, which will potentially enter
>>> the hidden mode.", whatever that means).
>>
>> Maybe we should ask Macronix if it is safe to send the RDSFDP command.
>> Can anyone from MXIC comment this?
> 
> For this part, we have validate RDSFDP command on some different chips which
> are not support SFDP mode. The conclusion is that Flash didn't reply anything.
> But we still not suggest to using commands which are not supported on the Flash.
> 
>> This is also interesting because we are discussing reading the SFDP
>> without reading the ID first.
> 
> I think this idea is good but I am not sure how other vendor chips will react
> after getting the commands which are not supported on the flash.

Do any of these flashed define an extended ID, i.e. more that 3 bytes of ID?
Rasmus, would you please try to read more bytes of ID?