linux-kernel - Re: [PATCH] regmap: Add a config option for making regmap debugfs writable

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: <20151013200700.GM14956@sirena.org.uk>
Date:	Tue, 13 Oct 2015 21:07:00 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Anatol Pomozov <anatol.pomozov@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regmap: Add a config option for making regmap debugfs
 writable

On Tue, Oct 13, 2015 at 11:33:13AM -0700, Anatol Pomozov wrote:
> On Tue, Oct 13, 2015 at 10:55 AM, Mark Brown <broonie@...nel.org> wrote:

> > This is deliberately not a Kconfig option because it is a terrible idea
> > to do this in production and making it either selectable or the default
> > is an invitation to abuse.

> What kind of abuse are you talking about?

Using it as a standard interface to control systems in production rather
than having appropriate support in the relevant driver.

> Having an easy way of modifying chip registers is extremely useful
> during bringup / driver development. And during device development
> phase I regularly have situations when I need to change a register to
> see if it fixes an issue. Sometimes I need to test it remotely when
> users located at another end of the Earth.

This is exactly the sort of use case this feature is intended for, and
is the sort of situation where a custom kernel is not going to be any
kind of practical problem.

> Current kernel source suggests I need to modify regmap-debugfs.c
> directly. But my kernel tree is shared by multiply products and some
> of the products in production already. I do not want to enable
> writable remap for production products. I would like to have a
> per-product compile-time configuration and .config serves exactly this
> purpose.

Feel free to make that modification in your local tree if you want it,
I'm not going to take it for upstream.

> > We want to place a barrier here so that
> > users know that this is something that they have taken a decision to
> > enable, not something that is in any way supported (this is also why we
> > taint the kernel when people do write).

> Honestly I am not convinced. Why to put obstacles on a feature that is
> very useful during development?

We don't want people complaining when someone misprograms their PMIC or
battery charger in a production system because a debug feature got left
on by mistake (both components that frequently use regmap and both
components that have the capacity to physically damage the system), or
have someone decide that the way to tune their system is to turn on this
option and bang on the hardware from userspace bypassing the driver.
It's really handy for debug but it's terrible for system robustness and
stability.

The whole point is that this is only intended to be used during
development while modifying the kernel, if you're able to do that it's
not a meningful obstacle.

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