linux-kernel - Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf

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]

Message-ID: <a9bddf44-3a7f-b701-a4dd-030818b68f5a@microchip.com>
Date:   Wed, 20 Jan 2021 16:56:27 +0000
From:   <Tudor.Ambarus@...rochip.com>
To:     <michael@...le.cc>
CC:     <vigneshr@...com>, <p.yadav@...com>, <miquel.raynal@...tlin.com>,
        <richard@....at>, <linux-mtd@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <Kavyasree.Kotagiri@...rochip.com>
Subject: Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock
 on sst26vf

On 1/20/21 6:47 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2021-01-20 17:25, schrieb Tudor.Ambarus@...rochip.com:
>> On 1/20/21 5:49 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Am 2021-01-20 16:39, schrieb Tudor.Ambarus@...rochip.com:
>>>> On 1/20/21 5:02 PM, Michael Walle wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>>> know
>>>>> the content is safe
>>>>>
>>>>> Am 2021-01-20 15:52, schrieb Tudor.Ambarus@...rochip.com:
>>>>>> On 1/20/21 4:05 PM, Michael Walle wrote:
>>>>>>>> diff --git a/drivers/mtd/spi-nor/sst.c
>>>>>>>> b/drivers/mtd/spi-nor/sst.c
>>>>>>>> index 00e48da0744a..d6e1396abb96 100644
>>>>>>>> --- a/drivers/mtd/spi-nor/sst.c
>>>>>>>> +++ b/drivers/mtd/spi-nor/sst.c
>>>>>>>> @@ -8,6 +8,39 @@
>>>>>>>>
>>>>>>>>  #include "core.h"
>>>>>>>>
>>>>>>>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs,
>>>>>>>> uint64_t
>>>>>>>> len)
>>>>>>>> +{
>>>>>>>> +     return -EOPNOTSUPP;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs,
>>>>>>>> uint64_t
>>>>>>>> len)
>>>>>>>> +{
>>>>>>>> +     if (ofs == 0 && len == nor->params->size)
>>>>>>>> +             return spi_nor_global_block_unlock(nor);
>>>>>>>
>>>>>>>
>>>>>>> Some blocks might not be unlocked because they are permanently
>>>>>>> locked. Does it make sense to read BPNV of the control register
>>>>>>> and add a debug message here?
>>>>>>
>>>>>> It would, yes. If any block is permanently locked in the unlock_all
>>>>>> case,
>>>>>> I'll just print a dbg message and return -EINVAL. Sounds good?
>>>>>
>>>>> spi_nor_sr_unlock(), atmel_at25fs_unlock() and
>>>>> atmel_global_unprotect()
>>>>> will return -EIO in case the SR wasn't writable.
>>>>
>>>> You mean in the spi_nor_write_sr_and_check() calls. -EIO is fine
>>>> there if what we wrote is different than what we read back, it would
>>>> indicate an IO error.
>>>>
>>>> GBULK command clears all the write-protection bits in the Block
>>>> Protection register, except for those bits that have been permanently
>>>> locked down. So even if we have few blocks permanently locked, i.e.
>>>> CR.BPNV == 1, the GBULK can clear the protection for the remaining
>>>> blocks. So not really an IO error, but rather an -EINVAL, because
>>>> the user asks to unlock more than we can.
>>>
>>> Doesn't EINVAL indicate wrong parameters, but does nothing? In this
>>> case, unlock would be partially successful.
>>>
>> yes, that's what I said I'll do: "If any block is permanently locked
>> in the unlock_all case, I'll just print a dbg message and return
>> -EINVAL",
>> without sending a GBULK cmd. Caller wrongly asks to unlock all, when we
>> can just unlock partial memory.
> 
> Doh, I've missed that you will do it beforehand. Yes then EINVAL
> is fine by me.
> 
> But you won't unlock the flash during startup (given the config option
> is enabled) if any blocks has been permanently locked. Thus if just the
> topmost 4k block is permanently locked down, the whole flash wouldn't be
> writable, right?. I don't have a strong opinion on that.

Correct. I don't see problems with that. Individual Block protection
with unlock on a smaller granularity can be added later on, and the
behavior during boot will remain the same.

Cheers,
ta