linux-kernel - Re: [RFC PATCH 2/2] regulator: add boot protection flag

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]

Message-ID: <20160426163625.GB3217@sirena.org.uk>
Date:	Tue, 26 Apr 2016 17:36:25 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Pingbo Wen <pingbo.wen@...aro.org>
Cc:	linux-kernel@...r.kernel.org, lgirdwood@...il.com,
	Vincent Guittot <vincent.guittot@...aro.org>,
	stephen.boyd@...aro.org
Subject: Re: [RFC PATCH 2/2] regulator: add boot protection flag

On Tue, Apr 26, 2016 at 07:46:07PM +0800, Pingbo Wen wrote:

> > This is still a complete hack which is going to break as soon as things
> > are built modular, it's definitely *not* something that should ever
> > appear in DT since it depends so heavily on implementation details.  If
> > you need some driver to start early work on getting that sorted.

> I think this patch can handle the case you mentioned. I have add a
> regulator_has_booted flag, and it will set in regulator_init_complete()
> late_initcall hook. The regulator_ops_is_valid() will ignore boot
> protection if this flag is set.

That doesn't help after we get to userspace so doesn't work as soon as
things are built as modules.  That's a key issue with making something
that's robust here.

> > This is also going to interact badly with any other drivers that are
> > trying to configure things at runtime, if they've done enables and
> > disables (or especially an enable without a matching disable) their

> Ok, I have to admit that the boot_protection didn’t cover this. If other
> consumer try to configure during booting, it will get some error code.
> And the consumers need to re-configure the regulator state after
> late_initcall.

The worst thing is where we silently accept but forget about things
because the code currently translates them into valid noops then later
start paying attention to the operations, error codes at least the other
driver can handle.

> If we need to hold the state of other consumer, I prefer using a
> dummy-consumer to hold this. And this is my next try.

Or possibly store the data on the consumer but don't act on it then go
round actually acting on it when we decide to do things - that's more
what I'd have expected and seems like it might be easier than creating a
separate object.

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