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: <CAAP7uc+cEeD=G4H-2+Jbt3j15tuak6PruVnAbJhhbeUsizwhYA@mail.gmail.com>
Date:   Thu, 11 Feb 2021 10:26:40 +0100
From:   Aleksander Morgado <aleksander@...ksander.es>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        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

> What bothers me is maintaining shim drivers which just shuttle opaque
> messages between user space and firmware. One of which definitely is,
> and the other may well be, proprietary. This is an open source project,
> users are supposed to be able to meaningfully change the behavior of
> the system.

libqmi is an open source library under the LGPL; so all the messages
that are passed between e.g. ModemManager and the modem firmware can
be easily inspected by anyone. It is true, though, that libqmi may
also allow passing "unknown" messages between other proprietary third
party applications and the firmware, but that is very much like any
other modem control port that we already have; be it a plain tty, or a
ttyUSB or a ttyACM or a cdc-wdm port. The kernel drivers are passing
unknown stuff between modem firmware and userspace; I don't see how
the kernel driver would be interested in any other thing really. QMI
and MBIM are just 2 binary protocols (and we have libqmi and libmbim),
and there's a generic 3GPP AT command set, but every vendor then has
its own interpretation of that AT command set, and vendor-specific AT
commands, and what not. From my point of view, it's not like the
kernel should know or have much to say on what's being passed to the
modem.

>
> What bothers me is that we have 3 WWAN vendors all doing their own
> thing and no common Linux API for WWAN. It may have been fine 10 years
> ago, but WWAN is increasingly complex and important.
>

A WWAN modem is nowadays a complete Linux system itself with tons of
features, and if there is sometime a generic WWAN system in the kernel
providing API/ABI for generic features (e.g. data connection), that
API/ABI should anyway provide access to pass messages (be it binary,
or text AT commands) between firmware and userspace, for all the other
side features for which no generic API/ABI is provided by that
hypothetical generic WWAN system. Unless we don't want any of those
side features... like Voice call management, SMS, USSD, GNSS, SAR,
OMA-DM, carrier config selection, multi-SIM setups...

-- 
Aleksander