The patch needs to be provided by phone and tablet manufacturers. Except that many otherwise capable phones are not supported anymore and will not be fixed.
Were the firmware of these devices open source, the community could fix this (given that the firmware does not have to be signed, or a signing key can be added). But no, many devices will remain forever vulnerable. Including my phone, 4G RAM, 32G internal storage, excellent battery and screen, great computing capabilities, in a excellent physical shape. Will probably last a few years more. Last updated on November 2017 by its manufacturer. Some parts will never be updated again and there is no way to audit this stuff. This is a shame.
Edit: and I'm lucky my phone resembles an Android One phone, so some stuff can be taken from this phone to update mine.
Company A sells you a cell phone. In a reasonable time (5 years? 10?) a flaw is found. You, the costumer, can fix it? No, because it depends on proprietary code, a key, some DRM, whatever.
So company A should fix it or be accountable for the problem. Being sued, paying for it. Or open the hardware so that user can fix it.
Most people don't want to actually do that, but could anyway benefit from the inspection and fixes coming from third parties.
And when I buy some piece of hardware, I expect the manufacturer to fully support the device, as you said, when used the way it was intended to, but let me use it another way if I want to (which the reliance on closed binary blobs does not allow).
Moreover, it's time we consider it mandatory that the user has access to the code running on their device. People are not dumb. More and more, people want to know where their food come from and how it is produced. The same transparency should be obvious for what the computer do and how it is built.
If some things theoretically require the user not to see the code, maybe these things should not exist in the first place. "Oh, here is a product! But for your own good, you do not get to know how it works and what it does or does not do behind your back." This does not follow.
It gets even more interesting when the "secret sauce" is in software. Say I market "SmartButton 1.0", which is nothing more than an ESP8266 connected to a button, but with some cunning algorithms and proprietary protocols that make it useful. Under an escrow system, I'll have a competitor on my hands the second I stop supporting SmartButton 1.0. Even if I'm already on SmartButton v19.
If you have made genuine improvements in versions 2-19, releasing version 1 shouldn't hurt too much. If, on the other hand, your versions 1 and 19 are still substantially similar, you shouldn't stop supporting version 1 to save a small cost and completely destroy the value of the product for your customers.
Considering the global impact on security, this is an area that would make sense for regulation. At some point, the chip vendors should have to release their code to maintainers. I'd even be fine with limiting this to after the chip goes EOL! Perhaps it could come with guarantees reducing patent infringement risks, which may be where much of the vendor reluctance comes from.
> open source escrow
Is it better than, say, a gentleman's agreement to make the source public on github (or some other channel) upon dissolution of company?
(Disclaimer, I work for that company, but not in the escrow area)
Would highly recommend a penetration test for these.