Depends on:
https://lore.kernel.org/all/[email protected]/T/
Tudor Ambarus (2):
mtd: spi-nor: Fix shift-out-of-bounds
mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set
drivers/mtd/spi-nor/core.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
--
2.25.1
SPI_NOR_NO_ERASE is used either by F-RAMs, or MRAMs, or EEPROMs,
neither of which supports SFDP, so once SPI_NOR_NO_ERASE is set,
SFDP can not undo it. These type of flashes should be moved out of
the SPI NOR core anyway, so don't complicate things and just skip
the erase logic when SPI_NOR_NO_ERASE is set. Normally SPI NOR core
should operate just on SNOR_F flags, but since SPI_NOR_NO_ERASE
should be removed, don't bother with extra code.
Signed-off-by: Tudor Ambarus <[email protected]>
---
drivers/mtd/spi-nor/core.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index a1b5d5432f41..52c82d943499 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2680,6 +2680,9 @@ static void spi_nor_skip_sfdp_init_params(struct spi_nor *nor)
SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
}
+ if (info_flags & SPI_NOR_NO_ERASE)
+ return;
+
/*
* Sector Erase settings. Sort Erase Types in ascending order, with the
* smallest erase size starting at BIT(0).
@@ -3195,12 +3198,13 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor)
mtd->name = dev_name(dev);
mtd->type = MTD_NORFLASH;
mtd->flags = MTD_CAP_NORFLASH;
- if (nor->info->flags & SPI_NOR_NO_ERASE)
+ if (nor->info->flags & SPI_NOR_NO_ERASE) {
+ mtd->_erase = spi_nor_erase;
mtd->flags |= MTD_NO_ERASE;
+ }
mtd->writesize = nor->params->writesize;
mtd->writebufsize = nor->params->page_size;
mtd->size = nor->params->size;
- mtd->_erase = spi_nor_erase;
mtd->_read = spi_nor_read;
/* Might be already set by some SST flashes. */
if (!mtd->_write)
--
2.25.1
When paring SFDP we may choose to mask out an erase type, passing
an erase size of zero to spi_nor_set_erase_type().
Fix shift-out-of-bounds and just clear the erase params when
passing zero for erase size.
While here avoid a superfluous dereference and use 'size' directly.
UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
shift exponent 4294967295 is too large for 32-bit type 'int'
Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories")
Reported-by: Alexander Stein <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
---
drivers/mtd/spi-nor/core.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 3d97c189c332..a1b5d5432f41 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2230,8 +2230,13 @@ void spi_nor_set_erase_type(struct spi_nor_erase_type *erase, u32 size,
erase->size = size;
erase->opcode = opcode;
/* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
- erase->size_shift = ffs(erase->size) - 1;
- erase->size_mask = (1 << erase->size_shift) - 1;
+ if (size) {
+ erase->size_shift = ffs(size) - 1;
+ erase->size_mask = (1 << erase->size_shift) - 1;
+ } else {
+ erase->size_shift = 0;
+ erase->size_mask = 0;
+ }
}
/**
--
2.25.1
Am Samstag, dem 06.11.2021 um 09:56 +0200 schrieb Tudor Ambarus:
> When paring SFDP we may choose to mask out an erase type, passing
> an erase size of zero to spi_nor_set_erase_type().
> Fix shift-out-of-bounds and just clear the erase params when
> passing zero for erase size.
> While here avoid a superfluous dereference and use 'size' directly.
>
> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
> shift exponent 4294967295 is too large for 32-bit type 'int'
>
> Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP
> SPI NOR flash memories")
> Reported-by: Alexander Stein <
> [email protected]
> >
> Signed-off-by: Tudor Ambarus <
> [email protected]
> >
> ---
> drivers/mtd/spi-nor/core.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 3d97c189c332..a1b5d5432f41 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2230,8 +2230,13 @@ void spi_nor_set_erase_type(struct
> spi_nor_erase_type *erase, u32 size,
> erase->size = size;
> erase->opcode = opcode;
> /* JEDEC JESD216B Standard imposes erase sizes to be power of
> 2. */
> - erase->size_shift = ffs(erase->size) - 1;
> - erase->size_mask = (1 << erase->size_shift) - 1;
> + if (size) {
> + erase->size_shift = ffs(size) - 1;
> + erase->size_mask = (1 << erase->size_shift) - 1;
> + } else {
> + erase->size_shift = 0;
> + erase->size_mask = 0;
> + }
> }
>
> /**
Tested-By: Alexander Stein <[email protected]>
It fixes the UBSAN error and my spi-nor flash can still be detected.
Best regards,
Alexander
On 06/11/21 09:56AM, Tudor Ambarus wrote:
> When paring SFDP we may choose to mask out an erase type, passing
> an erase size of zero to spi_nor_set_erase_type().
> Fix shift-out-of-bounds and just clear the erase params when
> passing zero for erase size.
> While here avoid a superfluous dereference and use 'size' directly.
>
> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
> shift exponent 4294967295 is too large for 32-bit type 'int'
>
> Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories")
> Reported-by: Alexander Stein <[email protected]>
> Signed-off-by: Tudor Ambarus <[email protected]>
> ---
> drivers/mtd/spi-nor/core.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 3d97c189c332..a1b5d5432f41 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2230,8 +2230,13 @@ void spi_nor_set_erase_type(struct spi_nor_erase_type *erase, u32 size,
> erase->size = size;
> erase->opcode = opcode;
> /* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
The change itself looks fine to me. So,
Reviewed-by: Pratyush Yadav <[email protected]>
But I wonder if this code is doing the right thing. If a flash is
setting an incorrect erase size, shouldn't we fail loudly to make sure
the error is corrected, instead of working around it silently?
If you don't want to return an error here, how about:
WARN_ON(ffs(size) != fls(size))
or even a dev_warn() print so the programmer is aware of this.
> - erase->size_shift = ffs(erase->size) - 1;
> - erase->size_mask = (1 << erase->size_shift) - 1;
> + if (size) {
> + erase->size_shift = ffs(size) - 1;
> + erase->size_mask = (1 << erase->size_shift) - 1;
> + } else {
> + erase->size_shift = 0;
> + erase->size_mask = 0;
> + }
> }
>
> /**
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
On 06/11/21 09:56AM, Tudor Ambarus wrote:
> SPI_NOR_NO_ERASE is used either by F-RAMs, or MRAMs, or EEPROMs,
> neither of which supports SFDP, so once SPI_NOR_NO_ERASE is set,
> SFDP can not undo it. These type of flashes should be moved out of
> the SPI NOR core anyway, so don't complicate things and just skip
> the erase logic when SPI_NOR_NO_ERASE is set. Normally SPI NOR core
> should operate just on SNOR_F flags, but since SPI_NOR_NO_ERASE
> should be removed, don't bother with extra code.
>
> Signed-off-by: Tudor Ambarus <[email protected]>
> ---
> drivers/mtd/spi-nor/core.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index a1b5d5432f41..52c82d943499 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2680,6 +2680,9 @@ static void spi_nor_skip_sfdp_init_params(struct spi_nor *nor)
> SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
> }
>
> + if (info_flags & SPI_NOR_NO_ERASE)
> + return;
> +
> /*
> * Sector Erase settings. Sort Erase Types in ascending order, with the
> * smallest erase size starting at BIT(0).
> @@ -3195,12 +3198,13 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor)
> mtd->name = dev_name(dev);
> mtd->type = MTD_NORFLASH;
> mtd->flags = MTD_CAP_NORFLASH;
> - if (nor->info->flags & SPI_NOR_NO_ERASE)
> + if (nor->info->flags & SPI_NOR_NO_ERASE) {
> + mtd->_erase = spi_nor_erase;
You only set mtd->_erase when SPI_NOR_NO_ERASE is set? That does not
make any sense to me. It should be the opposite.
> mtd->flags |= MTD_NO_ERASE;
> + }
> mtd->writesize = nor->params->writesize;
> mtd->writebufsize = nor->params->page_size;
> mtd->size = nor->params->size;
> - mtd->_erase = spi_nor_erase;
> mtd->_read = spi_nor_read;
> /* Might be already set by some SST flashes. */
> if (!mtd->_write)
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
Hello,
Am Samstag, 6. November 2021, 08:56:15 CET schrieb Tudor Ambarus:
> When paring SFDP we may choose to mask out an erase type, passing
> an erase size of zero to spi_nor_set_erase_type().
> Fix shift-out-of-bounds and just clear the erase params when
> passing zero for erase size.
> While here avoid a superfluous dereference and use 'size' directly.
>
> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
> shift exponent 4294967295 is too large for 32-bit type 'int'
>
> Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR
> flash memories") Reported-by: Alexander Stein
> <[email protected]>
> Signed-off-by: Tudor Ambarus <[email protected]>
> ---
> drivers/mtd/spi-nor/core.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 3d97c189c332..a1b5d5432f41 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2230,8 +2230,13 @@ void spi_nor_set_erase_type(struct spi_nor_erase_type
> *erase, u32 size, erase->size = size;
> erase->opcode = opcode;
> /* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
> - erase->size_shift = ffs(erase->size) - 1;
> - erase->size_mask = (1 << erase->size_shift) - 1;
> + if (size) {
> + erase->size_shift = ffs(size) - 1;
> + erase->size_mask = (1 << erase->size_shift) - 1;
> + } else {
> + erase->size_shift = 0;
> + erase->size_mask = 0;
> + }
> }
>
> /**
What is the status of this patch? It is not applied up until now, no? Has it
been superseeded?
Regards,
Alexander
On 3/16/22 09:39, Alexander Stein wrote:
> [You don't often get email from [email protected]. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hello,
hi,
>
> Am Samstag, 6. November 2021, 08:56:15 CET schrieb Tudor Ambarus:
>> When paring SFDP we may choose to mask out an erase type, passing
>> an erase size of zero to spi_nor_set_erase_type().
>> Fix shift-out-of-bounds and just clear the erase params when
>> passing zero for erase size.
>> While here avoid a superfluous dereference and use 'size' directly.
>>
>> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
>> shift exponent 4294967295 is too large for 32-bit type 'int'
>>
>> Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR
>> flash memories") Reported-by: Alexander Stein
>> <[email protected]>
>> Signed-off-by: Tudor Ambarus <[email protected]>
>> ---
>> drivers/mtd/spi-nor/core.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 3d97c189c332..a1b5d5432f41 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -2230,8 +2230,13 @@ void spi_nor_set_erase_type(struct spi_nor_erase_type
>> *erase, u32 size, erase->size = size;
>> erase->opcode = opcode;
>> /* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
>> - erase->size_shift = ffs(erase->size) - 1;
>> - erase->size_mask = (1 << erase->size_shift) - 1;
>> + if (size) {
>> + erase->size_shift = ffs(size) - 1;
>> + erase->size_mask = (1 << erase->size_shift) - 1;
>> + } else {
>> + erase->size_shift = 0;
>> + erase->size_mask = 0;
>> + }
>> }
>>
>> /**
>
> What is the status of this patch? It is not applied up until now, no? Has it
> been superseeded?
>
I think it's marked with "changes requested". I'm going to send a v2.
Hi Tudor,
Am Mittwoch, 16. M?rz 2022, 08:47:40 CET schrieb [email protected]:
> On 3/16/22 09:39, Alexander Stein wrote:
>
> > [You don't often get email from [email protected]. Learn why
> > this is important at http://aka.ms/LearnAboutSenderIdentification.]
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> > Hello,
>
>
> hi,
>
>
> >
> > Am Samstag, 6. November 2021, 08:56:15 CET schrieb Tudor Ambarus:
> >
> >> When paring SFDP we may choose to mask out an erase type, passing
> >> an erase size of zero to spi_nor_set_erase_type().
> >> Fix shift-out-of-bounds and just clear the erase params when
> >> passing zero for erase size.
> >> While here avoid a superfluous dereference and use 'size' directly.
> >>
> >>
> >>
> >> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
> >> shift exponent 4294967295 is too large for 32-bit type 'int'
> >>
> >>
> >>
> >> Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI
> >> NOR
flash memories") Reported-by: Alexander Stein
> >> <[email protected]>
> >> Signed-off-by: Tudor Ambarus <[email protected]>
> >> ---
> >>
> >> drivers/mtd/spi-nor/core.c | 9 +++++++--
> >> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >>
> >>
> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> >> index 3d97c189c332..a1b5d5432f41 100644
> >> --- a/drivers/mtd/spi-nor/core.c
> >> +++ b/drivers/mtd/spi-nor/core.c
> >> @@ -2230,8 +2230,13 @@ void spi_nor_set_erase_type(struct
> >> spi_nor_erase_type
*erase, u32 size, erase->size = size;
> >>
> >> erase->opcode = opcode;
> >> /* JEDEC JESD216B Standard imposes erase sizes to be power of 2.
> >> */
> >>
> >> - erase->size_shift = ffs(erase->size) - 1;
> >> - erase->size_mask = (1 << erase->size_shift) - 1;
> >> + if (size) {
> >> + erase->size_shift = ffs(size) - 1;
> >> + erase->size_mask = (1 << erase->size_shift) - 1;
> >> + } else {
> >> + erase->size_shift = 0;
> >> + erase->size_mask = 0;
> >> + }
> >>
> >> }
> >>
> >>
> >>
> >> /**
> >
> >
> > What is the status of this patch? It is not applied up until now, no? Has
> > it
been superseeded?
> >
>
>
> I think it's marked with "changes requested". I'm going to send a v2.
Is there a v2 somewhere?
Best regards,
Alexander