linux-kernel - Re: [RFC] regmap: allow volatile register writes with cached only read maps

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] [day] [month] [year] [list]

Date:   Thu, 17 May 2018 18:04:11 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jorge Ramirez-Ortiz <jramirez@...libre.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RFC] regmap: allow volatile register writes with cached only
 read maps

On Thu, May 17, 2018 at 09:12:49AM +0200, Jorge Ramirez-Ortiz wrote:
> On 05/13/2018 04:22 AM, Mark Brown wrote:

> > > So I dont see where/how your recommendation fits; maybe you could clarify a
> > > bit more please?

> > As I've been saying if you explicitly need a write to happen don't use
> > regmap_update_bits(), do something that guarantees you'll get a write
> > like regmap_write() or regmap_write_bits().

> I do understand your point but Mark, that interface you mention sits above
> the user request (as a client the user does not call regmap_update_bits or
> regmap_write_bits or regmap_write(): none of those functions mean anything
> to the foo_regmap definition below - that is why we have an interface).

...

> and all this request means is that it expects foo_volatile_regs to be taken
> into consideration when accessing the reg_write callback: so whoever is
> calling the interface reg_write (be it regmap_update_bits or
> regmap_write_bits or whoever it is, I dont know) must make sure the volatile
> request applies.

Right, but your code can expect a lot of things and not have them happen
if they're not good expectations - that's explicitly not what we've been
meaning by volatile registers (they're just registers that can't be
cached).  I mean, you mentioned that you were doing this for an ALSA
control and since ALSA reports noop updates to userspace it'd be
entirely reasonable for an implementation change there were to suppress
the write before it gets to regmap (this is the sort of thing I was
thinking of when I said I was suspicious of what you're doing there,
this doesn't sound like a normal ALSA control).

I get what you're saying, it just doesn't feel like this is the right
place to solve whatever your end use case is, it feels like it's going
to be fragile one way or another and end up adding more complexity -
having a hand coded ALSA control for this feels more secure at that
level never mind anything that's going on in regmap. 

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)