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: <c62393288e9d82b08d14d74a9a8389ad@walle.cc>
Date:   Wed, 20 Jan 2021 17:47:25 +0100
From:   Michael Walle <michael@...le.cc>
To:     Tudor.Ambarus@...rochip.com
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

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.

-michael

> 
> It's similar to what is at:
> https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/drivers/mtd/spi-nor/core.c?h=spi-nor/next#n1946
> 
>> In any case, my point was that depending on the underlying locking
>> ops, either -EIO or -EINVAL is returned if spi_nor_unlock() fails
>> for the same reason, that is unlock() wasn't possible because of
>> some sort of hardware write protection. And IMHO it should return
>> the same errno (whatever the correct errno is in this case).
>> 
> 
> But the reasons are different: 1/caller wrongly asks to unlock
> more than we can, thus -EINVAL 2/ -EIO when we don't read what
> we expect to read.

-michael