Message-ID: <PSXP216MB04383EBB7FFBAEA7D9ABCAEE80E20@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM>
Date:   Thu, 5 Mar 2020 18:11:45 +0000
From:   Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH v2 1/3] nvmem: Add support for write-only instances

On Thu, Mar 05, 2020 at 05:03:11PM +0000, Srinivas Kandagatla wrote:
> 
> On 02/03/2020 15:42, Nicholas Johnson wrote:
> > There is at least one real-world use-case for write-only nvmem
> > instances. Refer to 03cd45d2e219 ("thunderbolt: Prevent crash if
> > non-active NVMem file is read").
> > 
> > Add support for write-only nvmem instances by adding attrs for 0200.
> > 
> > Change nvmem_register() to abort if NULL group is returned from
> > nvmem_sysfs_get_groups().
> > 
> > Return NULL from nvmem_sysfs_get_groups() in invalid cases.
> > 
> 
> > Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>
> > ---
> >   drivers/nvmem/core.c        |  2 ++
> >   drivers/nvmem/nvmem-sysfs.c | 53 ++++++++++++++++++++++++++++++++-----
> >   2 files changed, 48 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > index ef326f243..27bd4c4e3 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -388,6 +388,8 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
> >   			   config->read_only || !nvmem->reg_write;
> >   	nvmem->dev.groups = nvmem_sysfs_get_groups(nvmem, config);
> > +	if (!nvmem->dev.groups)
> > +		return NULL;
> Returning here will be leaking in this function.
Oops, I had thought about that but missed it. Will kfree(nvmem) in next 
revision of this patch. I will probably break this change off into 
another commit to make each commit smaller and do one thing.

> 
> >   	device_initialize(&nvmem->dev);
> > diff --git a/drivers/nvmem/nvmem-sysfs.c b/drivers/nvmem/nvmem-sysfs.c
> > index 9e0c429cd..00d3259ea 100644
> > --- a/drivers/nvmem/nvmem-sysfs.c
> > +++ b/drivers/nvmem/nvmem-sysfs.c
> > @@ -196,16 +196,50 @@ static const struct attribute_group *nvmem_ro_root_dev_groups[] = {
> >   	NULL,
> >   };
> > +/* write only permission, root only */
> > +static struct bin_attribute bin_attr_wo_root_nvmem = {
> 
> TBH, you would not need this patch once 2/3 patch is applied.
> Unless there is a strong reason for you to have write only file.
This was the whole reason. The Thunderbolt NULL dereference was because 
write-only was needed but not available. Mika Westerberg thought that by 
not providing reg_read, the nvmem would become write-only. I discovered 
the NULL dereference and that is why I am here - to provide the 
sought-after write-only support. So yes, there is a reason to have 
write-only.

> 
> If for any reasons you would want to add Write only file then it should be
> added for both with root and user privileges.
Mika just advised me that we should not have world-writable files, so it 
sounds like this needs some discussion between us. I am happy to provide 
this if that is desired, as the world-writable will presumably only be 
used if there is a driver that asks for it and has a good reason to use 
it, so it should not be unsafe.

Part of me agrees that there should be no need for world-writable (I 
cannot think of a use-case) but the other part knows that something 
could come along, and that we should cover all bases. Just like we did 
not see the need for write-only.

> 
> >   const struct attribute_group **nvmem_sysfs_get_groups(
> >   					struct nvmem_device *nvmem,
> >   					const struct nvmem_config *config)
> >   {
> > -	if (config->root_only)
> > -		return nvmem->read_only ?
> > -			nvmem_ro_root_dev_groups :
> > -			nvmem_rw_root_dev_groups;
> > -
> > -	return nvmem->read_only ? nvmem_ro_dev_groups : nvmem_rw_dev_groups;
> > +	/* Read-only */
> > +	if (nvmem->reg_read && (!nvmem->reg_write || nvmem->read_only))
> > +		return config->root_only ?
> > +			nvmem_ro_root_dev_groups : nvmem_ro_dev_groups;
> > +
> > +	/* Read-write */
> > +	if (nvmem->reg_read && nvmem->reg_write)
> 
> read_only flag will override this assumption!
If reg_read != NULL and read_only set then we have already returned. 
Setting read_only and having reg_read == NULL is clearly broken 
behaviour. How about I explicitly check for reg_read == NULL and 
read_only set, and return NULL?

> 
> > +		return config->root_only ?
> > +			nvmem_rw_root_dev_groups : nvmem_rw_dev_groups;
> > +
> > +	/* Write-only, do not honour request for global writable entry */
> > +	if (!nvmem->reg_read && nvmem->reg_write)
> > +		return config->root_only ? nvmem_wo_root_dev_groups : NULL;
> > +
> > +	/* Neither reg_read nor reg_write are provided, abort */
> This should not be the case anymore after this check in place
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git/commit/?h=for-next&id=f8f782f63bace8b08362e466747e648ca57b6c06
Nice. I can change the comment, but all code paths need a return value. 
I do not know if the compiler is smart enough to figure out that the 
final return statement is unreachable. So I will still be returning NULL 
at the end to avoid warnings.

> 
> thanks,
> srini
Thanks for reviewing.
Kind regards,
Nicholas

> 
> > +	return NULL;
> >   }
> >   /*
> > @@ -224,11 +258,16 @@ int nvmem_sysfs_setup_compat(struct nvmem_device *nvmem,
> >   	if (!config->base_dev)
> >   		return -EINVAL;
> > -	if (nvmem->read_only) {
> > +	if (nvmem->reg_read && (!nvmem->reg_write || nvmem->read_only)) {
> >   		if (config->root_only)
> >   			nvmem->eeprom = bin_attr_ro_root_nvmem;
> >   		else
> >   			nvmem->eeprom = bin_attr_ro_nvmem;
> > +	} else if (!nvmem->reg_read && nvmem->reg_write) {
> > +		if (config->root_only)
> > +			nvmem->eeprom = bin_attr_wo_root_nvmem;
> > +		else
> > +			return -EPERM;
> >   	} else {
> >   		if (config->root_only)
> >   			nvmem->eeprom = bin_attr_rw_root_nvmem;
> > 

Powered by blists - more mailing lists