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]

Message-ID: <YBrsmO/ATztB+1K4@builder.lan>
Date:   Wed, 3 Feb 2021 12:34:00 -0600
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>, davem@...emloft.net,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        jhugo@...eaurora.org, bbhatt@...eaurora.org,
        loic.poulain@...aro.org, netdev@...r.kernel.org
Subject: Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver

On Wed 03 Feb 12:05 CST 2021, Jakub Kicinski 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.

But said QMI driver would be identical to what is proposed here, given
that the libqmi [1] communicates in the raw messages of the given MHI
channel. Should I then propose another copy of the same driver for
transporting debug messages between [2] and the modem? And a third copy
to support firmware flashing using [3].

[1] https://www.freedesktop.org/wiki/Software/libqmi/
[2] https://github.com/andersson/diag
[3] https://github.com/andersson/qdl

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

PCI devices implementing this must have a MHI controller driver, which
explicitly needs to specify which logical channels should be exposed to
userspace using the UCI driver. So in contrast to things like USBFS or
the tty layer - which is used to implement "network devices" today -
there is a natural point of policing this.

Regards,
Bjorn