linux-hardening - Re: [PATCH v2 07/14] mfd: zl3073x: Add components versions register defs

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: <8c5fb149-af25-4713-a9c8-f49b516edbff@lunn.ch>
Date: Thu, 10 Apr 2025 23:54:16 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, netdev@...r.kernel.org,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
	Jiri Pirko <jiri@...nulli.us>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Prathosh Satish <Prathosh.Satish@...rochip.com>,
	Lee Jones <lee@...nel.org>, Kees Cook <kees@...nel.org>,
	Andy Shevchenko <andy@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Schmidt <mschmidt@...hat.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 07/14] mfd: zl3073x: Add components versions register
 defs

On Thu, Apr 10, 2025 at 08:44:43PM +0200, Ivan Vecera wrote:
> 
> 
> On 10. 04. 25 7:41 odp., Andrew Lunn wrote:
> > > > > +	/* Take device lock */
> > > > 
> > > > What is a device lock? Why do you need to comment standard guards/mutexes?
> > > 
> > > Just to inform code reader, this is a section that accesses device registers
> > > that are protected by this zl3073x device lock.
> > 
> > I didn't see a reply to my question about the big picture. Why is the
> > regmap lock not sufficient. Why do you need a device lock.
> > 
> > > 
> > > > > +	scoped_guard(zl3073x, zldev) {
> > > > > +		rc = zl3073x_read_id(zldev, &id);
> > > > > +		if (rc)
> > > > > +			return rc;
> > > > > +		rc = zl3073x_read_revision(zldev, &revision);
> > > > > +		if (rc)
> > > > > +			return rc;
> > > > > +		rc = zl3073x_read_fw_ver(zldev, &fw_ver);
> > > > > +		if (rc)
> > > > > +			return rc;
> > > > > +		rc = zl3073x_read_custom_config_ver(zldev, &cfg_ver);
> > > > > +		if (rc)
> > > > > +			return rc;
> > > > > +	}
> > > > 
> > > > Nothing improved here. Andrew comments are still valid and do not send
> > > > v3 before the discussion is resolved.
> > > 
> > > I'm accessing device registers here and they are protected by the device
> > > lock. I have to take the lock, register access functions expect this by
> > > lockdep_assert.
> > 
> > Because lockdep asserts is not a useful answer. Locks are there to
> > protect you from something. What are you protecting yourself from? If
> > you cannot answer that question, your locking scheme is built on sand
> > and very probably broken.
> > 
> >      Andrew
> 
> Hi Andrew,
> I have described the locking requirements under different message [v1
> 05/28]. Could you please take a look?

So a small number of registers in the regmap need special locking. It
was not clear to me what exactly those locking requirements are,
because they don't appear to be described.

But when i look at the code above, the scoped guard gives the
impression that i have to read id, revision, fw_vr and cfg_ver all in
one go without any other reads/writes happening. I strongly suspect
that impression is wrong. The question then becomes, how can i tell
apart reads/writes which do need to be made as one group, form others
which can be arbitrarily ordered with other read/writes.

What i suggest you do is try to work out how to push the locking down
as low as possible. Make the lock cover only what it needs to cover.

Probably for 95% of the registers, the regmap lock is sufficient.

Just throwing out ideas, i've no idea if they are good or not. Create
two regmaps onto your i2c device, covering different register
ranges. The 'normal' one uses standard regmap locking, the second
'special' one has locking disabled. You additionally provide your own
lock functions to the 'normal' one, so you have access to the
lock. When you need to access the mailboxes, take the lock, so you
know the 'normal' regmap cannot access anything, and then use the
'special' regmap to do what you need to do. A structure like this
should help explain what the special steps are for those special
registers, while not scattering wrong ideas about what the locking
scheme actually is all over the code.

	Andrew