netdev - cellular modem driver APIs

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

Date:   Wed, 03 Apr 2019 23:15:52 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     netdev@...r.kernel.org
Cc:     Dan Williams <dcbw@...hat.com>,
        Bjørn Mork <bjorn@...k.no>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
        Sean Tranchetti <stranche@...eaurora.org>
Subject: cellular modem driver APIs

Hi all,

I've been looking at modem drivers, to see what the APIs are to interact
with them, and while I originally thought I had the story sorted out ...
not at all.

Here's the current things we seem to be doing:

  (1) Channels are created/encoded as VLANs (cdc_mbim)

      This is ... strange at best, it requires creating fake ethernet
      headers on the frames, just to be able to have a VLAN tag. If you
      could rely on VLAN acceleration it wouldn't be _so_ bad, but of
      course you can't, so you have to detect an in-band VLAN tag and
      decode/remove it, before taking the VLAN ID into the virtual
      channel number.

      Creating channels is hooked on VLAN operations, which is about the
      only thing that makes sense here?

  (2) Channels are created using sysfs (qmi_wwan)

      This feels almost worse - channels are created using sysfs and
      just *bam* new netdev shows up, no networking APIs are used to
      create them at all, and I suppose you can't even query the channel
      ID for each netdev if you rename them or so. Actually, maybe you
      can in sysfs, not sure I understand the code fully.

  (3) Channels are created using a new link type (rmnet)

      To me this sort of feels the most natural, but this particular
      implementation has at least two issues:

      (a) The implementation is basically driver-specific now, the link
          type is called 'rmnet' etc.
      (b) The bridge enslave thing there is awful.

It seems to me that there really is space here for some common
framework, probably modelled on rmnet - that seems the most reasonable
approach of all three.

The only question I have there is whether the 'netdev model' they all
have actually makes sense. What I mean by that is that they all assume
they have a default channel (using untagged frames, initial netdev,
initial netdev respectively for (1) - (3)).

In 802.11, we don't have such a default channel - you can add/remove
virtual netdevs on the fly. But if you want to do that, then you can't
use IFLA_LINK and the normal link type, which means custom netlink and
custom userspace etc. which, while we do it in wifi, is bothersome.

Here I guess the question would be whether it makes sense to even remove
the default channel, or retag it, or something like that. If no, then to
me it all makes sense to just model rmnet. And even if it *is* something
that could theoretically be done, it seems well possible to me that the
benefits (using rtnl_link_register() etc.) outweigh the deficits of the
approach.

I'm tempted to take a stab at breaking out rmnet_link_ops from the rmnet
driver, somehow giving it an alias of 'wwan-channel' or something like
that, and putting it into some sort of small infrastructure.

Anyone else have any thoughts?

Thanks,
johannes