A Kernel Hacker Meets Fuchsia OS
a13xp0p0v.github.io
a13xp0p0v.github.io
It's hard not to feel like maybe Google has lost the ability to develop operating systems. Fuschia has been in development for years now, it has no users outside of Google yet if you flick through their docs you'll notice a whole bunch of pages talking about deprecated components, migrations, etc. When I last looked at their docs, they read like it's been around for 20 years and has millions of apps, even though that's not true. Oh yeah and of course the giant BLM banners everywhere they have/used to have. Just checked, now those banners are replaced with "Honoring Asian Pacific American Heritage Month", lol. Apparently their vision of a futuristic OS is one in which every page in the docs has some random totally US centric bit of virtue signalling in it. No wonder they somehow can't even finish a microkernel, a design that reduces performance in return for a much smaller syscall surface area.
Did they ever have that ability? I know they did a bunch of work for Android/Chrome OS. But both of those are Linux, have they tried to develop an OS from scratch before fuschia?
Perhaps more importantly, both of those are complete and have real users who found value in them.
Chrome OS absolutely dominates the education market. So less successful than Android, sure (but so is literally every other OS at this point), but still very successful.
It can be hardly seen in European countries, and I bet other continents are hardly different.
And the reasons why are pretty straightforward. Kids can't really mess them up, they are highly sharable (eg laptop carts), they are cheap (generally), and they have centralized management for schools that's otherwise typically limited to enterprise markets.
Before COVID, most schools were still about pen and paper in most European countries, computers are used at home.
> Before COVID, most schools were still about pen and paper in most European countries,
Gonna need a citation on that one. It'd be quite surprising for European schools to be so far behind
And from what I can find, they weren't. Eg way back in 2006 https://www.theverge.com/2013/4/19/4242022/europe-ict-survey...
"Scandinavian nations like Norway, Denmark, and Sweden are able to provide computing equipment to almost every single student and teacher within their borders"
Using Pen and Paper isn't so far behind, it is the wisdom to avoid hype.
Everything else, including driver subsystem (Android docs even calls classic Linux drivers legacy), doesn't have anything to do with GNU/Linux.
Let's not forget that Android didn't even have smooth 60fps scrolling until well into the 2010s.
It feels irrelevant to the purpose of the page, and makes it feel like the page is targeted to people who have a specific viewpoint on a specific political issue (usually an issue that non-Americans have little context for).
The giant banners say this: although these are technical docs you may need to do your job, the most important thing you must see above all is an announcement of how morally pure we (think we) are. Once isn't enough. On our blog isn't enough. It must be the biggest and most eyecatching thing on literally every single page of our documentation. This indicates a lack of respect for the time and attention of devs. The implementation is also incompetent - the banner text appears to have leaked into search result snippets, thus reducing the utility of their docs search engine.
When Steve Ballmer jumped around on stage yelling "developers! developers! developers!" he was ridiculed because the outburst of energy seemed absurd and out of place for a CEO. But many of us appreciated the sentiment - that if you're developing an operating system then developers matter and their time/attention matters. Ballmer knew that. Platforms aren't chicken/egg situations where it's unclear what comes first. Apps come first. Users come for the apps. Then more apps come to follow those early adopter users, but ultimately, there had to be some apps to kick things off.
When the first thing you see at the top of the Fuschia docs is something totally unrelated to programming / the reason you were at that site, and which is irrelevant to most of the world as well, this sends a powerful message that the Fuschia devs are:
a. Staggeringly US centric. Their mindset isn't international at all. This is offputting to those of us outside the US. Fuschia's front page claims it's "an inclusive, open source effort". Not only have they never even tested it with a non-English locale, but they ignored the critical locale bug for so long other people had to fork the project to even make the emulator start up for non-English users [1]. That's about as non-inclusive as you can get yet is also absolutely predictable. Did we really need the blog to tell us that? Not really, we could guess it quite easily. The sort of people who demand such banners always seem to be hypocrites. It's called virtue signalling for a reason - people who do it announce their principles but never seem to live by them.
b. Not really rewarded for making developers happy. It reinforces a general impression about modern Google, that the personal success of the employees and executives is tied to things like the size of a giant black banner as much as whether their kernel is secure or their API docs are actually accurate.
c. As such extremely likely to manipulate their platform to prioritize the happiness of activists over that of developers. It's a bold statement of ideological allegiance. Who in their right mind is going to write an app for Fuschia that's braver than a shopping cart when they see that? Nobody smart, because you can guess what will happen if Fuschia actually does get apps: half of them will end up banned for some inane, impossible to understand reason, probably related to mundane use of language that's inexplicably become unacceptable since yesterday in California. The financial risk of developing for this platform is huge.
BTW: the Google doodles are pretty political these days, but in the beginning they were mostly reflecting things like national holidays.
BLM originated in the US, but black people definitely experience racism elsewhere. The movement is not necessarily US exclusive.
I’ve seen plenty of tech companies with Ukraine banners on their websites, and have not seen a single criticism. Wouldn’t such banners exclude US developers under that logic?
The Ukraine banners are dumb. They have no place in technical docs. Like everyone else I want them to win their war, but spamming blue and yellow flags everywhere isn't going to help achieve that. Moreover the murky nature of their military alliances (Azov etc) makes it hardly a Disney movie-esque conflict with pure good and pure evil.
You see no complaints because why bother? The sort of people who do that never care if their actions are unpopular with other people, in fact they take a perverse joy in it.
Non-American distinct from both of them here: They're right.
>black people definitely experience racism elsewhere
Persuambly you think BLM is a generic "Racism Bad" message, so 3 things to say about this
1- BLM is not a generic "Racism Bad" message. It's the name of a movement whose leaders used donor money to accumulate personal wealth. It's the chant used by protestors who burned down homes and stole from people's business. It's the motto that people who write books to argue that disputing a racism accusation is a sign of guilt and fragility. I consider myself a non-racist, and this movement is not the kind of things I support.
2- The kinds of people and media outlets who support BLM tends to be selective and hypocritical. Wouldn't an honest person who shout "BLM" when a black man is killed by a police officer, wouldn't that person also be obligated to shout "White Lives Matter", WLM, when white innocents are killed by a black criminal because of their race ? This last event happens to be a real thing that actually happened (https://en.wikipedia.org/wiki/Waukesha_Christmas_parade_atta...), by a self-confessed black terrorist. Searching for "Black Supremacy", the only response in the first page is a short Wikipedia page, the rest is articles talking about White Supremacy instead. I have a feeling things are not so balanced here.
3- Even granting that BLM is a good moral cause to support, how is it relevant to a tech document ? Let us grant the following causes are all worthy of moral solidarity ["Climate Change", "China's Treatment of Uyghur Muslims", "Sexual Harrasment", "Child Abuse", "Animal Cruelty"]. All of the elements of this list are morally abhorrent things to me that I want to prevent or reverse. Now, where and when should I say this? at my home? to each and every one of my friends or family ? at work ? on the street ? Is there any time and place where I can safely lie down and not speak about atrocities, for once?
>I’ve seen plenty of tech companies with Ukraine banners on their websites
I'm very very annoyed by this too. Seeing Github and JetBrains issue a statment about this conflict is the most pathetic, hypocritical and forced thing I have seen in a very long while.
Point 3 above applies to it straightforawrdly with no explanation, point 1 and 2 also apply as follows
1- Pro-Ukraine sentiment isn't a neutral "War Bad" message, it usually encodes within it pretty dubious and very partisan assertions, such as the belief that all Russians are to - and should be - blame and punish for Putin's action, as well as unhealthy and fanatic support for the Ukrainian government and its actions.
2- Tons of countries, everywhere and all the time, have experinced invasions and other illegal military actions. The example off the top of my head is Yemen. Children dying of starvation, civilaians bombed and hospitals wrecked, *Since 2015*. Did any of those companies issue statments then ? Let's forget about the past. Do we have a right to expect those companies to protest every single war and illegal military actions, regardless of the position of US politicians and US foreign policy, in the future?
Regardless, the real disagreement seems to be in where it is appropriate to represent the movements you believe in.
Even granting that a technical document page may not be the best place for such advertising, I still do not understand why the presence of these messages would offend an international audience.
If they are truly irrelevant, then surely it should be at worst unsightly?
What me and other people are trying to get across to you, is that you only feel this way because you support the cause.
The practice of filling every place and institution with your partisan beliefs is a sign of disrespect, essentially a power move. "You're here to read up on an OS, but joke on you, you actually can't escape the all-pervasive hand of my religion. Here's some propaganda diet before you read anything".
To know what that feels, imagine if every time a mainland Chinese scientist published an academic paper they were forced to write at the end "Long Live The CCP" with big bold letters. Or imagine if every time a Muslim scientist published a paper they must write "In The Name Of Allah, God Of All Creation" in the beginning. Etc... Can you see why this is ridiculous to a non-communist or a non-Muslim ?
Why is this ridiculous belief-signalling an expression of power ? 2 reasons :
1- Like I said above, it asserts existence in a space where its competitors don't. No Christian, Jew or Hindu declares their religion in the academic papers they author, it feels fair that Muslims also shouldn't, it's like an unspoken agreement on keeping Academia free of an irrelevant controversial subject that gets people riled up and generates more heat than light. When Muslims (in the hypothetical world) violate this, it's a unilateral violation of the agreement that signals power and superiority. "Rules Don't Apply To Us". It's a fighting stance.
In the concrete case we're discussing here, only progressive tech companies signal their beliefs in this vulgar way, no conservative tech firm have ever put "Blue Lives Matter" or "Make America Great Again" on their technical docs, although there are tens of millions of people who believe just as sincerly as you that those causes represent worthy and moral goals. The reason sane well-adjusted people refrain from expressing politics and religion in workplaces is because of common sense social protocols and unspoken consensus, when you break those, you're deliberately asserting power and inviting challenge.
2- It's probably forced. Just like the vast majority of Chinese scientists or Muslim scientists would probably do the above hypothetical signalling out of fear (of being labelled a traitor and a heretic, respectively), the vast majority of people in progressive-dominated social bubbles probably virtue-signal out of fear, rather than any geniune conviction. It's morally disgusting to force people to express beliefs they don't actually hold, or hold in lesser intensity than being forced to express. It's tyranny 101, straight from 1984.
> In the concrete case we're discussing here, only progressive tech companies signal their beliefs in this vulgar way, no conservative tech firm have ever put "Blue Lives Matter" or "Make America Great Again" on their technical docs, although there are tens of millions of people who believe just as sincerly as you that those causes represent worthy and moral goals. The reason sane well-adjusted people refrain from expressing politics and religion in workplaces is because of common sense social protocols and unspoken consensus, when you break those, you're deliberately asserting power and inviting challenge.
No, but many will willingly participate in the US military industrial complex, which causes significantly more actual harm. So I think we have different ideas regarding who can claim to be “sane”.
> 2- It's probably forced. Just like the vast majority of Chinese scientists or Muslim scientists would probably do the above hypothetical signalling out of fear (of being labelled a traitor and a heretic, respectively), the vast majority of people in progressive-dominated social bubbles probably virtue-signal out of fear, rather than any geniune conviction. It's morally disgusting to force people to express beliefs they don't actually hold, or hold in lesser intensity than being forced to express. It's tyranny 101, straight from 1984.
You say all this, but “probably” is doing a lot of work. This kind of banner is uncommon even among Silicon Valley companies. It’s not as if there would be outrage if it weren’t there, or if it disappeared.
Finally, these are all reasons why someone who doesn’t agree with BLM would feel excluded by the banner. My original question was why people outside of the US would feel excluded. Do you feel that most people outside of the US view BLM negatively or indeed have an opinion at all? Enough that the banner can be said to exclude international audiences in general?
I have no idea what to think about BLM. I'm not American, so it's not part of my zeitgeist. I hear all kinds of differing opinions about it from Americans. One thing is clear to me: "BLM good" is more complicated than just "racism bad".
When I see something supporting BLM in tech documentation, it's confusing (I don't know why it's relevant to tech documentation, and I don't know what to think about BLM), and alienating (the banner presupposes knowledge about BLM that most of the world doesn't have).
But pro-BLM is not the same thing as anti-racism, as I noted.
If you want to write down your values and plaster them at the top of every page of your tech documentation, I'll think that's a bit weird but I guess I'll mostly be fine with it?
But if you distill your advertised values into a single message of support for a political group that is virtually unknown in most of the world, that's more complicated. It makes it harder to understand the message, and it gives it an air of exclusivity, as the real meaning of the message is only understood to a subset of the people who see it.
I guess for me the BLM movement goes back to the roots of the struggle for civil rights in the west. The west has always had this tension between a strong history of formal equality (probably going back to the Roman citizenship tradition) and an equally strong tradition of slavery and segregation.
You can go back to the 1800's anti-slavery campaign slogan 'Am I not a man and a brother?', or to the MLK-era billboard 'I am a man', to 'Black Lives Matter', and you can see the basic line of attack is the same. Equally, every step of the way, their opponents have always said that contemporary forms of anti-racism are not really connected to the past forms, they're going too far, even though their slogans and basic politics are more or less the same.
If you're not from the west, I guess you can say, 'not my dog, not my race', but I think just as nations around the world have adopted western models of economics, and western models of citizenship, they also have to wrestle with the implications those models have for minority groups within their polities.
> But if you distill your advertised values into a single message of support for a political group that is virtually unknown in most of the world, that's more complicated.
I guess in the 70's, villagers in China knew about Huey P. Newton, but probably had a very shaky understanding of McDonalds. If there's one cultural export from America I'm rather pleased about, its the great work of their anti-racism campaigners. I'd be quite happy if the BLM message was as ubiquitous as the Coca Cola message, for instance.
Politics and religion are notoriously related. They are both morally charged subjects that infamously degrade people's ability to see the world clearly and discuss pros and cons rationally. I can cite plenty of pro-BLM speech and actions that disturbingly mirror religious language and actions. The fact that most BLM supporters might not speak or act like this is irrelevant too, most Christians don't go to church either.
>The former mixes, often by necessity, with technical documents all the time. See GNU or the Apollo program.
I'm really puzzled as to how this supports BLM banners in OS design documents though. You said "by necessity", is BLM mottos and iconography necessary to understand micro kernels as much as Cold War terms and timeline is necessary to understand the Apollo program ? that would be an... interesting point to argue.
Even ignoring this, not all politics is created equal. "The Apollo program was created as a demonstration of technical supramecy by the US intended to intimidate the USSR" is politics. "The Apollo program was when we showed those dirty commies who's the boss" is also politics. I hope you agree the first statment is vastly more palatable and neutral than the second. The vast majority of progressive mottos and rallying cries strike my ears like the second statment.
>No, but many will willingly participate in the US military industrial complex, which causes significantly more actual harm.
This is a strange thing to say for more reasons than 1
1- Conservative tech companies aren't any more likely to cooperate with the US military than progressive tech companies. Amazon and Google, hardly bastions of conservatism, are both known contractors to the US military. So if you hate this, you should hate all influential US tech companies, conservatism is not a useful predictor of this any more than random chance.
2- I'm not assessing who is "doing more harm overall", I'm assessing who's asserting ideological power over people in vulgar ways. US military power projection is an entirely different topic for a different conversation, we're now talking about who brings their obnoxious politics into the workplace. There are different ways of disliking things, I dislike the US military power posturing and US progressives power posturing in 2 different ways.
>This kind of banner is uncommon even among Silicon Valley companies.
Which is all the more reason to think it's forced virtue signaling.
>It’s not as if there would be outrage if it weren’t there, or if it disappeared.
I see you're unfamiliar with Twitter.
>Finally, these are all reasons why someone who doesn’t agree with BLM would feel excluded by the banner.
When it comes to religions and religion-like things, "disagree" is anything that isn't "agree". Any Non-Muslim "disagrees" with Islam, not because they have read the history of the prophet (which is awful) or studied Islamic Theology's arguments for why Islam is true (which is weak), but simply because Non-Muslims don't say "No God but Allah" and don't pray 5 times a day. They are non-believers, not dis-believers.
>Do you feel that most people outside of the US view BLM negatively or indeed have an opinion at all?
I can't speak for all the world off course, but I do feel that BLM is entirely irrelevant and unknown in my country, even if the events that sparked and galvanized it was internationally known. Again, no need for intense, explicit disagreement here, although I personally do think it's a destructive obvious scam\religion mix that every person who knows what it does and what kind of people run it should oppose it intensely, but there's really no reason to go that far.
Do you think you need hate or disagree with Islam to despise and hate the hypothetical practice of Muslims writing religious verses in completely unrelated writings? Do you think you need to hate or disagree with Communism to despise the hypothetical practice of Chinese Scientists writing pro-CCP mottos in completely unrelated writings?
My answer to the above question is No, I hate ideological spamming as a pathetic authoritarian practice regardless of the ideology doing it. In fact, sometimes I will hate the ideology itself, for no other reasons but the spam that its fanatics continually pump, and I think my view is a fairly popular and widespread to view things.
Whatever merits BLM might have had, it's completely eclipsed by the fact that their true believers seem to believe that micro kernel developers must hear them when they are reading up on their work.
Does this extend to letting people control other people and harass them with politics in their workplace to coerce them into expressing their politics ?
>Why do you want to censor
Quote 1 part of my comments where I advocated for censorship.
>anything that looks "ideological" to you
Is this meant to imply that "ideological" is subjective? Because I'm pretty sure all the examples I mentioned would all be recognized as partisan Ideology to the vast majority of people (except possibly the believers of said ideology, who would predictably disagree that it's anything but the plain obvious truth).
As for why I mock people who bring their ideology or religion to their workplace and why I think they are immature and unworthy of respect or cooperation, it's because I believe in not burning bridges.
Humans differ on uncountable millions of things, the exception is when we agree for once. A workplace is already full of potential and actual work-related conflicts enough, without somebody bringing in another certified-infinite source of conflicts that serves nothing except heat generation.
It's selfish and disgusting, like an army breaking a peace agreement to score a quick victory.
Yes, that they constantly think about diversity and inclusion. Though, I agree that encouraging workplace / employee activism is a tricky slippery slope. Companies like coinbase and basecamp eschew it, for instance.
Re: a: You gotta start somewhere. Besides, work to add a banner is probably a one-day / one-week low-hanging fruit, whereas i18n is not. In comparing those, you're comparing something that takes months to deride something that probably took hours to build and ship.
Re: b: Not privvy to today's culture at Google, so can't say for sure other than speculate.
Re: c: You view that as a bad thing. Such markers (drastic measures as it may seem to you) is how any of this changes. As a thought-experiment / deriving example from tech: do you oppose DNS encryption (a drastic measure in many a eyes [0]) because it nullifies existing cheaper surveillance apparatus deployed by schools, corps, governments; or do you embrace it and firmly want Browser and OS vendors to push forward with it?
[0] https://www.zdnet.com/article/uk-isp-group-names-mozilla-int...
It was much, much worse than that.
Putting aside the crass yelling and dancing; also putting aside any rumor of cocaine abuse; putting aside how cultish it looks...
Having a large crowd of adults yelling "dentists! dentists!" or be it lawyers, accountants, etc in a frenzy would be seen as very unprofessional.
> But many of us appreciated the sentiment
I hope not.
> It's called virtue signalling for a reason - people who do it announce their principles but never seem to live by them
And how do you know that? Some people can be hypocritical, yes.
Are all people with principles hypocritical?
If the CEO of a large dental organization has the balls to go on stage and yell, "Hygienists! Hygienists! Hygienists!", it shows that he's willing to prostrate himself to show his commitment to the company he serves. People appreciate that. There are certainly enough CEOs ignoring the needs and desires of their employees sitting inside their ivory towers these days. We don't need more of them.
I think the issue here is not "People With Principles", but "People With Principles They Are Dying To Tell You About". This makes the standard for judging you much much higher : You not only think those principles are superior to a lot of other competing ones, You not only advocate (sometimes, a lot of times to be honest, obnoxiously) for those principles, You do all of those things in times and places where it doesn't make much sense, and right in the middle of other people who might very well disagree with you to heaven and back on those things but choose to stay silent and cooperate with you on unrelated matters nonetheless, cooperation which you break and impede by loudly and non-ceaseingly declaring views they find disagreeable. This makes the people around you, understandbly, model you as the truest possible expression of an X-ism follower: you're at least as sincere as any other X-ist, so any failings or deviation from you principles you have or do is something that the whole X-ism movement along with all its followers also have or do.
I'm biased against what typical US progressives advocate for, so I will choose one of my own principles to make an example of.
I'm a (still booting up) vegetarian, I try not to eat any meat for ethical reasons. I did manage to successfully banish meat from my food for about 2 years now, but I'm not strong-willed enough yet to stop eating marine life. (Technically this makes me not a vegetarian at all, but the weird-sounding word "Pescetarian", but "vegetarian" is more well known and more in alignment with my mental self-image and future plans.) Now, if I started advocating for vegetarianism very loudly and in every single chance and place I find, not only will this make some people very annoyed, but they will start asking : What sort of life do you lead by following this principle you're very passionate about ? If my life deviates from my principles (and it does), I expect people will be even more annoyed, outraged even, and become resistent to and critical of my advocacy. A similar thing happens with nearly every major religion or religion-like ideology, which vegetarianism and progressivism indeed are.
Did I miss anything?
That's why the bug says: "The overall impact of this bug is pretty minimal in our current set of supported products, since none support running untrusted native code, and if you can run your own code on the system, then (at present) you can also use other existing supported workflows to obtain kernel logs, but it does seem to be a useful stepping stone towards privilege escalation if you have already obtained code-exec in some process through another exploit."
So while not awesome, also not possible on a real device right now without a code-exec exploit.
The fact he got KASAN working and talks about fuzzing suggests he looked for one, but couldn't find one, which is a good sign.
I just assume C++ code is unsafe, because it's really really hard to make it safe.
However, at the same time, the privilege escalation issues would have happened in any language - if you don't implement the check, you don't implement the check.
(and you could make it equally automatic in most languages)
Yes, this particular one enabled a defeat of ASLR, but so what? Missing access checks enable privilege escalation no matter what the language.
Your claim that "has well-definable consequences" is equally true in C++ as anywhere else. Whether you miss your access check in rust, or C++, or python, or whatever, the definable consequences are "privilege escalation".
Let's not pretend memory safe languages solve logic problems. They help with memory safety - that's awesome but not a complete solution.
If we want better verification of access contracts, we'd need a language with contracts or some other verifiable mechanism.
Those exist, and i'd support their use in this sort of case.
There is no equivalence to make. Memory corruption bugs are unambiguously, unequivocally better exploitation primitives than logic bugs.
No one is claiming that memory-safe languages solve logic problems. The claim is that most memory corruption bugs are conveniently exploitable and any exploit can reach for anything in the address space, and logic bugs often can’t. You could as well say that you’d rather promote chess pawns to knights instead of queens. Like, that makes sense sometimes, but it’s a bad default.
The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you).
In other words, a capability is like a key in a hash table, and unlike an index in an array.
That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a message to send them
We use (somewhat) large and non-dense numerical values for handle values to reduce the risk of accidental reuse of values.
It uses a couple of techniques, like wide/tagged pointers, object ids, and a special hardware managed bit to track illegal modifications.
If I had to hazard a guess, those object ids are probably useful for general capability systems.
I think apple (maybe as just an arm feature?) can do encrypted pointers, with a per application key tracked by the kernel.
ARM has added both pointer authentication codes and memory tagging extensions to their ISA, from (I think) ARMv8.5-A. Apple are the only ones to implement silicon that supports PAC that anyone can buy today but a) this will change fast and b) I might've missed something else.
I wouldn't say "encrypt". You can still read what the pointer is, you just can't forge it. It is more like a message authentication code, or keyed hash. Confusingly, the ARM ISA suggests you use the block cipher QARMA, a lightweight block cipher of their design. This is not a mistake - from a crypto academic's perspective the distinction between block cipher and hash is not so easy to draw as it tends to be communicated: you can get a block cipher out of the SHA family of hash functions (called SHACAL) and so on. There was a line of work on finding a suitable family of permutations (e.g. Gimli) that could be hardware-accelerated and appropriate constructions built from that.
tl;dr it is kinda a "signed pointer", and if you forge the pointer but get it wrong you don't get another chance because the CPU triggers a fault, so you can use lower security lightweight ciphers and still make exploitation very unreliable.
Now Fuchsia:
As to how Fuchsia does it, we can just look at the source:
1) https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z... 2) https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z... 3) https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z...
For example. I don't think there's any magic here: the kernel maintains some structure to reference jobs, tasks or whatever we are calling our isolated privilege boundaries, in which the capabilities are described. On the face of it this "looks" a lot like the traditional permission-style system, but the key difference is that the root job will hand out capabilities to processes it has created. An example is probably the best way to proceed: on a linux system, you might decide your process needs to read `/system/sensitive_file`. To allow this to happen, you might grant access to the user using some other command: chown .../chmod ..., or you might set an selinux policy, semanage fcontext -a -t myprocess_t /system/sensitive_file. In a capability-based system, chmod/chown and even running the process as a user don't exist as concepts. You would need to use a process authorized to transfer a capability to your target process to access this file. In some ways, this is closer to selinux, in the sense that semanage fcontext updates policy, except that the policy is somewhat dynamic here: if your controlling process provides the capability, then the child process gets it.
In a microkernel-based architecture, the idea is that "servers" (jobs that are arguably part of the system, but don't need to be in kernel) are similarly userspace processes subject to said capabilities also.
Of course, some part of the code still needs to be privileged here, let's call it the "executive". This code is doing the capability enforcement, and if that code contains bugs, all bets are off, as always. You can't defend such code from itself, even with capabilities.
The real disappointment is that Zircon is written in C++. Granted it was probably started before Rust was a thing, but while Ada/SPARK might be considered a bit unfashionable, it has some formal verification available, and if you're going for a software solution this should help reduce exploitable bugs. Personally I also wonder what about seL4 made it unsuitable for this: granted, it is not complete as a system, but neither is Zircon alone.
I'm not aware of other generally available chips with pointer authentication. The Qualcomm Snapdragon 8cx Gen 3 supposedly support PA. The Lenovo ThinkPad X13s supposedly contains it, but when will it actually be commercially available is anyone's guess.
Also, I think it's ARMv8.3.
A lot of good stuff has come from SPARC :)
File systems aren't actually capability based (generally, in practice) because you can 'ls' and 'cd ../'. Otherwise they could be.
Dropbox Paper is a good example of a capability based system. Anyone with a URL can perform actions on a page, but there is no way to derive a URL without already having access to it, you must be told what it is. This is because the urls are sufficiently random so as to be unguessable.
That's precisely how it works in FreeBSD (https://www.freebsd.org/cgi/man.cgi?capsicum).
There's also openat on linux. My point is that the general, practiced approach is not capability based.
1. Revocation is pretty critical
2. Bounding of capabilities is great - "You have this right for N seconds", meaning that a leak is less devastating
3. Not relying on capabilities is the best option. Capabilities are amazing, and a wonderful access control system. Their main benefit is that you can very naturally implement extremely fine grained access control. The downside is that it becomes hard to reason about that access control statically. ACLs are bad at super fine grained access control, but they're great for "I can look at a policy and know what this thing can/ can not do".
Layering ACLs and capabilities is a match made in heaven.
(One process can request that the kernel transfer it to another process, which I guess you might be referring to? I'm not familiar with Fuchsia specifically here but generally speaking capability-based designs sometimes let you "revoke" a capability if that is something you need, though that's not really something you would need to do periodically.)
The Dropbox approach is sort of a fuzzy emulation of this, by necessity, because it's a public internet service.
No, this is incorrect. Let's just quote wikipedia,
> A capability (known in some systems as a key) is a communicable, unforgeable token of authority.
communicable. It is practically the whole point that you can say "hey, here's a capability I have, now you have it".
Yes, it matters deeply if a capability is leaked. To name something is to authorize something, in capabality land.
No, you do not need to ask for it to be transferred. As with file descriptors in linux you can fork to delegate (or otherwise pass the handle around). Again, it is fundamental to capabilities that the capability is the authorization.
Dropbox's approach is faithful. And, in order to deal with these limitations of capability systems, Paper supports ACLs as well as capabilities. I think it's going to be a huge problem if Fuschia doesn't, but I don't know what they do - certainly some sort of MAC is desirable.
Obviously if you communicate the actual capability itself to someone you didn't intend to, that would be bad. But that's more of a question of API design- even fork is, in this sense, asking for the capability to be transferred. This is a very different problem than the one Dropbox has- no amount of random guessing, or side channel information leaks, or anything else like that, is going to land a capability in another process's kernel table.
> you can in principle forge a URL in a way that you could never forge a file handle.
Maybe it would be better to not talk about fs apis, because they're not really capability based, so I suspect that's the confusion.
The point is that if someone has a capability, they have that capability. There is no additional access control or checking in a capability based system. You absolutely have to consider things like rotation and revocation.
In this sense, fs APIs are a fine example, as long as you keep the ls/.. caveats in mind. If you have a file descriptor for something inaccessible through the global file system namespace, then the only way to grant that to another process is via specifically-designed APIs like domain sockets or fork.
As I said in my first comment, there are of course other reasons you might want to revoke a capability. But unlike Dropbox URLs, true capabilities are unforgeable, so you don't need to rotate them out simply to make them harder to guess- they're already unguessable.
If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability.
Delegation is not forgery. Forgery would be an entity creating a token without the token being delegated to that entity. Guessing is forgery, but you can "guess" a uuid in the same way that you can "break AES" with a bruteforce, which is to say, you can't.
You're taking "communicable" too literally. It doesn't mean "literally giving someone else this bytestring and now they can do it, too". It means "there is a way to give someone else the capability". SCM_RIGHTS is such a way to communicate capabilities between processes. Further up above you're also conflating files and file descriptors, which are very different things.
You can read more about it in Capability Based Computer Systems by Henry M Levy. The Hydra MMP, GE-645, and iAPX 432 are older implementions of this concept in hardware.
In both cases (TCB table enforced and crypto one way function enforced) the name is the capability, but in a kernel (or hardware) table enforced method that's interpreted to mean that you have permission to access the object by having a simply having reference to it in your descriptor table.
You can see this also in KeyKOS, EROS, Coyotos, XOK, and SeL4 among many other capability based kernels. They don't give you a capability just because you got access to a global name to the backing object; the whole shtick for them is there is no global names for objects, only descriptor tables.
> A capability thus provides addressing and access rights to an object.
> a program cannot access an object unless its capability list contains a suitably privileged capability for the object.
> Capability system integrity is usually maintained by prohibiting direct program modification of the capability list. The capability list is modified only by the operating system or the hardware.
> Thus, a program can execute direct control over the movement of capabilities and can share capabilities, and therefore, objects, with other programs and users.
You can think of capabilities lists as kernel managed namespaces if you'd like. Maybe that would help clear things up.
Crypto backed capabilities that merge the token with the capability itself are one morph of capability based systems, but that's not the scheme being described here. Leaking the name of a capability (the offset in the cap table) does not leak the capability itself in these TCB schemes. Capabilities are still communicable in these TCB schemes because they're explicitly supported in the IPC mechanisms like SCM_RIGHTS or seL4_Send along side normal data. The token naming a capability then is a per process concept and you can clone an identical capability into several tokens in the same cap table, unlike the crypto enforced scheme which are basically content addressed storage for a secret representing a capability.
Though, it is still worth thinking about how someone might accidentally leak a table-based capability via API misuse. For example, if table entries are reused over time you might get a sort of use-after-free situation where you mean to share an old capability but accidentally share the new one that replaced it.
The attack surface of "bit pattern" capabilities is much larger than that of "trusted state" capabilities- even if you can't practically guess one, all you need to break it is to discover its bit pattern somehow. Trick someone into printing it out, read it out of their memory space, leak it via a side channel, attack their UUID generator, etc. For this kind of capability, sure- periodic revocation might be a worthwhile mitigation technique.
But for "trusted state" capabilities, which is where this thread started, and what file descriptors exemplify, this all goes away. The attack surface is reduced to the kernel and the component's own API (nothing new here) and its use of a finite set of capability delegation APIs. Leaking an fd number does not leak the corresponding capability the way leaking a Dropbox URL does, so there is relatively little purpose in rotating those out.
Using your version of the word, since you appear incapable of operating in any other frame, Fuchsia does not use capabilities, and thus does not have the problem of leaking permissions via bit patterns. The original question of whether they need to be rotated periodically does not apply here.
Of course I've spent this entire thread explaining a clearly defined term, was that not obvious?
And yes, rotation is relevant to capabilities because leaking capabilities is a critical failure. It's not the only way to protect capabilities though, you can add ACLs or namespaces, which is what Fuschia seems to do.
In my comment I meant "in theory fuscia could have been architected/could be rearchitected that way", sorry should have been more clear.
(caller_capabilities[WHATEVER_CAPABILITY])(...);
when the capability is not present, then you get no_method_found or something similar.
The basic idea is that you don't need to waste a whole 64 bits for vtable entry, especially since you can usually assume that code within the same DSO will be within 32 bits of each other. So, instead, you do a 32-bit offset from a known address (the vtable's address) to get the function pointer, and in the rare case you need a cross-DSO entry, just emit a thunk for the symbol that's in the same DSO to get an address within 32 bits.
Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of back.
Code that has a preponderance of vtables is usually bad code written by Java transplants who haven't learned the right way to code C++. But that code has to run, too.
From the link: "I can report that a prototype of this was able to shrink Chromium's code size by 9%."
I am not sure why there's so much negativity around Fuchsia. From a technical point of view it's finally a serious attempt to do something new in the OS space. It might not be the right and perfect answer, but it might introduce new paradigms and maybe some fork of the project might be able to provide additional benefits for end users down the road. I know that there are lots of hobby/research projects trying out new stuff, but i think Fuchsia stands out because it might be able to land the innovation and make it accessible for a larger user base.
Personally I think Fuchsia is cool, and there is a lot to like, but I expect to hear it was killed by google anyday now.
The issue I have with Google is it's never clear to outsiders when projects are simply "experiments" that google is going to kill later. Dart, GWT, Angular Dart, for example, seemed like more than "experiments" yet google did a soft kill on Dart and effectively a hard kill on GWT.
You learn that something is "an experiment" when all the sudden updates slow or stop and the mailing list stops getting responses.
I don't trust google software because google bureaucracy is fickle and unpredictable.
Well if it's any comfort that's not clear to the Googlers either.
On the other hand if something is done by a startup there's also no way to know how much of a future it has. At least if it's open source then you have time to migrate to something else if Google stops investing in it. All the examples you name are Open Source.
And I don't think it's accurate to say Google did a "soft kill" on Dart. I don't recall any time when they reduced the manpower on the project, excepting perhaps the Dartino/Fletch (embedded Dart), which was explicitly labelled as tentative and experimental. These days things are going great for Dart.
What makes you say it's being killed?
From roughly 2013->2015 the mailing list was practically silent on dart.
Even then, the language got "rebooted" with a v2 in 2018 to try and stir up some new life in a language everyone thought was dead.
Because the real reason for its existence seems to be to slowly kill open source, by not requiring hardware vendors to provide kernel/driver source anymore.
Yes it does. The GPL literally does exactly that.
The Fuchsia design is good because it recognizes that reality and creates a world where patching the kernel doesn't require hardware vendors to rebuild their drivers.
In any case, the transition to MIT based FOSS on embedded platforms like Zephyr, RTOS, NutX,... proves that it won't matter for much longer anyway.
https://sfconservancy.org/copyleft-compliance/vizio.html
If it does, then any recipient of Linux will be able to sue for compliance.
As to why there’s so much negativity: no clue. I quite appreciate the idea of a blank slate devoid of cruft.
I'm concerned that it may not get real use or that Google might poison the well it dug.
But I would love to see it become a minimum viable desktop/embedded platform. But looking at CLs, sometimes the enemy of better/good is perfect.
Change is quite scary for some judging from the responses and there is finally a serious new OS that abandons the legacy Unix model and gives a refreshing approach to doing something new with support for only modern architectures.
To see it already running Chrome, Flutter, and being deployed on a Nest Hub without the users noticing tells me it is likely going to be the base of ChromeOS first and then it will replace Android in a couple of years with all Flutter and Android apps all running on Day 1 on the first phone running Fuchsia.
Won't be surprised to see Fuchsia on Chromebooks.
Easy: this is not the future we want. We don’t trust google. We don’t want an OS designed to further their goal of total control and surveillance capitalism.
“It’s all just a little bit of history repeatin’.”
Android is also open source, and is notably very difficult to simply fork and do your own thing and then actually use the thing, unless you happen to be a handset maker.
My OS entirely driven by Google? No thanks, they're making enough of a mess of the web (and Android lately, TBF).
What parts of the operating system design do this?
And for the same exact reason that I have less control over my phone, I also trust it radically more for my current threat model.
iOS is maybe a counter-example. It relies a lot more on the walled garden, which helps a ton with malware, but not as much with "legit app got owned".
It's worth noting that you explicitly believe Android to be "free-er", even though I would say the average Android device is safer. The two things aren't always at odds, and with Android it's also very device specific.
Another good example is HSMs and TPMs. Many people fear that these devices are inherently untrustworthy, but they also drive a lot of important modern OS security.
My position here is that Linux is something of a disaster with regards to security and it truly can not get better for a number of pretty fundamental reasons. If I had Google money I'd absolutely be investing in ways of removing Linux from my security boundaries - something they've already done to some extent with gvisor.
Some of the easiest phones to do this to today, namely the Pixel phones, are also some of the most secure stock Android phones on the market. Freedom and security are not mutually exclusive.
> Some of the easiest phones to do this to today, namely the Pixel phones, are also some of the most secure stock Android phones on the market. Freedom and security are not mutually exclusive.
What's so safe about it once you unlock the bootloader and install a custom ROM / rootkit (since by disabling boot verification you don't actually know that what you're booting is the custom ROM you intended to to boot or something else)?
Unfortunately those people are often correct.
Wouldn't the easier path have been just for Google to contribute (or fork) Free/Open/NetBSD?
Anyways, if you’re going to build an alternative or fork another stack —- you might as well hit two birds with one stone. Fuchsia’s relatively distinct capability-based, quasi-microkernel (it is not in fact a microkernel on a strict read) architecture is a chance to cleave off technical debt and start anew on security, and it’s relative modularity dovetails into the whole driver, kernel interface issue.
As a research project to inform design design, as a long term bet and sure, for staff retention.
You have more insight, but it's sort of hard for me to see even Google put that many millions into an OS and, more importantly, put it into production usage on actual hardware (Nest) if that were the case.
One factor here is that Fuchsia is in direct competition with both Android and Chrome OS.
Maligning it as just a staff retention project might serve those teams quite well... either as a coping mechanism or as a political tool to kill it off.
They’ve shipped Fuchsia on a real product now - the Nest Hub - they have Chrome working on Fuchsia, and an Android syscall interface in the works.
They removed this line from the site, possibly since it read as provocative, but for a few recent years they had updated Fuchsia.dev with “Fuchsia is not a science experiment”. Anyways, Google has a tendency to scrap projects as we all know but I don’t know if the recent trends point in that direction just yet, but it is possible - the project lead did leave recently and reportedly Meta were going to use Fuchsia for an AR/VR platform and switched to Android, likewise Google.
Google is one of few companies with capacity, capital and mindshare to make these kinds of projects.
It's under MIT (the kernel Zircon specifically since comparing with Linux). Whether a license allowing even more freedom is worse is arguable.
Yay for arguable freedom.
An MIT license is fine. Great, even, because Fuchsia is in fact still an open source OS.
Hardware OEM’s don’t owe the public transparent firmware blobs.
That exists already. Vast majority of Android devices require binary blobs in kernel for essential functionality.
That's the point. With something like fuchsia there can be entire closed forks of the kernel instead of having to blobs, making closed source easier to develop.
None of what you're saying is true, you've gone for extreme hyperbole in every comment you've made, from Fuchsia being a "retention project", to the Nest Hub being the "least important device" to "all users hate it" "it crashes daily now."
https://android-review.googlesource.com/q/fuchsia
What is more likely to happen is to replace Linux with the Fuchsia infrastructure.
Otherwise, why is Fuchsia already running the Chrome web browser? [0]
[0] https://9to5google.com/2022/03/04/full-google-chrome-browser...
Who in this day, and hour tries to make an OS as a commercial product?
Yes they do; they run code written by Google. The only thing worse would be Facebook; the literal NSA are more trustworthy.
Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.
>This is a known-issue. KASLR support on the zircon kernel is just there so that it doesn't bit-rot. We are always picking up a static address instead of a dynamic one.
>Once physboot rollout is complete, that should make it easier to support kaslr.
I don’t see them re-enabling it later, so yes, they found security problems, but they didn’t show a complete attack, either.
They explain why they do so, and the article is extremely valuable as a first step and tutorial to get started in Zircon kernel hacking. They also find some actual issues, including one CVE. But I disagree the article shows how "unsecure Fuchsia is as a result of being unfinished".
If it was directly end-to-end on say a Nest Hub running a release version of Fuchsia then that would be a more convincing here, as that would confirm that it can be deployed and the bug can be exploited in the wild and in production and not on a newly built developer version running in an emulator.
The writeup of finding and exploiting this bug is impressive, but whether if you can use that exploit to directly attack a production version of Fuchsia on a device like the Nest Hub is another thing, which is the same way security researchers do to break live versions of other OSes like macOS, Windows, Android and Linux.
I used to think that, too. But now my fingers just type the words as I hear them spoken in my mind, and that seems to occasionally produce homophones.
Kinda fascinating what this says about our language processing, to be honest!
You start with something secure and rudimentary and add features over time.
You don't start with something unsecure and then add security to it.
(yes... it's also a very limited OS... maybe someday it gets a decent GUI and starts to get more attention)
On the one hand POSIX et al is effectively impossible to deploy in a secure way, so there is a reasonable argument for going back to the drawing board; but on the other hand there isn't really a well-defined go-to alternative How To Computer model that is friendly to provable security, so everyone has gets to reinvent that wheel every time
Considering the contemporary status quo in terms of independently-implemented OS projects and platforms (eg, my ever-so-slightly-wobbly VxWorks-based TP-LINK consumer ADSL modem), I do wonder how good seL4 implementations end up working out in practice - the kernel might be rock solid, but what about all the bits on top of it, some of which presumably communicate with the outside world, consume various protocols, need to control the hardware in various ways (which includes relying upon reading the hardware state/status), etc?
Take the Web, we all run untrusted programs 24/7 there, every single snipped of Javascript is an untrusted program. Yet it neither does damage to our systems nor does it prevent the user from opening up the developer tools, hacking away on existing websites or making their own.
The Web isn't perfect either, but it's worlds better than Android and Co.
Susceptible to damage by inkjet cartridge DMCA attack.
Replace by "email support", nobody likes spam, much harder to defend. They've been softening up people with the anti-social media work, so it's palatable.
Good catch! I really am sorry if that's damaging or condescending, it's meant as a golden rule thing.
yes, i do, and the thing that i mostly find is people paying for "legitimate products" that their computers can do for free with essentially no additional hassle. Apple and google arent in the business of protecting your naive family members, they are in the business of monopolizing the exploitation of your naive family members.
Just yesterday i discovered that jpeg compression is broken in preview, and has been for years. The top result for what to do about it on the macos subreddit is to pay for image editing software.
i suspect you of arguing in bad faith.
That didn't go away because people learned. And it never would have.
No. Those people get newspapers and landlines.
If they actually like any of the computers around them, it's probably the most locked-down ones: their phones and video game consoles.
[EDIT] That is, you're way off in thinking it's only a bunch of soon-to-be-dead grandmas who have trouble operating computers that don't prevent them from fucking things up too badly. The "digital native" generations are barely better.
If yes, man that's really dangerous thinking.
And I'm a life-long computer geek who's done professional mobile development. Most people care even less than I do. They just want it to work, because computers aren't their life, they just use them to get stuff done, or when someone else tells them they have to. Would it be sort of nice to have the option to unlock it? Yes, exclusively so I could run pirated games in emulators more easily, which is the only thing non-programmers I know with unlocked Android phones use all that freedom of theirs for. For most people, they'd not pay even a couple dollars to have the unlock option. It's worth basically nothing to them, because they do not have any actual use for it. But sure, it'd be nice. It's just not a big deal.
> If yes, man that's really dangerous thinking.
The NES had a DRM chip—a bad one, but still.
Some computers have been appliances, and some have been programmers' machines, for a long time, and the sky hasn't fallen. The former have just eaten some of the use cases for the latter, where a fully-capable general-purpose computer was at least as much of a liability as a boon.
Even Apple still makes normal-ass computers for people who need them. If your reaction to that statement is "pft, yeah, but they're clearly trying to get rid of those", well, people have been saying that for more than a decade, and it still hasn't happened and doesn't seem to be any closer, so... I'll believe it when I see it.
This is super misleading. There's only slightly more wide-open platforms now than there ever were, but there's way, way more locked-down ones.
> There's just also a couple new categories of computing appliance
A couple?
Yeah, I'm counting phones and tablets as two categories. But I'm also being really generous on how old something can be and still be "new" (15 years is quite a while, in tech) and not counting those as just an iteration (admittedly, a big one) on PalmOS devices and such. They're also much closer to being general-purpose devices than most other appliance-type machines (consoles, dedicated set-top boxes, et c.), occupying more of a middle ground between the two.
I suppose you could add smart watches and make it three. Set-top boxes are at least 23 years old (TiVo), so stretch even generous definitions of "new", and we had closed-source non-user-modifiable DVD players well before that.
Some people only have access to tablets and phones. Let them have the freedom we had to create something. With that freedom, maybe one of them grows up and creates the next Apple, only without the cruelty and greed.
On top of that, it would reduce waste.
> the next Apple, only without the cruelty and greed.
Sigh. Well, never mind, I'm out.
And cheers bud, see yah round.
That's the opposite of what is being said.
The ability to sandbox software (with a lot of effort) means that you can run software you don’t trust. The web is built on this.
The ones being sandboxed is the user.
Try getting investor dosh without it. Not happening.
And later moved into having workstation VMs accessed on the network as soon as PC virtualization catched with what mainframes have been doing for decades.
Sorry if I got your point wrong :)
Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function.
Correct me if I'm wrong on any of this.
For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from.
Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.
You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products.
The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs!
[1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...
For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:
* a hardware key (on hardware that supports it), which checks the signature of
* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.
* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).
* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.
* base packages are then launched upon demand.
This establishes a direct line of trust from the hardware key to the base packages.
For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.
[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...
[2]: https://theupdateframework.io/
[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...
How do you insure that the end user is able to replace the hardware key and bootloader with one of their own devising (and generally to tamper with arbitrary parts of system) without a remote vendor/employer/DRM firm being able to prevent or detect it?
What's reasonable - 5 years of support? 10?
I guess I was thinking more Laptops and Phones.
The bad thing about Fuchsia is it's like a Google version of Plan 9.
<ramble> To me the major overlap between them is their designs are clearly informed by the contemporaneous shape of network architectures. Fuchsia is a take on what an OS design would be as a set of named microservices that can be routed. Plan 9 noticed network topologies of compute labs and clusters weren't too different, and both graphs could be represented in filesystems. The major visible difference to me is that the visibility of routing is much more apparent in Plan 9 than it is in Fuchsia. It's still a little difficult to understand how and where capabilities propagate through the system.
Implementation-wise, FIDL is a much different take than 9P2K. Though much simpler, 9P2K forces every API to exist via a filesystem interface (many of the higher level protocols also involve quite a lot of string passing) and struggles with throughput of streaming operations. Individual FIDL APIs might have similar problems, but the message encoding itself is relatively more efficient. </ramble>
They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.
But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.
There is now a UI experience available as part of Fuchsia in the workstation product, but I wouldn't overly index on it as it's just one take on what you could use Fuchsia to build.
This dreck would never pass code review at my shop.
I'm doubtful many people would be able to read it or contribute to it very effectively.
It's becoming a kindergarten, really.
So I think your assumptions about the reasons for the down votes are inaccurate.