netdev - Re: [PATCH net-next v2 2/2] usb: class: cdc-wdm: WWAN framework integration

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] [day] [month] [year] [list]

Message-ID: <CAAP7ucJah5qJXpjyP9gYmnYDyBWS7Qe3ck2SCBonJhJB2NgS5A@mail.gmail.com>
Date:   Wed, 12 May 2021 09:30:43 +0200
From:   Aleksander Morgado <aleksander@...ksander.es>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     Oliver Neukum <oliver@...kum.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Bjørn Mork <bjorn@...k.no>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 2/2] usb: class: cdc-wdm: WWAN framework integration

Hey Loic,

On Tue, May 11, 2021 at 4:33 PM Loic Poulain <loic.poulain@...aro.org> wrote:
>
> The WWAN framework provides a unified way to handle WWAN/modems and its
> control port(s). It has initially been introduced to support MHI/PCI
> modems, offering the same control protocols as the USB variants such as
> MBIM, QMI, AT... The WWAN framework exposes these control protocols as
> character devices, similarly to cdc-wdm, but in a bus agnostic fashion.
>
> This change adds registration of the USB modem cdc-wdm control endpoints
> to the WWAN framework as standard control ports (wwanXpY...).
>
> Exposing cdc-wdm through WWAN framework normally maintains backward
> compatibility, e.g:
>     $ qmicli --device-open-qmi -d /dev/wwan0p1QMI --dms-get-ids
> instead of
>     $ qmicli --device-open-qmi -d /dev/cdc-wdm0 --dms-get-ids
>

I have some questions regarding how all this would be seen from userspace.

Does the MBIM control port retain the ability to query the maximum
message size with an ioctl like IOCTL_WDM_MAX_COMMAND? Or is that
lost? For the libmbim case this may not be a big deal, as we have a
fallback mechanism to read this value from the USB descriptor itself,
so just wondering.

Is the sysfs hierarchy maintained for this new port type? i.e. if
doing "udevadm info -p /sys/class/wwan/wwan0p1QMI -a", would we still
see the immediate parent device with DRIVERS=="qmi_wwan" and the
correct interface number/class/subclass/protocol attributes?

> However, some tools may rely on cdc-wdm driver/device name for device
> detection. It is then safer to keep the 'legacy' cdc-wdm character
> device to prevent any breakage. This is handled in this change by
> API mutual exclusion, only one access method can be used at a time,
> either cdc-wdm chardev or WWAN API.

How does this mutual exclusion API work? Is the kernel going to expose
2 different chardevs always for the single control port? If so, do we
really want to do that? How would we know from userspace that the 2
chardevs apply to the same port? And, which of the chardevs would be
exposed first (and notified first by udev), the wwan one or the
cdc-wdm one?

-- 
Aleksander
https://aleksander.es