RFC-0082: Runnning unmodified Linux programs on Fuchsia
fuchsia.dev
fuchsia.dev
Step 1: Require OEM's userspace drivers to use stable ABI (Android 8.0-9.0) exposed over a bus
Step 2: Require OEMs to use your way of doing secure boot chain (Android 10)
Step 3: Require OEM's kernel-space drivers to use stable ABI, and force the usage of Linux Kernel Modules (Android 11 -- we already lost the GPL here)
Step 3b: Start implementing VM support. Find a nifty marketing reason to have VMs ("Privacy Core")
Step 4: Require OEMs to use your own signed kernel (Android 12)
Step 5: Have said micro-kernel load/exec original kernel's executables
Step 5: Say that for security's-sake, it will be better of the nifty VM if its OS is a micro-kernel
Step 6: Require OEMs that your own signed kernel also runs as hypervisor
Step 7: Expose bus defined at step 1 across the VM. Use it to move various components from original kernel to the new micro-kernel, "for security reasons"
Step 8: Have said micro-kernel load/exec original kernel's kernel-space drivers (stable thanks to step 3)
Step 9: OTA kernel defined at step 4 to new micro-kernel
Step 10: Extinguished.
Android phones don't have any semblance of FOSS/Linux/DIY sprint in them anyway...
Nowadays, Linux's realtime is pretty good. Steven Rostedt has extensive documentations on how to "debug" realtime on Linux. You know what's the number one source of non-realtime-ness in Linux? It's parts of hardware that Linux simply can't control. He found that on many PCs, the BIOS triggers SMI (to refresh the RAM IIRC), and said SMI blocks the CPU.
In case you're thinking "Surely this is an x86-only mess", well, sorry, but that's wrong. It's even worse for embedded systems with shared memory bus, where modem has higher priority over the bus, and can decides to stall any memory access made by the CPU.
Switching to Fuchsia won't change much wrt real-time. (Possibly with Fuchsia, it is harder for OEMs to footgun their drivers, which would still be an improvement)
I think the reason Android would switch to Fuchsia is simply that Google is too big to rely on the community, and most engineers there don't have an opensource mind, so overall it makes it more convenient for Google to get rid of 3rd parties. Yes, it is a technical reason.
I agree that extinguishing is not Google's goal (which is why I didn't add embrace/extend). It is just a side-effect.
Too little imagination applied here. They will find a way. They always do.
Three years ago, gregkh did a presentation about LTS in Android. Guess who was using latest LTS kernels. Google? Nope. Sony and Essential are who.
Guess who upstreamed support for their phones in Linux kernel? Google? Still nope, again it's Sony.
How long was Pixel 1 supported? Ah yes, a whopping 3 years. (Same for Pixel 2 I believe). Who does better? Fairphone (circa 100 overall employees, and not many are software engineers), and nVidia.
Guess who provides major kernel upgrades? Sony (but not Google-certified sadly), and nVidia.
So far, Google hasn't shown any sign they are more capable than average OEMs to upgrade my devices.
The one Qualcomm supports in their BSP package for Pixels SoC.
You seem to not understand who exactly provides kernels for Android and other embedded devices.
If they can't even wrangle this for their own phones, how is going to a more permissive license and embracing proprietary modules going to make the situation better?
And this stuff isn't like an http API. I gave examples above about how NT has fallen behind Linux because of their stable API and binary drivers.
Why are you so darn sure that they're wrong and the model that's been failing for the last 15+ years is really the right one?
Oh, I perfectly understand how those things work, I've Google-certified more smartphones than I can count (which means more than 50), and that's merely one line of my resume.
In my comment, I mention Sony who upgraded their major kernel version. How does it fit your mental model of embedded system's BSPs?
I currently work in a company who provides software upgrades for a 10 years-old STB. This 10 years-old STB (that's older than the Nexus 4) is currently running Linux 5.4, and is planned to run Linux 5.14 in a few months, at millions of customers' home.
Are we bigger than Google? Gosh no, by orders of magnitude. Are we spending a lot of time on this? Well nope, we don't even need one person full-time to upgrade kernel version. Are we paying that person a lot? Nope, they could probably move to Google 500 meters away and have at the very least double salary.
Of course SoC-vendor stopped providing us with upgrades aeons ago.
But, contrary to Google, we actually have monetary incentives to keep supporting this device.
Google doesn't have an obligation to use Linux. Linux doesn't offer what they need, so they stopped using it.
However, I'm MAKING my own Android ROM. I actually do the job Google implied they would do when they announced Project Treble with Android 8.0 (which is actually providing working new Android versions on older Android vendors).
I'm guessing you don't know my project, so I'm making GSIs, which make Android's Project Treble actually usable to thousands of various devices. If you take Google's Project Treble as-is, you get /at best/ something that is not even a smartphone (you get no in-call audio, assuming you get calls at all, because it doesn't provide VoLTE support). I'm making it actually daily-drivable.
Many users are saying that I'm doing Google's job there, and even some Googlers said so. But of course, it's not in Google's nor the OEM's best interests to do that, which is way this job needs to be done by other people.
Also, I sent dozens of patches to AOSP, with very very small success rate. (While my contributions to Linux were pretty smooth)
But yes, I'm entitled to Google's work.
I'm pretty sure Google will disagree on that :P
No, I don't feel entitled to Google's work, the quote was sarcasm.
My point of showing my contributions is that I can do stuff on my own, that I'm happy that Android is opensource, and I do my best to contribute to it, in the opensource spirit. But if it stops being opensource, then so be it (it'd be a bigger shot in the foot for Google than for me anyway), I'm not simply leeching on Google's back, like previous comments assumed.
They did it because they wanted to be entitled to someone else's work (the free components they built it on). No one told them they couldn't be proprietary from the ground up.
This largely depends on them having the goodwill of the phone manufacturers in not de-googling their distributions. How would Google feel about Samsung switching the default search engine to Bing?
And for what matters, non-techies love Samsung´s UI skin.
In that nobody would use it on mobile without continued development from Google (Android development can easily pause after say a 5-10 year transition period) and without Google apps and services on it.
At best, you'd have Samsung or some Chinese company keeping the flame alive for a short while.
After that everything now Android will be Fucscia based.
They aren't going to be interested in supporting Linux after Android.
Google hasn't extinguished anything. Linux just didn't offer a compelling reason for companies to support it.
Logically it's very strong. It's also neither here, nor there.
The "extinguish" part refers to the transition from Linux on mobile being a thing thanks to Android (on billions of devices) to Linux on mobile not being a thing anymore (or being a small niche) in a post-Android/Fucscia world.
It doesn't matter if Linux on mobile wasn't a thing before Android, the same way when defending a murder "Well, the victim wasn't alive before it was born either, judge" is not an argument.
What you are describing is what happens when an inferior technology is replaced by a better one.
I'll agree with that.
It still is "use X when convenient, profit off X, build your own replacement piecemeal, throw X away and let it die" though.
Pretty sure doing that falls under the essential software freedoms, though, doesn't it.
I've been using Linux on all my (non-mobile) devices for a long time, but I'm excited about the potential of Fuchsia as a general purpose (including desktop) operating system.
## Capability Based Kernel
Each process gets its own custom environment and only has access to capabilities that it receives, either ambient ones provided at startup, or passed down from other process via "RPC".
Linux has a hodgepodge of isolation solutions with different levels of abstraction, ranging from namespaces or seccomp over Docker and other container solutions to selinux, AppArmor, Firejail, Snap and Flatpak.
In short: it's kind of a mess.
The low level functionality has been steadily evolving, driven by containers, but very little of the ecosystem was built with sandboxing in mind. Most of the end-user solutions are either a leaky sieve, fringe and barely used, or a pain to use. Often all three of them.
I have a really hard time seeing the Linux (desktop) ecosystem evolve into something that can be reasonably secure. Not because of lack of technical foundations, but because of ecosystem cruft and lack of motivation.
A new open source OS with sandboxing as it's core design element can open the door to actually secure ecosystem.
## Sandboxed Drivers
In Fuchsia drivers are regular processes and only get access to what they need via capabilities.
A big part of the Linux kernel is drivers. Many of them are buggy and have potential vulnerabilities. I'd much rather have my drivers running in an isolated environment. Especially with huge drivers that no one can audit anyway (eg graphics cards - the AMD graphics drivers alone take up a large percentage of the kernel)
YES, this does allow hardware manufacturers to not open source their drivers and keep their shoddy, badly written code private instead of polishing it somewhat and upstreaming it to the Linux kernel, denying any chance of auditing or customizing them short of reverse engineering. This definitely is a problem and a step in the wrong direction, which is my biggest concern about Fuchsia.
But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
## Library and Application Model
Fuchsia apps actually work a lot like Nix(OS). Apps are retrieved from a package registry and stored in an (immutable) blob store bashed on content hashes. Libraries are also shared between applications based on those hashes, which means different versions of libraries can be present and each application can have it's own set of libs.
As a NixOS user myself, this is exactly what I want.
In addition, system facilities like drivers and even higher level ones like an HTTP client use a standardized interface (via a FIDL schema and RPC) and can be swapped and plugged per application.
This opens a few interesting doors to application design. EG: you don't need to bake in an http client, you can just have bindings to the system interface, and let the OS provide the http client for you. (or let the user chose the implementation that they want).
This also has some interesting benefits for development.
---
In general, Fuchsia with its hybrid Kernel has made some really cool design decisions that would make it a great desktop and mobile OS, even for me as a big Linux supporter.
Do I trust Google to be a good steward of an open source OS and work with the community, rather than running a mostly "source available" project? Probably not. Do I have concerns about the effects on open drivers? Definitely.
But it's still a really cool effort, and a company like Google is one of the few players with the resources to actually make a new OS happen.
On mobile devices, the proprietary drivers are in user space. The kernel can be recompiled (because providers are forced to provide the source for their modified kernel), with necessary patches, which helps create alternative ROMs. This probably won't be a possibility anymore with a kernel for which you don't need to provide the source code. The drivers will probably be back in the kernel and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space.
So, the situation would stay the same regarding that.
> The drivers will probably be back in the kernel
Manufacturers putting drivers back into the kernel would be a step back for them since it would be more work than just using them in user space given there is a stable driver API.
> and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space
I think people forget that Fuchsia is more than the kernel. It comprises more things than Linux. Being based on a microkernel design, the kernel part represent just a small surface of the whole 'system interface'. All the rest is in the user space. The Android (platform) part of the system will be layered on top of this 'system interface', and will not define all the user space per se alone. This 'system interface' is well defined and documented [0] and, similarly to the Android (platform), they also have a CTS that tries to ensure that [1]. For example, the software layer implementing the product representing the Nest Hub is outside the Fuchsia platform, as will be with the Android (platform). So, a manufacturer implementing a particular feature inside the kernel, or in other component like drivers, will still result in its device having a 'system interface' at least compatible with the oficial Fuchsia one; if it's not, but offers something more, we all would be in the same situation where the provider bundles that features in closed blobs anyway.
I think Fuchsia's decoupled system architecture will make using an alternative user space not a big problem, if not even easier that it is with Android based systems.
[0]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0... [1]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...
The advantages seem very theoretical, the lack of tooling will be a problem at first. So there needs to be more compelling reasons to use it.
I am excited for a new operating system to emerge, that are far too few choices these days.
I would love to see tools emerge that are all from 2016 (?) going forwards without the legacy of standard UNIX tools.
It has the promise of innovation. A chance to start with clean hands.
I hope the UNIX tools are not going to be the ultimate ways of interacting with a system.
Microsoft has gone a bit of a different route with PowerShell. I hope Google will too
Do you think they're misdiagnosing the actual problem that WSL1 had?
If they can impose restrictions on applications, e.g. say to Android devs "you can only use this set of syscalls" and use e.g. seccomp to enforce that on Linux-Android, maybe they can get those applications to work. But if they want people to just take any Linux application and run it, they'll have to implement all kinds of crazy stuff. Take rr for example, they'd have to implement ptrace and perf_event_open and other arcane features that you really, really don't want to reimplement.
Today they're probably thinking that with some bounded amount of work they can run "90% of Linux apps" or something like that. But Microsoft thought the same thing about WSL1 and it didn't pan out, hence WSL2. It's strange to me to see Google failing to learn from that mistake.
Similarly, what is accessible from the NDK is limited: https://developer.android.com/ndk/guides/stable_apis
The Linux syscall layer (which is most of WSL1) lives next to, not above the windows syscall layer. But e.g. for all that filesystem access functionality, WSL1 doesn't just have to talk to the NTFS driver and generic FS layer but also to a lot of Win32 system libraries. If it doesn't, things will break. If it does, you have dependencies across layers, syscall conventions and system services. WSL1 didn't work because windows internals are a mess.
So I don't know anything about Illumos Linux zones, but if they run rr or docker or Firefox or WINE I'll be stunned. (Note that Firefox, rr and docker (by default) use seccomp-bpf syscall filtering which would be an absolute beast to implement in your Linux compatibility layer.)
The HN I remember would celebrate this technical success.
The technical achievement here is not so special, but the implied goal (removing user rights by switching from a GPL to an MIT/BSD operating system on billions of devices) is.
When reasonable people stopped commenting and engaging with bitter hateful commenters spewing bile in all the topics.
It happens sooner or later to most communities unfortunately - the toxic ranters push away any decent discussion with their ravings.
This topic is a nice example - so much wierd misinformation and misunderstanding just how Android and Fuchsia work (bot politically and technically).
I don't think this happened. However, since HN inception, more and more people (edit to clarify: in the general population) worry about bad uses of technical advances. This is true outside HN and it reflects in the community. Both are good things in my opinion.
> When reasonable people stopped commenting
Quite the contrary. People are considering the whole picture, not merely the technical aspect of things. They are also thinking about the long term consequences and what is at stake. Technical aspects do not live in a vacuum.
I'm quite happy that people are no longer unconditionally in awe about new tech stuff regardless of what is at stake.
I actually understand people who only want to consider technical stuff less and less, as someone who is interested in technical stuff a lot. Please, think critically.
It does not mean you need to be against Fuchsia or anything. Just broaden your sight and take the time to consider whether things are done according to your values, and don't be angry against people who do.
On Reddit, this kind of situation on a subreddit is called a "circlejerk".
Until that, I'll stay with the idea that much more people are at least aware of issues around new tech today than before Snowden revelations, let alone the beginning of the 2000s, and some of them are not happy with this even if they haven't taken actual actions, and even if they are not the majority.
HN is probably only in advance on those topics compared to the general population by the way.
(I added a clarification to the original post because I'm not sure you understood my post like I intended and the sentence was indeed ambiguous)
It's pretty clear that some people are only on this site to hate on "big tech"
It isn't new. There was a time when anything anti-Google or anti-Apple was downvoted to oblivion around 5 years ago, but that absolutely wasn't the historical norm (thankfully).
.
However, from a technical point of view, the Windows kernel is just as exciting but the restrictions on the source code and its use make it very hard to build excitement in a community like this.
From a practical standpoint, the whole goal of the project is to throw out the open source system because manufacturers can't be arsed to play nice with open source. The philosophy behind it undoes a lot of the technical merit that would otherwise make it exciting.
Had Red Hat, Canonical or another such company been behind the project, I think the community would be all over it. With the way things are going, this is probably going to go down in the open source world like Darwin has: a few hackers building on top of it, but mostly everything is left up to the big corporation managing it. This is entirely different from Android, where enhancements are often built into custom ROMs made possible purely by the GPL nature of the kernel source code, enhancements that more than once made their way into the core Android project.
While I'm excited about a brand new kernel, I'm disheartened by knowing this project is a harbinger of death for large parts of the custom ROM scene. When Fuchsia appears on phones, we'll be thrown back into the days of customising Windows Mobile installs, by moving around special DLLs and copying over magical data files. Open source makes it easier to modify existing code, but manufacturers won't be running the open source version of that code.
At what point are we going to call out Google for doing the “popular” embrace, extend, extinguish act?
- Solaris LX-branded zones;
- Microsoft WSL1;
- Google gVisor;
- Amazon Firecracker.
None of above done anything groundbreaking (other than ditching GPL). Why would you think LX-branded Fuchsia would?
Plus, you have various [LSM]s as a safety net. Android was an early adopter of SELinux, and latest releases still use it.
I distinctly remember ad companies using various tricks like reading /proc and the like to try and get information about what applications are running on a phone and what servers they are communicating with without asking for perms (it's fixed now, but it used to be a thing years ago). This is the kind of stuff that fuchsia should, in theory, prevent.
Refer to Genode Handbook for a decent definition and examples.
seL4 is formally proven to enforce capabilities.
Genode is, and should be reasonably easy to test on a regular PC, via bootable usb stick.
It can be quite confusing to use at first, as capabilities have GUI representation.
There's a blog[0] and some introductory video[1].
Can it be forced to?
> it loses all permissions normally associated with its controlling user, with the exception of "capabilities" it already has in the form of file descriptors.
What if we want to grant an app already running a new capability on the fly? E.g. I imagine a case of user opening a file in a GUI app as an OS-level file selection dialog getting invoked (provided the app already has a capability to invoke it, as by the manifest) and producing a capability for the app to access the file the user choosse in an explicitly specified (RO or R/W) mode.
The OS as a control point for where software can be installed and used is increasingly less relevant. It's increasingly about controlling the application stores and maximizing their reach rather than the OS platforms. Mobile is actually lagging behind these trends a bit; mostly because of draconian app store policies discouraging/forbidding anything that is "not native".
It will be interesting to see if Fuchsia will get a lot of adoption outside of Google. I'm very skeptical about their ability to convince others to use this. Even their strategy around Fuchsia remains murky. E.g. their whole IOT strategy resembles what they are doing with messaging in terms of quickly abandoned things that they announce with a lot of fanfare every year. One of these train wrecks is Nest, which they picked as a niche player guinea pig for the first commercial rollout of Fuchsia. I doubt it will move the needle for Nest. Or for Fuchsia.
Might be worth remarking that (historically, and AFAIK also currently) Docker on Windows and Mac used a Linux VM under the hood.
I thought that what Microsoft did to WSL was the first indicator of Embrace and Extend of Linux. I guess Linux was always 'used' as the testing bed for the giants for creating their own closed ecosystems.
Hardly surprising that Fuchsia exists for the same reason; as I previously predicted.
Edit: Of course, I know that this is technically possible already now, but if google creates an OS with the explicit support for such a contraption, there will be an industry where companies like Samsung can buy their "legal modules" for their target markets soon.
There are already many similarly licensed and capable OSes, some (e.g. FreeBSD) capable of running Linux executables. Are these hurting humanity? I guess you could argue that they've enabled proprietary OSes on, say, game consoles, which could be a negative on humanity.
The second is it strikes me as absurd that the thing standing in the way of government rootkits is copyleft licensing. The power to enforce GPL style licenses lies in government -- a corrupt government can just ignore it.
You can already ship proprietary kernel components with Linux. It happens all the time. It's why you can't use "normal" kernels on most smartphone devices. And it's easy for entities like the government or Google or Samsung or whoever to run their code in, say, TrustZone, or heck, just run Linux as a guest under a microkernel. So many ways to do it, and creating an evil BSD licensed OS with the primary purpose of furthering the surveillance state just feels ... silly to me. Because they just don't need to.
Tldr; I don't believe anyone who isn't already installed rootkits on our phones is holding out until they can do it "officially" with modules for a BSD licensed kernel.
And you don't see far more use cases where "proprietary modules" are meant for, besides the one you've mentioned (which is already possible anyway)?
Basically: to allow for a stable ecosystem for proprietary drivers for all kinds of devices (Fuscia will also be a desktop OS eventually)...
As spijdar observes, with FreeBSD the legal and technical obstacles were removed long ago. I find the claims of doom to be so overworked in your post that I am not clear as to what organisational obstacles you are talking about: can you calm down and express this point more clearly?
This will surely harm linux phones in the future.
Whether it is the end of the world is something I do not know, but it is not a net positive for software and hardware freedom on mobile devices.
One obstacle is still there: it has too low market share.
You mean the world is the linux ecosystem?
Well I disagree and I will just say, that the way I see it, Fuchsia is just pragmatic with drivers.
You cannot really force the vendors to ship open source drivers for your OS. But you can make it easy for them to write them against a stable ABI.
I would love to have a 100% open system. But because of proprietary standards and linux drivers policy, I am forced to use windows on my laptop. I rather would have a open OS and take just the proprietary drivers. Now I have to have the core proprietary and the drivers, with the alternative of messing with linux driver configs and custom kernels again. No thank you. I got work to do.
I would take fuchsia instead, if I could.
Which is open as far as I know, so I really do not see the way from here to government mandated rootkits. At least not through fuchsia.
I wish Google did exactly that.
> But because of proprietary standards and linux drivers policy, I am forced to use windows on my laptop.
How does it force you to run Windows? I don't understand. You just choose hardware designed for Linux and you don't need to care about the drivers at all.
Yeah well, if you can afford this (money and time) luxery and find what you need, good for you.
My hardware needs are not met with "linux designed hardware".
I need 2 devices: full powered gaming laptop and lightweight rugged long life battery touchscreen laptop: I found nothing in that realm and I actually did searched a long time.
So I have windows and chromeOS on my mobile hardware, but I gladly take fuchsia if it would be avaible.
> You mean the world is the linux ecosystem?
No, humanity in general. There has been a decades-long battle between the powers that would love to have everything tightly controlled by the manufacturer (or a consortium of corporations with admissions for a lofty fee) and users who are aware of the advantages of open computing. It's a dividing line between actually owning a computing device and something like leasing it under certain conditions even though you paid for it. As everybody household has more and more computing device, and as these become much more user-hostile, transparency and openness is needed more than ever.
Yeah, I agree to that.
Which is why I do not agree to a statement, that a new and open OS will hurt humanity, because it does not have the same restrictive licence, you would prefer.
If anything, this melodramatic mindset is really hurting the struggle to really own your hardware
Secondly, to really own your device, we need open hardware anyway. Everything else is a weak compromise.
But yes, all things considered, it's a bit similar to Apple using BSD as a base of Mac OS X - it had some positive effects on the overall ecosystem.
It is designed specifically, to give the manufactures the freedom to choose how they write and release their driver.
That can be open source, or closed. But it is not designed for proprietary. So I rather see it as designed for openness.
It can not be the job of a OS maker, to force change the way, the industry treats intellectual property.
This is a way bigger problem to solve, for the whole society.
Till then, I want the maximum on openness, I can realistically get, while still getting work done.
Fuchsia might help with that.
Essentially, they 'used' Linux as a test-bed for Android and now replacing it all with Fuchsia which aims to be as consistent as macOS and iOS. Starting with the Nest Hub [0] where the user won't notice anything different, which that is the point.
Due to the mess created by the Linux distro ecosystem, the free form swapping of system components by the user and driver maintenance hell vendors dealing with an unstable kernel API, I won't be surprised to see Fuchsia overtake ChromeOS and Android even by this decade. Not surprised to see Fuchsia attempting to run existing Linux apps too.
This just makes the process even quicker and everyone is watching them out in the open in real time™
[0] https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...
But fear not, you can still use non-free drivers with Linux!
edit: you said about chromeOS in another post. Congratulations, it uses Linux!
But it is very strongly modified and reshaped and is still no open system I can control or own. But it works. With standby times for example, my 100% linux laptops could not even dream about (and that is, with all the quirks and optimisations hacked into them) as they are worlds apart.
(standbydrain is something like from 100% to 0% battery in 2 days on full linux and over 4 weeks with chromeOS. My windows laptop lasts at least twice the time under windows, compared to linux. With more power.
Mainly because of good and bad drivers.
But currently, mobile SoC vendors _are_ shipping open source drivers. They must release the source code of kernel-mode drivers in compliance with the GPL.
The problem with SoC drivers is that they're not upstreamed and upstreaming them would require major effort and specialized knowledge. SoC vendors work under intense scheduling pressure and feel the need to cut corners. In other words, this code remains outside the mainline kernel because it doesn't meet the quality bar set by Linux maintainers.
Many mobile hardware vendors don't even see value in maintaining a single kernel tree supporting all their SoCs: their approach is to freeze on an LTS kernel early in the development cycle of a particular generation and then never rebase their changes onto newer kernels. They also work mostly in secret until the new SoC is unveiled.
A stable driver API would appear to solve this problem, but actually causes huge constraints for kernel development while not solving the actual driver quality issue. GKI is an attempt to go down this path, but several kernel hackers disapprove it:
https://source.android.com/devices/architecture/kernel/gener...
Why do you think that is?
(the criticism of GKI seems to be because of different issues)
As far as I understand, it is quite a deliberate choice of linux to actually force vendors to open source their drivers.
So what happens now is what you describe: the drivers get written against one lts kernel and then shipped and mostly forgotten. (Which is why I cannot really use my old android tablet anymore, despite the hardware did not degrade)
With a stable driver ABI, I could update to a newer android and keep the drivers as they are.
And with vendors writing drivers for a small and clear API - they could deliver better quality drivers, and update them - because they do not have tp deal with the very expensive whole kernel integration they have to redo for every kernel and every driver.
So yeah, in rainbow fairy unicorn world they all just open source everything and work in harmony and collaboration for the greater good of humanity. But in reality right now, with proprietary being the standard mode, it is just a mess. And I prefer pragmatic solutions that actually improve the status quo.
Long term they'll just add friction in their ecosystem.
What prevents one such now?
They’ve likely done some CBA and determined that porting their existing platforms to new operating systems requires a lot of work, and it’s far easier to sell a new SOC to OEM instead!
TLDR; blame Board manufacturers and not the Linux operating system/community as a whole. Although Google is trying so very hard to decouple the Operating system from the drivers as a whole.
"Not everybody is here, so lets talk until more people get here."
A perfect encapsulation of Google's approach to standards, I suppose.