linux-kernel - Re: [PATCH v1 0/3] nvmem: Add support for write-only instances, and clean-up

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: <PSXP216MB043872618DA517085324FA0580ED0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM>
Date:   Tue, 25 Feb 2020 15:23:34 +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 v1 0/3] nvmem: Add support for write-only instances, and
 clean-up

On Tue, Feb 25, 2020 at 02:59:46PM +0000, Srinivas Kandagatla wrote:
> 
> 
> On 24/02/2020 17:41, Nicholas Johnson wrote:
> > [Based on Linux v5.6-rc3, does not apply successfully to Linux v5.6-rc2]
> > 
> > Hello all,
> > 
> > I offer the first patch in this series to support write-only instances
> > of nvmem. The use-case is the Thunderbolt driver, for which Mika
> > Westerberg needs write-only nvmem. Refer to 03cd45d2e219 ("thunderbolt:
> > Prevent crash if non-active NVMem file is read").
> > 
> 
> Had a look at the crash trace from the mentioned patch.
> 
> Why can not we add a check for reg_read in bin_attr_nvmem_read() before
> dereferencing it?
That can be easily done in PATCH v2. What error code should be returned?

> 
> The reason I ask this is because removing read_only is not that simple as
> you think.
> Firstly because a there is no way to derive this flag by just looking at
> read/write callbacks.
> Providers are much more generic drivers ex: at24 which can have read/write
> interfaces implemented, however read only flag is enforced at board/platform
> level config either via device tree property bindings or a write protection
> gpio.
> Removing this is also going to break the device tree bindings.
> 
> only alternative I can see ATM is the mentioned check.
> 
> --srini
Noted. However, the .read_only flag is only removed in the third patch, 
which can be discarded if you feel that is the best plan of action.

The write-only will not have a flag added, which should not be a 
problem, as nothing relies on there being one yet.

Regards,
Nicholas