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: <20210210062531.GA13668@work>
Date:   Wed, 10 Feb 2021 11:55:31 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Aleksander Morgado <aleksander@...ksander.es>,
        Loic Poulain <loic.poulain@...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

On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote:
> On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote:
> > This may be a stupid suggestion, but would the integration look less a
> > backdoor if it would have been named "mhi_wwan" and it exposed already
> > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just
> > QMI?
> 
> What's DIAG? Who's going to remember that this is a backdoor driver 
> a year from now when Qualcomm sends a one liner patches which just 
> adds a single ID to open another channel?

I really appreciate your feedback on this driver eventhough I'm not
inclined with you calling this driver a "backdoor interface". But can
you please propose a solution on how to make this driver a good one as
per your thoughts?

I really don't know what bothers you even if the userspace tools making
use of these chardevs are available openly (you can do the audit and see
if anything wrong we are doing). And exposing the raw access to the
hardware is not a new thing in kernel. There are several existing
subsystems/drivers does this as pointed out by Bjorn. Moreover we don't
have in-kernel APIs for the functionalities exposed by this driver and
creating one is not feasible as explained by many.

So please let us know the path forward on this series. We are open to
any suggestions but you haven't provided one till now.

Thanks,
Mani