netdev - MBIM backwards compatibility and user vs kernel policy

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]

Message-ID: <87sj43cxg5.fsf@nemi.mork.no>
Date:	Sun, 10 Mar 2013 12:21:14 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Greg Suarez <gsuarez@...thmicro.com>
Cc:	Alexey Orishko <alexey.orishko@...ricsson.com>,
	linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: MBIM backwards compatibility and user vs kernel policy

Hello,

I just realized that our current strategy for MBIM backwards
compatibility results in bad user experience by *forcing* the user to
cdc_mbim if it is enabled at build time. There are legitimate reasons for
a user to select cdc_ncm instead of cdc_mbim at runtime, and at the
moment we prevent that.  The most obvious and important reason is that
the required MBIM userspace applications are not ready yet.  But even in
a future where these are available, I believe we should leave the choice
up to the user.

So our current build time based decision will not do.  But what will?
Is a cdc_ncm module param setting MBIM vs NCM priority OK?  We could
still make the default depend on whether cdc_mbim is built.  I don't
think there are any reasons to complicate this with a per-device
selection.  It is really a system wide setting depending on whether MBIM
is supported by the system.

What do you think?

This problem just came up as a result of a user failing to make Linux
v3.8 work on a Lenovo Thinkpad X230 with an Ericsson H5321gw Mobile
Broadband Device, while v3.7 appeared to work fine.  The H5321gw
firmware support NCM backwards compatibility, making it work fine with
cdc_ncm in v3.7. But in v3.8 we select the cdc_mbim alternate setting
instead, and ModemManager does not yet know how to handle that, making
it fail.

The user noticed the new cdc_mbim module and tried blacklisting it, as
one would find natural. But to no effect, as the problem is in the MBIM
compatibility check in cdc_ncm.  There appears to be no way to force the
cdc_ncm driver in v3.8 to be used for this device if cdc_mbim is
selected at build time. Which of course is a distro choice and not
something most users will touch.

I believe we need to resolve this quickly, and I'll probably just cook up
a proposed module param patch unless someone comes up with something
better.

BTW, I am starting to hate the NCM backward compatibility. There were so
many other ways this could have been solved. Changing class depending on
the selected interface altsetting is ugly, IMHO.

Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html