Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitigations are attack surface, too

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Mitigations are attack surface, too

#11

Post by pjmlp »

izacus wrote: post #9
wtallis wrote: post #8

Earlier quoted context omitted.

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 t…

Desktop Linux doesn't have a 500 Pound Gorila behind it.

They behave quite differently in what concerns providing drivers for ChromeOS or Windows.

Re: Mitigations are attack surface, too

#12

Post by tasogare »

izacus wrote: post #7
CiPHPerCoder wrote: post #2

> 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.

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.

Why Linux doesn't have a driver framework? That's seems the problem here. It exists in Windows, FreeBSD and probably elsewhere too.

Re: Mitigations are attack surface, too

#13

Post by adrianN »

tasogare wrote: post #12
izacus wrote: post #7

Earlier quoted context omitted.

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.

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.

Re: Mitigations are attack surface, too

#14

Post by izacus »

rolandog wrote: post #10
izacus wrote: post #9

Earlier quoted context omitted.

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 t…

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?

> 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?

Re: Mitigations are attack surface, too

#15

Post by danShumway »

izacus wrote: post #9
wtallis wrote: post #8

Earlier quoted context omitted.

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 t…

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.

Re: Mitigations are attack surface, too

#16

Post by chalst »

izacus wrote: post #7
CiPHPerCoder wrote: post #2

> 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.

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.

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.

Re: Mitigations are attack surface, too

#17

Post by AnthonyMouse »

izacus wrote: post #9
wtallis wrote: post #8

Earlier quoted context omitted.

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 t…

> 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.

Re: Mitigations are attack surface, too

#18

Post by pjmlp »

adrianN wrote: post #13
tasogare wrote: post #12

Earlier quoted context omitted.

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.

Re: Mitigations are attack surface, too

#19

Post by the_why_of_y »

tasogare wrote: post #12
izacus wrote: post #7

Earlier quoted context omitted.

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.

Why Linux doesn't have a driver framework? That's seems the problem here. It exists in Windows, FreeBSD and probably elsewhere too.

http://www.kroah.com/log/linux/stable_api_nonsense.html

Re: Mitigations are attack surface, too

#20

Post by LargoLasskhyfv »

izacus wrote: post #9
wtallis wrote: post #8

Earlier quoted context omitted.

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 t…

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...

Post reply on HN