[LEDE-DEV] Open and secure firmware for Quectel 4G modems [Was: Re: Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]]
laforge at gnumonks.org
Mon Jan 9 01:04:51 PST 2017
On Sun, Jan 08, 2017 at 08:26:23PM +0100, Petr Štetiar wrote:
> Indeed, it's very interesting and very scary. This modems are quite powerful
> devices, usually equiped with very good, but limited uplink connection, still
> making it ideal candidate for DDoS botnet for example, like any other router,
I agree. In days of LTE and LTE-A, the connectivity of cellular modems
is sometimes better than that of DSL-modems/routers ;)
> It's just a matter of time we see something like this in the wild.
> The probability is very high, 1.5M lines of just kernel code done
> probably in a hurry, without proper review, this is very big attack surface.
The kernel code is the same (or close to?) what is in all the Qualcomm
based Android devices. That could mean a lot of things, among them that
Google Project Zero guys or other people doing android security might
find issues. But i could also mean that the attack surfaces is much
larger than those modems ;)
> Guys at Osmocom already started working on completely open and more secure
> firmware using OpenEmbedded, but I would like to see it supported in LEDE
> also, probably with more mainline kernel if possible.
Our goal at this point is not to modify / strip down the kernel. The
primary goals at this point are:
a) more work on osmo-cqdiag and my wiershark DIAG protocol decoder
b) establish libqmi-glib interoperability with qmuxd
c) gradually replace existing proprietary userspace programs
d) build custom images + package feeds from OE/poky.
e) understand + document more parts of the Qualcomm Android Kernel
> Still, it's quite strange to see such a big embedded systems running
> in the 4G modem. It seems like 2017 is era of SITSes, Systems In The
I wanted to state this in my talk, but forgot: If software complexity
continues ti increase in cellular modems like we have seen it increase
in the 2006-2016 timeframe, then in ten years we will have
virtualization with orchestration managers in them.
I think the main problem is that 32bit CPU cores with MMU and memory is
getting so small and cheap cheap, that people just put full-blown Linux
systems everywhere. Whether it makes sense, and how to maintain that in
the long term is apparently no concern.
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the Lede-dev