5 ms·

Mitigations are attack surface, too

104 points by archimag0 7y ago

CiPHPerCoder 7y ago
> On Android, it is normal for vendors to add device-specific code to the kernel. https://i.imgur.com/DnRNrZe.png https://i.imgur.com/DnRNrZe.png Normal for Android : Normal in general :: Madness : Sanity > This code is a frequent source of security vulnerabilities. If the first sentence was the shot, that's the chaser.
- tedunangst 7y ago
  Apertif: But in the Android ecosystem, that doesn't mean that it actually makes its way into device kernels.
- zxcmx 7y ago
  I don't get it; if I'm shipping my own SOC, with my own wizzy latest hardware how else do I get drivers for all my stuff, without adding them myself? Like, I expect the results to have all the expected "quality" of software written by hardware vendors, but I'm not sure what the alternative is? EDIT: oh right, userspace drivers for everything. Leaving the comment here anyway...
- izacus 7y ago
  Your snark is very welcome, but do you have any proposal of how do you add support for a new Qualcomm SoC, GPU and it's camera modules without modifying the kernel? Or for their basebands? Linux still has pretty much no path of adding these in userspace, neither it's interested in a stable ABI. And no, forcing the only big SoC manufacturer in the world to opensource their drivers isn't really going to work.
  - wtallis 7y ago
    If forced to choose between open-sourcing and upstreaming their drivers, or supporting them for 5+ years and forcing their customers to actually deliver those updates to end users, then Qualcomm absolutely would choose the open-source route. QC's taking the path of least resistance, but if we take "ship it and forget it" off the menu of choices, they'll change.
    - izacus 7y ago
      How would that work? Really? I mean, if you ever worked on any hardware, there's not many choices you have. Qualcomm says "no" and there's nothing much you can really do to get the same kind of software. It's also not interesting from financial perspective to do that. Incentives aren't there. This "oh, just force them!" mindset is incredibly naive and hasn't worked for desktop Linux in years. Madness here is trying to do the same thing and expecting different results.
      - rolandog 7y ago
        Well, hasn't Android been doing something similar in the play store by changing how permissions to access storage are given? Or was that just a proposal?
        izacus 7y ago
        > Well, hasn't Android been doing something similar in the play store by changing how permissions to access storage are given? Hmm, can you clarify? Storage changes aren't really driver related?
      - pjmlp 7y ago
        Desktop Linux doesn't have a 500 Pound Gorila behind it. They behave quite differently in what concerns providing drivers for ChromeOS or Windows.
      - danShumway 7y ago
        Google has shown it's willing to force the issue on other parts of Androids -- particularly shipping Google Play with default apps. You can make an argument that's anti-competitive, or against the spirit of Open Source, but regardless, Google is willing to do it. Custom kernels definitely aren't the only reason why the Android update situation is bad, but they're also definitely a nontrivial part of it. A hardline policy that kernel patches had to be pushed upstream if you wanted to brand as Android with Google Play would probably go a long way towards improving that situation for everyone. Qualcomm would either say yes or all of their proprietary chips would become nonviable for the smartphone market. Linux itself can't force that issue because they don't have an attractive brand and suite of basically mandatory proprietary services to take away from smartphone designers who say no. The only thing Linux can do is make life more hellish for people maintaining userland drivers, which companies don't care about because they're not interested in maintaining their stuff to begin with.
  - tasogare 7y ago
    Why Linux doesn't have a driver framework? That's seems the problem here. It exists in Windows, FreeBSD and probably elsewhere too.
    - adrianN 7y ago
      To encourage people to either open source their drivers so that they can be maintained inside the kernel tree, or to pay the cost of updating their stuff themselves so that Linux kernel hackers don't have to pay for backwards compatibility.
      - pjmlp 7y ago
        It does wonders for those stuck with AMD cards on their laptops not supported by the open sourced driver.
        underlines 7y ago
        if i understand the discussion correctly user space drivers could not help, right? and sadly, user space drivers in android are fairly limited. https://developer.android.com/things/sdk/drivers https://developer.android.com/things/sdk/drivers
    - the_why_of_y 7y ago
      http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.kroah.com/log/linux/stable_api_nonsense.html
  - chalst 7y ago
    Eric Raymond argued for mandating suppliers provide source to firmware; this problem is harder, but somewhat similar. http://esr.ibiblio.org/?p=6860 http://esr.ibiblio.org/?p=6860 (from 2015; excuse the grandiose tone, but the idea is interesting) Of course, no chance.
pjmlp 7y ago
The irony of Google security blog giving advice to a problem that the company is responsible for it happening in first place. Had they placed update requirements as part of the Play Store contract, vendors would be more keen in providing the said updates.
- CiPHPerCoder 7y ago
  The irony is real, but I appreciate P0's transparency here.

