netdev - Re: gsmtap design/extensions?

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:   Mon, 15 Apr 2019 12:29:09 +0200
From:   Bjørn Mork <bjorn@...k.no>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Vadim Yanitskiy <axilirator@...il.com>,
        Harald Welte <laforge@...monks.org>,
        OpenBSC Mailing List <openbsc@...ts.osmocom.org>,
        Sean Tranchetti <stranche@...eaurora.org>, radiotap@...bsd.org,
        Dan Williams <dcbw@...hat.com>,
        netdev <netdev@...r.kernel.org>,
        "open list\:NFC SUBSYSTEM" <linux-wireless@...r.kernel.org>,
        Aleksander Morgado <aleksander@...ksander.es>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Subject: Re: gsmtap design/extensions?

Johannes Berg <johannes@...solutions.net> writes:

>> As I said, as long as you do not get the QMI, AT command, MBIM etc.
>> control path session recorded as well, you have nothing to really
>> analyze.
>
> But you do - afaict there are no ways other than the netdevs to
> communicate with the device,

I don't understand where you are going here? Neither QMI, AT command nor
MBIM management are transported over netdevs. AT is usually transported
using simple USB bulk streams, exported to userspace as tty devices by
some USB serial driver.  Both QMI and MBIM management are transported as
USB control messages, and exported to userspace as chardevs.  There are
no netdevs involved.

> and people do things like "socat" to set up
> PTYs and pretend to have serial channels there, on top of the netdevs?

I assume you are referring to my MBIM DSS examples here.  I don't know
if anyone is actually using that, so you should probably ignore it...
I'll happily admit it was a bad idea.  Should have just added the
necessary code to map DSS channels to some sort of character device in
the driver, like most users requested.

But there really isn't anything in the MBIM spec saying how DSS should
be used. DSS is a generic data stream.  Could easily be connected to a
single TCP session for example, in which case you'd probably want to
connect it to a TCP session in the other end too.  So I wouldn't want to
force DSS into character devices on the host end.  This doesn't rule out
a userspace controlled optional mapping though. We could probably still
add that, replacing the VLAN mapping with a chardev for a specific DSS
session if requested by userspace.  I guess this is something to
consider for a generic cellular framework - supporting non-ip data
streams between modem and host.

Adding to my previous excuses: The DSS implementation in the cdc_mbim
driver was added without having seen a single modem firmware with *any*
type of DSS support.  It was purely based on spec{ification,culation}.
The VLAN mapping, along with examples of how to use socat to further map
the streams from VLANs into suitable application specific forms, seemed
like a simple and flexible enough solution.

Bjørn