Hi Geert! Thanks for this very interesting patch! On Fri, Jul 5, 2019 at 6:05 PM Geert Uytterhoeven <geert+renesas@xxxxxxxxx> wrote: > GPIO controllers are exported to userspace using /dev/gpiochip* > character devices. Access control to these devices is provided by > standard UNIX file system permissions, on an all-or-nothing basis: > either a GPIO controller is accessible for a user, or it is not. > Currently no mechanism exists to control access to individual GPIOs. Yes, I did that decision deliberately, as the chip is one device and the base system control is usually on a per-device granularity. At one point some people were asking for individual GPIO line permissions in the character device and my argument was something like why can't I have individual control over the access rights on a block device or the pixels on a graphics device then. Jokes aside, filesystems do provide access control over individual blocks on a block device in a way. So it is further up the stack. The same goes for this: something above the GPIO chip provide more granular access control, and as such it fits the need very well. > Hence add a virtual GPIO driver to aggregate existing GPIOs (up to 32), > and expose them as a new gpiochip. This is useful for implementing > access control, and assigning a set of GPIOs to a specific user. > Furthermore, it would simplify and harden exporting GPIOs to a virtual > machine, as the VM can just grab the full virtual GPIO controller, and > no longer needs to care about which GPIOs to grab and which not, > reducing the attack surface. Excellent approach. I would even go so far as to call it "gpio-virtualization" or "gpio-virtualized" rather than "gpio-virtual" so it is clear what the intended usecase is. We have a bit of confusion in the kernel because people misuse the word "virtual" left and right, like for "virtual IRQ number" (Linux IRQ numbers) which are just some random number space, but not really "virtual", it's a semantic disease similar to the confusion of using the word "manual" in computer code. Here it is however used correctly! (Maybe for the first time.) > Virtual GPIO controllers are instantiated by writing to the "new_device" > attribute file in sysfs: > > $ echo "<gpiochipA> <gpioA1> [<gpioA2> ...]" > "[, <gpiochipB> <gpioB1> [<gpioB2> ...]] ...]" > > /sys/bus/platform/drivers/gpio-virt-agg/new_device > > Likewise, virtual GPIO controllers can be destroyed after use: > > $ echo gpio-virt-agg.<N> \ > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device I suppose this is the right way to use sysfs. I would check with some virtualization people (paged Marc Zyngier and Christoffer Dall) so they can say whether this is the way any virtual machine wants to populate its local GPIO chip for use with a certain machine. If QEMU can deal in a simple and straight-forward way with this I see it quickly becoming a very useful tool for industrial automation where you want to run each control system in isolation and just respawn the virtual machine if something goes wrong. Since this might be very popular we need some scrutiny but the concept as a whole is very appetizing! Yours, Linus Walleij
