Re: Question regarding runtime pinctrl (2nd try)

["Niedermayr, BENEDIKT" <benedikt.niedermayr@xxxxxxxxxxx>]

Hi Andy,
thanks for the response!

On Wed, 2022-11-30 at 17:43 +0200, Andy Shevchenko wrote:
> On Wed, Nov 30, 2022 at 03:09:50PM +0000, Niedermayr, BENEDIKT wrote:
> > Hello,
> > 
> > I got no response since last time so I try it again, but with a bit more
> > knowledge this time.
> > 
> > After carefully reading the pinctrl documentation
> > (driver-api/pin-control.rst) it was very clear for me that such an interface
> > already exists and is accessable via debugfs. The documentation is very clear
> > and self-explanatory. Thanks for that!
> > At the time of writing my last email [1] I took a look into an older BSP
> > kernel where this feature has not been implemented, yet. I must apologize for
> > that...
> > 
> > Now my last concern is using debugfs on a productive system. IMHO debugfs is
> > not the right interface to interact on a productive system.
> 
> And this is a point. No-one should try it on the production systems.
> 
> > Especially when
> > when a unprivileged process wants to interact with an interface offered by
> > debugfs. It's possible to change
> > permissions on files and folders there but nevertheless I think that this is
> > not the way to go, since debugfs was designed to offer interfaces to
> > privileged processes only.
> 
> Correct.
> 
> > My proposal would be to implement an chardev interface for that and using
> > udev rules to assign correct permissions to that. With this interface I can
> > then select the active pinctrl-groups which have been defined in the device
> > tree before.
> > I could also imagine to put the interface into the sysfs (that would be very
> > close to the debugfs implementation I think).
> > 
> > What do you think about it? Am I still missing something?
> 
> In my opinion -- no go.
> 
> The platform description (ACPI, DT, or board files) should know what they are
> doing. If something missing to achieve what you need via existing interfaces
> we rather think about that, but no, the debugfs stays and only for the purposes
> of development on the "I know what I'm doing" basis.
> 
Ok. If I got you right, you meant that there is no way to replace the debugfs interface?

So instead replacing the debugfs interface I would rather add a second interface that coexists with
debugfs.  

Unfortunatelly there is no interface available for runtime configuration, yet. The only alternative 
is to access "/dev/mem", but this is the most questionable solution from a security perspective.
There should be a way to avoid unsecure "/dev/mem" implementations but currently this is the only
way to achieve runtime configuration with reasonable effort. 
IMHO the current architecture leads to lot of unsecure implementations out there.

For example the raspberrypi kernel tries to workaround this issue by providing a "/dev/gpiomem"
interface that only provides mappings to the gpio register set(drivers/char/broadcom/bcm2835-gpiomem.c). 
This reduces possible vulnerabilities but they still persist since:

- mmap() cannot map memory less than PAGE_SIZE, which means that memory outside of the GPIO registers is accessable. 
- it's possible to select untested  pin configurations which may not be electrical fine.


I like the current architecture since I define pingroups in the platform description which have been tested and 
then select one of them during runtime.
It's just the interface itself which is not sufficient enough when it comes to security.  

> > [1] https://marc.info/?l=linux-gpio&m=166850640920120


cheers,
Benedikt