linux-kernel - Re: [PATCH] mtd: spi-nor: mt25qu: Ignore 6th ID byte

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:   Tue, 23 Nov 2021 16:14:43 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <michael@...le.cc>, <alexander.sverdlin@...ia.com>
CC:     <linux-mtd@...ts.infradead.org>, <p.yadav@...com>,
        <miquel.raynal@...tlin.com>, <richard@....at>, <vigneshr@...com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: mt25qu: Ignore 6th ID byte

On 11/23/21 4:01 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi,
> 
> Am 2021-11-23 13:40, schrieb Alexander Sverdlin:
>> On 23/11/2021 09:14, Michael Walle wrote:
>>>>
>>>> Some people ask themselves why this table keeps growing if there is
>>>> SFDP...
>>>> I see the point in fixups, but maybe at some point we will be able to
>>>> support
>>>> some devices just out of the box?
>>>
>>> Are these features detectable by SFDP? Without knowing anything, as
>>> you ignored
>>> my former question, I'd say no.
>>
>> Well, I just had nothing to say on your question.
>> It wasn't my intention to study security features of a chip, which I
>> don't use.
> 
> Like I said, without that information its hard for me do decide if we
> can just
> ignore that last byte. (And yes I've already tried to get that NDA PDF
> via $WORK,
> but I don't have high hopes with that).
> 

It would be nice to understand what is the difference between the two,
otherwise keeping a single flash entry will become a maintenance burden.
For example, what is the difference between the "top/bottom block address
protection lock" and the BIT(5) (Top/Bottom) of the Status Register?

Is the newer flash completely backward compatible with the 0x00 variant?
I'm not talking about the flash_info flags that are currently specified
in the flash_info entry, but about all the features of the 0x00 version
(also the ones that are not implemented in linux SPI NOR).

If the newer flash is fully backward compatible with the older one,
it should be fine to strip the 6th byte of ID. As Michael has suggested,
if the security features are not SFDP discoverable (either via a generic
table or a vendor specific table) and one wants to use/implement the
security features, one will have to revert the patch that drops the 6th
byte of ID, and to introduce a new flash_info entry anyway.

Cheers,
ta