libgpiod API v2 release

libgpiod API v2 release

[Alexandre Ghiti]

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?

Thanks,

Alex

Re: libgpiod API v2 release

[Kent Gibson]

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.

Re: libgpiod API v2 release

[Dimitri John Ledkov]

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.

Re: libgpiod API v2 release

[Kent Gibson]

On Wed, Mar 29, 2023 at 12:03:31PM +0100, Dimitri John Ledkov wrote:
> 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.
> 

You are confusing uAPI v1 with the long deprecated sysfs API.
uAPI v2 is a functional superset of v1 - anything that can be done with
v1 can also be done with v2, and the ioctl approach is the same.

But replacing "v1 API" with "sysfs API" and the following makes more
sense...

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

Here we go again.  sysfs has been deprecated since 2015, and yet you are
only now looking to migrate away from it.
Please specify exactly how much notice you require not to feel "pressured".

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

Use the GPIO aggregator[1] to create a chip confined to the pins of interest?
Then you can use LSM, or whatever, to control access to the chip?

Cheers,
Kent.

[1] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html

Re: libgpiod API v2 release

[Dimitri John Ledkov]

Hi,

On Wed, 29 Mar 2023 at 12:36, Kent Gibson <warthog618@gmail.com> wrote:
>
> On Wed, Mar 29, 2023 at 12:03:31PM +0100, Dimitri John Ledkov wrote:
> > 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.
> >
>
> You are confusing uAPI v1 with the long deprecated sysfs API.
> uAPI v2 is a functional superset of v1 - anything that can be done with
> v1 can also be done with v2, and the ioctl approach is the same.
>
> But replacing "v1 API" with "sysfs API" and the following makes more
> sense...

Yes I am, apologies.

>
> > 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?
> >
>
> Here we go again.  sysfs has been deprecated since 2015, and yet you are
> only now looking to migrate away from it.
> Please specify exactly how much notice you require not to feel "pressured".

I guess lack of knowledge about gpio-aggregator was the missing piece,
rather than any particular timelines.

>
> > 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)
> >
>
> Use the GPIO aggregator[1] to create a chip confined to the pins of interest?
> Then you can use LSM, or whatever, to control access to the chip?
>

This looks exactly what Ubuntu Core / snapd wants, thus I will
investigate implementing that.

> Cheers,
> Kent.
>
> [1] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html
>


-- 
okurrr,

Dimitri