Linux's Qualcomm Ath10k Driver Getting WoWLAN, WCN3990 Support

[phoronix]

Phoronix: Linux's Qualcomm Ath10k Driver Getting WoWLAN, WCN3990 Support

The Qualcomm/Atheros "Ath10k" Linux driver coming up in the Linux 4.20~5.0 kernel merge window is picking up two prominent features...

http://www.phoronix.com/scan.php?page=news_item&px=Ath10k-WoWLAN-Plus-WCN3990

[Space Heater]

Kalle has also recently posted firmware updates for ath10k.

https://www.spinics.net/lists/linux-wireless/msg178842.html

[Uqbar]

Will this "new" driver hide another closed-source binary inside?
If so then ... no, thanks.
(spoiler: yes, there's a brand new ath10k-20181010 blob in the firmware git).
While new fantastic hardware with gazillions of new features and super boosted performance is always desirable (really? really really?),
a tainted kernel is as desirable as a kick in the mouth or as a(n unwanted) system backdoor or a security hole.
My favorite distro already has a 290+MB "linux-firmware" package installed (then you also have alsa-firmware, bluez-firmware and sane-firmware).
A list can be seen here (beware: git ahead!).
Yes, I am not using all those blobs at once. Just one or two. But why?
Because the hardware support under Linux has lacked behind for years. So a BLOB has been considered better than nothing.
But what about the so-called "now"?
I wouldn't say that Linux relevance in the market is minimal or even marginal.
And with home routers and smartphones running Linux, the relevance is rather high. Isn't it?

I would like the Linux dev-board and the Linux whatever-committee to vote for a "please, publish that f*c*i*g source code or we won't support your hardware by license" motion.

Then I wake up from my dreams and go on loading my blobs.

[cynical]

Are there any 802.11AC devices that don’t require blobs?

[Wilfred]

Will this "new" driver hide another closed-source binary inside?
If so then ... no, thanks.
(spoiler: yes, there's a brand new ath10k-20181010 blob in the firmware git).
While new fantastic hardware with gazillions of new features and super boosted performance is always desirable (really? really really?),
a tainted kernel is as desirable as a kick in the mouth or as a(n unwanted) system backdoor or a security hole.
My favorite distro already has a 290+MB "linux-firmware" package installed (then you also have alsa-firmware, bluez-firmware and sane-firmware).
A list can be seen here (beware: git ahead!).
Yes, I am not using all those blobs at once. Just one or two. But why?
Because the hardware support under Linux has lacked behind for years. So a BLOB has been considered better than nothing.
But what about the so-called "now"?
I wouldn't say that Linux relevance in the market is minimal or even marginal.
And with home routers and smartphones running Linux, the relevance is rather high. Isn't it?

I would like the Linux dev-board and the Linux whatever-committee to vote for a "please, publish that f*c*i*g source code or we won't support your hardware by license" motion.

Then I wake up from my dreams and go on loading my blobs.

Fuck yeah. Dumping blobs does not count as support imho. I like my ath9k with open firmware and wifi fairness queuing.

[starshipeleven]

Will this "new" driver hide another closed-source binary inside?

You are confusing blob drivers with firmware. Firmware does not taint the kernel, and is not "inside" a driver. Drivers run with the Kernel, in RAM and on the CPU.

Firmware is run inside the peripheral's own controller/processors, regardless of the OS or driver. The only interaction with the Linux kernel is sending the blob to the peripheral.

That's why a blob driver taints the kernel, and a firmware does not.


Now the blob is loaded at runtime, while before it was often stored in a ROM in the peripheral itself.
Loadable blobs are a significant improvement over ROMs as they still give the user as much control as possible, as you can decide what version of the blob to load (which allows you to sidestep any attempt to remove features in more recent firmwares or allows some working around firmware bugs by refusing update until they release a stable firmware), or IF you want to load the blob at all (which effectively disables the peripheral).

[starshipeleven]

Are there any 802.11AC devices that don’t require blobs?

No, every ac device needs a firmware to work. https://en.wikipedia.org/wiki/Compar...reless_drivers

Do note that a lot of wifi n devices rely on firmware flashed on a ROM in the device itself (see link above) anyway.

[Uqbar]

You are confusing blob drivers with firmware. Firmware does not taint the kernel, and is not "inside" a driver. Drivers run with the Kernel, in RAM and on the CPU.

Firmware is run inside the peripheral's own controller/processors, regardless of the OS or driver. The only interaction with the Linux kernel is sending the blob to the peripheral.

That's why a blob driver taints the kernel, and a firmware does not.


Now the blob is loaded at runtime, while before it was often stored in a ROM in the peripheral itself.
Loadable blobs are a significant improvement over ROMs as they still give the user as much control as possible, as you can decide what version of the blob to load (which allows you to sidestep any attempt to remove features in more recent firmwares or allows some working around firmware bugs by refusing update until they release a stable firmware), or IF you want to load the blob at all (which effectively disables the peripheral).

In order to make hardware device work some software part is needed.
I don't like it whenever that part is closed source.
No matter whether that's run inside the device, on the host cpu or any other hardware part,
at it cannot be peer reviewed, nor modified.

Thanks for clarifying, though.

[starshipeleven]

In order to make hardware device work some software part is needed.
I don't like it whenever that part is closed source.

Eh, you're not wrong, but I'm just not really seeing a future where even low-level firmware for devices is opensource (and there are enough hardware manuals to actually make sense of it).

No matter whether that's run inside the device, on the host cpu or any other hardware part,
at it cannot be peer reviewed, nor modified.

The reason why it is seen as less important is that a peripheral is (or can be made) untrusted, so it won't have access to 100% the system like a driver has in Linux.

A driver in Linux can do whatever it wants, while a peripheral still has to follow the limitations of the communication protocol it is using, and there are measures to sandbox them, like with IOMMU/VT-d.

[Uqbar]

I understand your points. Especially the one about the differences between a driver and a firmware blob.
Nonetheless, I don't like it anyway.
Because there's no reason (for me at least) to keep that code opaque and hidden.
Especially if there's a way to reverse compile or to disassemble it.

Then we could discuss what can be done and cannot with a device running undisclosed software.
For example, a network adapter (wired or wireless) can do a lot of things, as the latest news seem to show.