Mitigations are attack surface, too(googleprojectzero.blogspot.com)
googleprojectzero.blogspot.com
Mitigations are attack surface, too
https://googleprojectzero.blogspot.com/2020/02/mitigations-are-attack-surface-too.html
22 comments
The irony is real, but I appreciate P0's transparency here.
> On Android, it is normal for vendors to add device-specific code to the kernel.
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.
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.
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.
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.
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.
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.
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.
> This "oh, just force them!" mindset is incredibly naive and hasn't worked for desktop Linux in years.
Are you kidding? There are open source drivers for nearly everything on the desktop. The biggest holdout is nVidia, and that's for the same reason as Qualcomm -- they have inadequate competition. There are people who need CUDA which allows nVidia to shove proprietary drivers down their throats. And even that's slowly eroding as AMD comes out of the decade they spent asleep.
The problem with Qualcomm is that they keep buying every prospective competitor and the antitrust authorities haven't done anything to stop them, so there is no market pressure for them to do what the customers want because the customers have no alternative.
Are you kidding? There are open source drivers for nearly everything on the desktop. The biggest holdout is nVidia, and that's for the same reason as Qualcomm -- they have inadequate competition. There are people who need CUDA which allows nVidia to shove proprietary drivers down their throats. And even that's slowly eroding as AMD comes out of the decade they spent asleep.
The problem with Qualcomm is that they keep buying every prospective competitor and the antitrust authorities haven't done anything to stop them, so there is no market pressure for them to do what the customers want because the customers have no alternative.
I don’t know about you, but if I were a big company evaluating vendors for my scientific computing / HPC cluster, whether or not a vendor has open source drivers would be pretty low on my priority list. If AMD comes out today with a CUDA competitor that people use with high adoption, companies will switch, and it won’t be because AMD’s drivers are open source.
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.
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.
Comparative difference in value between desktop linux users (either individually or as a collective) vs Android mobile phone manufacturers is very different.
From the perspective of the hardware manufacturer, individual desktop linux users are worthless, and they're unable to form a large enough collective to have enough money to matter either.
Individual Android vendors may or may not be large enough to try and force the hand. Google requiring this as part of the Google Play contract, thus bringing a large number of Android manufacturers together, is a very different beast.
That said, there's still no way to know whether or not it would work, but comparing the collective phone manufacturers to desktop linux users doesn't really seem like a fair comparison.
Linux desktops remain a minority share. Linux mobiles account for the vast majority of smartphones in the world.
From the perspective of the hardware manufacturer, individual desktop linux users are worthless, and they're unable to form a large enough collective to have enough money to matter either.
Individual Android vendors may or may not be large enough to try and force the hand. Google requiring this as part of the Google Play contract, thus bringing a large number of Android manufacturers together, is a very different beast.
That said, there's still no way to know whether or not it would work, but comparing the collective phone manufacturers to desktop linux users doesn't really seem like a fair comparison.
Linux desktops remain a minority share. Linux mobiles account for the vast majority of smartphones in the world.
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?
Or was that just a proposal?
> 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?
Hmm, can you clarify? Storage changes aren't really driver related?
Desktop Linux doesn't have a 500 Pound Gorila behind it.
They behave quite differently in what concerns providing drivers for ChromeOS or Windows.
They behave quite differently in what concerns providing drivers for ChromeOS or Windows.
May i remind you of https://www.reuters.com/article/russia-satnav-idUSLDE7331242... ?
That was a "soft forcing" which worked. Because nowadays there is almost no phone on the market which is incapable of working with GLONASS.
Of course you can overdo this, like (at least in the past?) Brazil did to push indigenous suppliers and markets, with the effect that they don't really have them, and everything "digital" is just more expensive.
But it could work. Depends...
That was a "soft forcing" which worked. Because nowadays there is almost no phone on the market which is incapable of working with GLONASS.
Of course you can overdo this, like (at least in the past?) Brazil did to push indigenous suppliers and markets, with the effect that they don't really have them, and everything "digital" is just more expensive.
But it could work. Depends...
Eric Raymond argued for mandating suppliers provide source to firmware; this problem is harder, but somewhat similar.
http://esr.ibiblio.org/?p=6860 (from 2015; excuse the grandiose tone, but the idea is interesting)
Of course, no chance.
http://esr.ibiblio.org/?p=6860 (from 2015; excuse the grandiose tone, but the idea is interesting)
Of course, no chance.
Why Linux doesn't have a driver framework? That's seems the problem here. It exists in Windows, FreeBSD and probably elsewhere too.
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.
It does wonders for those stuck with AMD cards on their laptops not supported by the open sourced driver.
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
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...
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...
Apertif: But in the Android ecosystem, that doesn't mean that it actually makes its way into device kernels.
Had they placed update requirements as part of the Play Store contract, vendors would be more keen in providing the said updates.