5 ms·

This is an exploit within the wifi driver? So on iOs this would be a kext, and Apple controls all of that, so they can update and resign the kext and issue it i

by cmurf 10y ago

This is an exploit within the wifi driver? So on iOs this would be a kext, and Apple controls all of that, so they can update and resign the kext and issue it in an update. Whereas Google can't do that; it'd be up to the handset manufacturer. Is this an example of the problem Google faces using the Linux kernel in Android? It cedes the kernel to the manufacturer, and wifi (and bluetooth etc) drivers are all kernel space, not user space. So Google can't really do anything here can they?

izacus 10y ago
They can and they did - they pushed the update to Nexus and Pixel devices.
- emodendroket 10y ago
  I know this is a well-rehearsed complaint at this point but having OEMs customizing Android to the point where it can't be updated was a real mistake.
  - TeMPOraL 10y ago
    It was also probably necessary to have Android end up at its current position. Worse is Better strikes again.
  - StavrosK 10y ago
    I don't think customization is the whole problem. Sounds like different hardware is (most of) the problem, as it needs drivers.
    - emodendroket 10y ago
      I mean, Windows has way more drivers than Android and yet somehow I don't have to wait two years for hardware vendors to come up with special versions of Windows updates. Is that really an insurmountable problem?
      - user5994461 10y ago
        To their credit, Microsoft is massively invested in driver support, retro compatibility and patches. They have a massive support ecosystem for and around hardware vendors. Google has nothing close. Even if they tried, it could take a decade to get there.
      - vetinari 10y ago
        Windows Phone doesn't run on a fraction of SoCs that Android does. You are basically limited to a Snapdragon and that's it. There is no such rich ecosystem like in Android, ranging from MediaTek to Nvidia.
        huxley 10y ago
        Parent was referring to Windows on desktops and laptops
        vetinari 10y ago
        If he meant PC-compatibles, that's even worse. Desktops and laptops have something common: BIOS or UEFI, which standardize both boot process and plaform services, and enumerable buses like PCI. Nothing of this sort is available for ARM/Sparc/whatever boards. It's like criticizing Windows, that it doesn't run on Chromebooks or PPC Macs.
        emodendroket 10y ago
        I'm not a systems programmer, much less a hardware designer, but it seems to me like if it has been done once it can be done again.
        vetinari 10y ago
        The issue is not whether it is possible or not. Of course, it is possible. The issue is whether it will result in better product, where better is defined as "will it sell more?". Your average cellphone buyer does not care about that. But he cares about thinness and battery life, which would be affected by a more universal platform. Imagine a 3D chart, where one axis is battery life and small-sized hardware, second is versatility, third showing the sales, with a curve going through, showing a compromise between two trade-offs and total sales for that compromise. We are currently in one point, with few people arguing to change the position to another point, completely ignoring these two other axes.
- cmurf 10y ago
  What I wrote: "Whereas Google can't do that; it'd be up to the handset manufacturer." Your first statement isn't congruent with your second statement. That they push it to their devices alone does not mean they "can and did" apply the update to all Android devices. My whole post is that they can't push kernel drivers to handsets that aren't theirs.
- stevenhubertron 10y ago
  > They can and they did - they pushed the update to Nexus and Pixel devices. fwiw: my Nexus does not see the update yet.
duskwuff 10y ago
> This is an exploit within the wifi driver? No. This exploit runs against the firmware of the wireless chipset itself. (That's what's so weird and interesting about it.) That being said -- the wireless chipset firmware is loaded by the application processor, so it still requires an OS update to fix.
- cmurf 10y ago
  OK I'm not familiar with this form of firmware loading. What I see on Linux laptops with proprietary firmware blobs being needed by Broadcom wifi hardware, that firmware lives in /usr/lib/firmware/ and it's up to the kernel driver to load the most recent firmware. I guess this must work differently on Android handsets with Broadcom wifi, if it's not possible to just push a new firmware bin file into /usr/lib/firmware? Presumably Google could do that, although I'm not sure what the code signing requirments are for firmware blobs such as this.
  - scintill76 10y ago
    In the case of some Android devices I've looked at, what you described is how they work too. The problem is that the firmware path is on a partition that's normally not writable except by signed updates. I think they'd have to be signed by e.g., Samsung, rather than Google or Broadcom, but Google probably has a key on the approved list in some devices. Savvy users with root can probably patch it themselves, if they can find the correct fixed firmware binary and know where it's stored on their device.

