Re: Question regarding runtime pinctrl (2nd try)

["andriy.shevchenko@xxxxxxxxx" <andriy.shevchenko@xxxxxxxxx>]

On Mon, Dec 05, 2022 at 10:47:27AM +0000, Niedermayr, BENEDIKT wrote:
> 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.

I meant that this feature quite likely will stay in the debugfs realm. No new
interface is needed for sure.

> Unfortunatelly there is no interface available for runtime configuration, yet.

There is no explanation why you need that.
This is the main point of this discussion, right?

> The only alternative 
> is to access "/dev/mem", but this is the most questionable solution from a security perspective.

It's not an alternative at all, it's simple no go variant.

> 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"

This is even worse than more standard /dev/mem interface.

> 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.  

Still no clue, what you are trying to achieve and why. Use case, please?

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

-- 
With Best Regards,
Andy Shevchenko