104 points by archimag0 7y ago

> On Android, it is normal for vendors to add device-specific code to the kernel. https://i.imgur.com/DnRNrZe.png https://i.imgur.com/DnRNrZe.png Normal for Android : Normal in general :: Madness : Sanity > This code is a frequent source of security vulnerabilities. If the first sentence was the shot, that's the chaser.

tedunangst 7y ago
Apertif: But in the Android ecosystem, that doesn't mean that it actually makes its way into device kernels.
zxcmx 7y ago
I don't get it; if I'm shipping my own SOC, with my own wizzy latest hardware how else do I get drivers for all my stuff, without adding them myself? Like, I expect the results to have all the expected "quality" of software written by hardware vendors, but I'm not sure what the alternative is? EDIT: oh right, userspace drivers for everything. Leaving the comment here anyway...
izacus 7y ago
Your snark is very welcome, but do you have any proposal of how do you add support for a new Qualcomm SoC, GPU and it's camera modules without modifying the kernel? Or for their basebands? Linux still has pretty much no path of adding these in userspace, neither it's interested in a stable ABI. And no, forcing the only big SoC manufacturer in the world to opensource their drivers isn't really going to work.
- wtallis 7y ago
  If forced to choose between open-sourcing and upstreaming their drivers, or supporting them for 5+ years and forcing their customers to actually deliver those updates to end users, then Qualcomm absolutely would choose the open-source route. QC's taking the path of least resistance, but if we take "ship it and forget it" off the menu of choices, they'll change.
  - izacus 7y ago
    How would that work? Really? I mean, if you ever worked on any hardware, there's not many choices you have. Qualcomm says "no" and there's nothing much you can really do to get the same kind of software. It's also not interesting from financial perspective to do that. Incentives aren't there. This "oh, just force them!" mindset is incredibly naive and hasn't worked for desktop Linux in years. Madness here is trying to do the same thing and expecting different results.
    - rolandog 7y ago
      Well, hasn't Android been doing something similar in the play store by changing how permissions to access storage are given? Or was that just a proposal?
      - izacus 7y ago
        > Well, hasn't Android been doing something similar in the play store by changing how permissions to access storage are given? Hmm, can you clarify? Storage changes aren't really driver related?
    - pjmlp 7y ago
      Desktop Linux doesn't have a 500 Pound Gorila behind it. They behave quite differently in what concerns providing drivers for ChromeOS or Windows.
    - danShumway 7y ago
      Google has shown it's willing to force the issue on other parts of Androids -- particularly shipping Google Play with default apps. You can make an argument that's anti-competitive, or against the spirit of Open Source, but regardless, Google is willing to do it. Custom kernels definitely aren't the only reason why the Android update situation is bad, but they're also definitely a nontrivial part of it. A hardline policy that kernel patches had to be pushed upstream if you wanted to brand as Android with Google Play would probably go a long way towards improving that situation for everyone. Qualcomm would either say yes or all of their proprietary chips would become nonviable for the smartphone market. Linux itself can't force that issue because they don't have an attractive brand and suite of basically mandatory proprietary services to take away from smartphone designers who say no. The only thing Linux can do is make life more hellish for people maintaining userland drivers, which companies don't care about because they're not interested in maintaining their stuff to begin with.
- tasogare 7y ago
  Why Linux doesn't have a driver framework? That's seems the problem here. It exists in Windows, FreeBSD and probably elsewhere too.
  - adrianN 7y ago
    To encourage people to either open source their drivers so that they can be maintained inside the kernel tree, or to pay the cost of updating their stuff themselves so that Linux kernel hackers don't have to pay for backwards compatibility.
    - pjmlp 7y ago
      It does wonders for those stuck with AMD cards on their laptops not supported by the open sourced driver.
      - underlines 7y ago
        if i understand the discussion correctly user space drivers could not help, right? and sadly, user space drivers in android are fairly limited. https://developer.android.com/things/sdk/drivers https://developer.android.com/things/sdk/drivers
  - the_why_of_y 7y ago
    http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.kroah.com/log/linux/stable_api_nonsense.html
- chalst 7y ago
  Eric Raymond argued for mandating suppliers provide source to firmware; this problem is harder, but somewhat similar. http://esr.ibiblio.org/?p=6860 http://esr.ibiblio.org/?p=6860 (from 2015; excuse the grandiose tone, but the idea is interesting) Of course, no chance.

pjmlp 7y ago

The irony of Google security blog giving advice to a problem that the company is responsible for it happening in first place. Had they placed update requirements as part of the Play Store contract, vendors would be more keen in providing the said updates.

CiPHPerCoder 7y ago
The irony is real, but I appreciate P0's transparency here.