linux-kernel - Re: [PATCH 5/5] nvmem: Add support for write-only instances

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: <PSXP216MB04387C07F1E4C827245DE98380F10@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM>
Date:   Tue, 24 Mar 2020 14:24:21 +0000
From:   Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
CC:     Greg KH <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/5] nvmem: Add support for write-only instances

On Tue, Mar 24, 2020 at 01:25:46PM +0000, Srinivas Kandagatla wrote:
> 
> 
> On 24/03/2020 12:29, Greg KH wrote:
> > > But the Idea here is :
> > > We ended up with providing different options like read-only,root-only to
> > > nvmem providers combined with read/write callbacks.
> > > With that, there are some cases which are totally invalid, existing code
> > > does very minimal check to ensure that before populating with correct
> > > attributes to sysfs file. One of such case is with thunderbolt provider
> > > which supports only write callback.
> > > 
> > > With this new checks in place these flags and callbacks are correctly
> > > validated, would result in correct file attributes.
> > Why this crazy set of different groups?  You can set the mode of a sysfs
> > file in the callback for when the file is about to be created, that's so
> > much simpler and is what it is for.  This feels really hacky and almost
> > impossible to follow:(
> Thanks for the inputs, That definitely sounds much simpler to deal with.
> 
> Am guessing you are referring to is_bin_visible callback?
> 
> I will try to clean this up!
I am still onboard and willing do the work, but we may need to discuss
to be on the same page with new plans. How do you wish to do this?

Does this new approach still allow us to abort if we receive an invalid
configuration? Or do we still need to have something in nvmem_register()
to abort in invalid case?

The documentation of is_bin_visible says only read/write permissions are 
accepted. Does this mean that it will not take read-only or write-only? 
That is one way of interpreting it.

I am further studying up on what was said in this email chain.

Regards,
Nicholas

> 
> thanks,
> srini
> > 
> > thanks,
> > 
> > greg k-h