Re: libgpiod API v2 release

[Dimitri John Ledkov <dimitri.ledkov@canonical.com>]

Hi,

On 14/07/2022 04:10, Kent Gibson wrote:
> On Tue, Jul 12, 2022 at 09:48:45AM +0200, Alexandre Ghiti wrote:
>> Hi,
>>
>> Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the
>> libgpiod package that we ship is still based on the latest version
>> 1.6.3 which does not implement the API v2. So I'd like to update
>> libgpiod, do you have any recommendations about what branch/sha1 I
>> should use? Do you plan to make a release that implements the API v2?
>>
> 
> Firstly, libgpiod is Bart's library so he is the authority, but this
> is my understanding...
> 
> TLDR: You should keep GPIO_CDEV_V1 enabled.
> 
> v1 is deprecated from a development perspective, so all new feature
> development will occur on v2, and new applications should target v2.
> Existing apps targetting v1, be that directly or via libgpiod v1.6.3,
> will require GPIO_CDEV_V1 until they migrate to v2.
> The mainline kernel will continue to support v1 while userspace
> transitions.
> 
> libgpiod v2 is in active development, and should reach its first release
> shortly.
> Note that it is NOT a plugin replacement for v1. It has a different API,
> for similar reasons to why we had to switch in the kernel, so apps will
> need to be actively migrated.
> 
> I wouldn't suggest making any effort to package libgpiod v2 until Bart
> makes an official release.
> 
> Cheers,
> Kent.
> 

libgpiod v2 is out now at least upstream, even if it is not yet packaged in most distributions. But this brings newly identified loss of functionality that seems to be impossible to resolve so far.

With the v1 API, it was possible to do fine-grained access and mediation control via LSM. Specifically privileged process would export pins, and then use LSM controls to allow rw access to individual pin path in sysfs to otherwise unpriviledged or confined applications. This is used a lot on Ubuntu Core with snapd and apparmor, to mediate confined applications (such that only one application at time has access to a particular pin, and to ensure they only have access to pins they need).

It doesn't seem to be possible to do such mediation with v2 api, as I don't see any LSM hooks inside the gpiochip ioctl implementation, and the character device is for the full chip, not individual pins. Similarly, mediating ioctl calls requires a lot of gpio ioctl specific knowledge (i.e. introspecting gpio_v2_line_values masks and what not).

Thus right now, I cannot migrate to v2 api, as I would loose confinement capabilities. And there is external pressure to stop using "DEPRECATED" config option in the kernel that "will be removed after 2020" as per comments and Linux documentation.

What is the LSM plan for v2 API, if any?

Ideally, it would be nice to have lsm hook to check/filter operations on allowed pin numbers.

Or for example, can we add ability to create filtered char device that self-limits itself to particular lines only, within a particular chip? As then the usual LSM could mitigate access to that, without specific gpio ioctl knowledge / introspection. (e.g. /dev/gpio/my-gpio-pins that only allows access to gpiochip0 lines 0..100)

Regards,

Dimitri.