linux-kernel - Re: [PATCH 0/6] In-kernel QMI handling

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:   Tue, 8 Aug 2017 13:13:22 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        "David S. Miller" <davem@...emloft.net>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        Netdev list <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] In-kernel QMI handling

Hi Bjorn,

>> This series starts by moving the common definitions of the QMUX protocol to the
>> uapi header, as they are shared with clients - both in kernel and userspace.
>> 
>> This series then introduces in-kernel helper functions for aiding the handling
>> of QMI encoded messages in the kernel. QMI encoding is a wire-format used in
>> exchanging messages between the majority of QRTR clients and services.
> 
> Interesting!  I tried to add some QMI handling in the kernel a few years
> ago, but was thankfully voted down.  See
> https://www.spinics.net/lists/netdev/msg183101.html and the following
> discussion. I am convinced that was the right decision, for the client
> side at least. The protocol is just too extensive and ever-growing to be
> implemented in the kernel. We would be catching up forever.

I think that even back then I said, that it has to be done as a proper subsystem if it has a chance to be in the kernel. So something similar to Phonet and CAIF where the service registration is handled by the kernel, but applications can be fully in userspace. None of this is actually brand new Qualcomm design since Nokia has had its Phonet long before QMI existed.

The real importance is that Qualcomm is behind this and wants to get this done a clean way with a proper API. The /dev/qmi thing was a pretty broken interface. Any subsystem has to support multiple QMI devices. Even if this is unlikely in a phone design, it has to be supported so that attaching two USB QMI based dongles does not end up with some pointless errors.

Regards

Marcel