linux-kernel - Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

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]

Date:   Wed, 3 Feb 2021 19:28:28 +0100
From:   Loic Poulain <loic.poulain@...aro.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        David Miller <davem@...emloft.net>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Bhaumik Bhatt <bbhatt@...eaurora.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

Hi Jakub,

On Wed, 3 Feb 2021 at 19:05, Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 03 Feb 2021 09:45:06 +0530 Manivannan Sadhasivam wrote:
> > >> Jakub, Dave, Adding you both to get your reviews on this series. I've
> > >> provided an explanation above and in the previous iteration [1].
> > >
> > >Let's be clear what the review would be for. Yet another QMI chardev
> > >or the "UCI" direct generic user space to firmware pipe?
> >
> > The current patchset only supports QMI channel so I'd request you to
> > review the chardev node created for it. The QMI chardev node created
> > will be unique for the MHI bus and the number of nodes depends on the
> > MHI controllers in the system (typically 1 but not limited).
>
> If you want to add a MHI QMI driver, please write a QMI-only driver.
> This generic "userspace client interface" driver is a no go. Nobody will
> have the time and attention to police what you throw in there later.

Think it should be seen as filtered userspace access to MHI bus
(filtered because not all channels are exposed), again it's not
specific to MHI, any bus in Linux offers that (i2c, spi, usb, serial,
etc...). It will not be specific to QMI, since we will also need it
for MBIM (modem control path), AT commands, and GPS (NMEA frames), all
these protocols are usually handled by userspace tools and not linked
to any internal Linux framework, so it would be better not having a
dedicated chardev for each of them.

Regards,
Loic