Announcement

Collapse
No announcement yet.

Linux's Qualcomm Ath10k Driver Getting WoWLAN, WCN3990 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Uqbar
    replied
    Originally posted by brad0 View Post

    You still sound like an idiot.
    Thanks for your great contribution to the discussion.
    Let's say you need to let every day an unknown person in your house because otherwise your fridge wouldn't work.
    She's not just sitting near your fridge. She sometimes walks around, touches stuff, peeks at people and stuff.
    You are not allowed to know what she's doing all the time. You only know that otherwise your fridge won't work.
    That person isn't always the same. Sometimes an apparently new person replaces the previous one.
    Sometimes you see weird things all around and weird behaviors of your pets and appliances.
    Sometimes apples smell like bananas and the cheese like strawberries.
    But you have no evidence it's been caused by that person.
    You just recall that those weird things never happened before you got that fridge (and unknown person).
    Are you OK with that? Are you easy?

    I am not and I sound like an idiot.

    What about yourself?

    Leave a comment:


  • Falcon1
    replied
    Originally posted by brad0 View Post

    You still sound like an idiot.
    Not to me. The problem with loadable firmware is that a alternative firmware can be loaded maliciously. While preserving functionality it might infect your OS and keep infecting while you reinstall again and ad again. As it's independently of your system and OS it can just give access to your system remotely on it's own or share your information with others. No virus scanner will detect.

    Now you can say: let vendors publish a list of checksum's on valid firmware's so you can check. But if the company has been infiltrated the firmware might just be malicious and publish as OK. Or just has exploitable bugs and you will not be able to check nor anyone else.

    Also product vendors are more concerned about functionality and speed not on your safety. It simply doesn't sell product if they are safe but slow en less in functionality than your competitors.

    Vendors are however reluctant to share the code for numbers of reasons.
    1. The code might not be theirs or not completely, copyright, licencing, etc.
    2. The code might reveal information on the hardware usefull to their competitors
    3. The code might come form altered open source (GPL) code, which is an infringement
    So the cheap solution is just to deliver blob's and pretend everything smells like roses

    "Just because you're paranoid doesn't mean they aren't after you"

    Leave a comment:


  • brad0
    replied
    Originally posted by Uqbar View Post
    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.
    You still sound like an idiot.

    Leave a comment:


  • Uqbar
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Uqbar View Post
    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.

    Leave a comment:


  • Uqbar
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by cynical View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Uqbar View Post
    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).

    Leave a comment:


  • Wilfred
    replied
    Originally posted by Uqbar View Post
    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.

    Leave a comment:


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

    Leave a comment:

Working...
X