Re: [PATCH 2/2] drivers/misc: add transfer ioctl for HPS

[Arnd Bergmann]

On Fri, Jan 28, 2022 at 8:42 AM Sami Kyostila <skyostil@xxxxxxxxxxxx> wrote:
> to 27. tammik. 2022 klo 20.41 Greg KH (gregkh@xxxxxxxxxxxxxxxxxxx) kirjoitti:

> >
> > Why can't you just do normal i2c transfers to/from userspace instead of
> > requring a custom ioctl?
>
> The main reason is security: without this driver, in order to talk to
> HPS the userspace daemon needs read/write access to the entire I2C
> controller (e.g., /dev/i2c-0). This means the daemon can also control
> any other I2C device which happens to be on the same bus. With a
> separate ioctl we can limit access to just HPS.
>
> As far as I can tell, there's no way to restrict access on a
> per-device level with normal i2c, but I'd be happy to be proven wrong
> :)

I don't know if is correct, but I trust your research on that. However,
I would still argue that instead of adding a custom low-level interface to
give user access to a single raw i2c device, we would be better off doing
one of two other approaches:

a) add the generic interface you are missing -- it seems unlikely that you
are the only user that has come across this issue, and adding a generic
per-device interface to complement the per-controller one would likely
help avoid others coming up with the same thing elsewhere, using yet
another set of custom ioctls.

b) move part of your application into the kernel, and provide a high-level
abstraction for your device in place of the low-level i2c access.

          Arnd