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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a09twTx-UFGw9u_b0CtJJGbwbyO3Z_aL+Tr3iHrvgv_kA@mail.gmail.com>
Date:   Fri, 28 Jan 2022 10:47:33 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Sami Kyostila <skyostil@...omium.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Torokhov <dtor@...omium.org>, evanbenn@...omium.org,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 2/2] drivers/misc: add transfer ioctl for HPS

On Fri, Jan 28, 2022 at 8:42 AM Sami Kyostila <skyostil@...omium.org> wrote:
> to 27. tammik. 2022 klo 20.41 Greg KH (gregkh@...uxfoundation.org) 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