by cmurf 10y ago

izacus 10y ago

They can and they did - they pushed the update to Nexus and Pixel devices.

emodendroket 10y ago
I know this is a well-rehearsed complaint at this point but having OEMs customizing Android to the point where it can't be updated was a real mistake.
- TeMPOraL 10y ago
  It was also probably necessary to have Android end up at its current position. Worse is Better strikes again.
- StavrosK 10y ago
  I don't think customization is the whole problem. Sounds like different hardware is (most of) the problem, as it needs drivers.
  - emodendroket 10y ago
    I mean, Windows has way more drivers than Android and yet somehow I don't have to wait two years for hardware vendors to come up with special versions of Windows updates. Is that really an insurmountable problem?
    - user5994461 10y ago
      To their credit, Microsoft is massively invested in driver support, retro compatibility and patches. They have a massive support ecosystem for and around hardware vendors. Google has nothing close. Even if they tried, it could take a decade to get there.
    - vetinari 10y ago
      Windows Phone doesn't run on a fraction of SoCs that Android does. You are basically limited to a Snapdragon and that's it. There is no such rich ecosystem like in Android, ranging from MediaTek to Nvidia.
      - huxley 10y ago
        Parent was referring to Windows on desktops and laptops
        vetinari 10y ago
        If he meant PC-compatibles, that's even worse. Desktops and laptops have something common: BIOS or UEFI, which standardize both boot process and plaform services, and enumerable buses like PCI. Nothing of this sort is available for ARM/Sparc/whatever boards. It's like criticizing Windows, that it doesn't run on Chromebooks or PPC Macs.
        emodendroket 10y ago
        I'm not a systems programmer, much less a hardware designer, but it seems to me like if it has been done once it can be done again.
        vetinari 10y ago
        The issue is not whether it is possible or not. Of course, it is possible. The issue is whether it will result in better product, where better is defined as "will it sell more?". Your average cellphone buyer does not care about that. But he cares about thinness and battery life, which would be affected by a more universal platform. Imagine a 3D chart, where one axis is battery life and small-sized hardware, second is versatility, third showing the sales, with a curve going through, showing a compromise between two trade-offs and total sales for that compromise. We are currently in one point, with few people arguing to change the position to another point, completely ignoring these two other axes.
cmurf 10y ago
What I wrote: "Whereas Google can't do that; it'd be up to the handset manufacturer." Your first statement isn't congruent with your second statement. That they push it to their devices alone does not mean they "can and did" apply the update to all Android devices. My whole post is that they can't push kernel drivers to handsets that aren't theirs.
stevenhubertron 10y ago
> They can and they did - they pushed the update to Nexus and Pixel devices. fwiw: my Nexus does not see the update yet.

duskwuff 10y ago

> This is an exploit within the wifi driver? No. This exploit runs against the firmware of the wireless chipset itself. (That's what's so weird and interesting about it.) That being said -- the wireless chipset firmware is loaded by the application processor, so it still requires an OS update to fix.

cmurf 10y ago
OK I'm not familiar with this form of firmware loading. What I see on Linux laptops with proprietary firmware blobs being needed by Broadcom wifi hardware, that firmware lives in /usr/lib/firmware/ and it's up to the kernel driver to load the most recent firmware. I guess this must work differently on Android handsets with Broadcom wifi, if it's not possible to just push a new firmware bin file into /usr/lib/firmware? Presumably Google could do that, although I'm not sure what the code signing requirments are for firmware blobs such as this.
- scintill76 10y ago
  In the case of some Android devices I've looked at, what you described is how they work too. The problem is that the firmware path is on a partition that's normally not writable except by signed updates. I think they'd have to be signed by e.g., Samsung, rather than Google or Broadcom, but Google probably has a key on the approved list in some devices. Savvy users with root can probably patch it themselves, if they can find the correct fixed firmware binary and know where it's stored on their device.