So, still entirely closed hardware / firmware, just with some bits of the firmware supposedly disabled. Pure security theater incomplete form of verified boot / attestation that's there for marketing instead of as a meaningful or usable implementation (it's neither).
Conversation
Not sure why you care so much about proprietary components for device support in the OS that are not obfuscated and have full symbols available. It doesn't matter if the code is open or closed source beyond barrier to entry in working on it and people don't work on either anyway.
1
I care about those blobs because they represent a massive amount of attack surface that, as you admit, no one has time to reimplement and/or audit.
At least Google reviews the code they write, but it is obvious they don't review blobs either given vendor quality.
1
Google and other vendors are given the source code for these components and get to build them from source. The reason these things don't get attention is because they are specific to a hardware generation and no one cares to invest much time in something that becomes obsolete.
1
1
It doesn't particularly matter whether this code is open or closed source. Either way, people are not working on it much. Most effort goes into the device independent code. AOSP doesn't have blobs. Devices have blobs, whether or not you run AOSP using those or something else.
2
Qualcomm has invested effort into the open source driver stack but it's never ready in time for it to be what vendors choose to ship. Look at linaro.org/blog/dragonboa as an example. This is the same SoC as the Pixel 3. It has open drivers for mainline kernels. It comes too late.
1
That is the first credible evidence I have seen that there are people at Qualcomm that care about these classes of problems.
This is going to end with someone trying to get VC funding to pay for an actually open driver hardware target isn't it...
1
Qualcomm cares about selling hardware. They've been trying to get a mainline kernel driver stack up and going for years. It's incredibly difficult to land everything upstream. The upstream kernel doesn't accept kernel drivers only used with closed source userspace libs, etc.
1
1
There aren't kernel drivers to build userspace support because the userspace support hasn't been written for non-existent kernel drivers. It all has to be cleaned up, overhauled, ported over to upstream frameworks which are often totally inadequate and have to be improved, etc.
1
1
The open source driver stack for Snapdragon exists and is usable. However, it doesn't match the performance/functionality for devices it supports and it's ready a year or two after the hardware is launched rather than way before that which is what would have to happen...
1
1
So, since it's not what gets shipped, it obviously doesn't get the same resources applied to it. Over time, it's getting better and getting more resources applied but it's unclear if there will EVER be a point that devices can ship with upstream kernel unless they use an old SoC.
Once it gets upstream, there's a new LTS kernel branch every year at an arbitrary point in the year. Those LTS kernel branches are the only thing any sane vendor would actually ship on a production device. That delay things by another ~6 months after support actually lands...
1
1
So it takes 1-2 years to land support and then 6 months to 1 year for it to show up in a LTS, at which point everything that wasn't yet upstream has to be added, etc. They have to actually write drivers and ship something so the upstream stack isn't what they actually use.
1
I would happily use a crippled 5 year old SoC if it was going to continue to be sustainably manufactured.
I would even settle for wifi-only if I could have my 4 apps, open drivers, and decent secure boot.
2
Out of curiosity, what are those 4 apps you are talking about? :)
1
Show replies