I think the more interesting thing here is the fact that so much code in their repository appears to be bit-rotted or half baked, despite being documented. KASLR is mentioned all over the place but doesn't work and the answer is "we know, it's there only to stop it bit-rotting". You need to patch the system to do kernel debugging because otherwise the toolchain hangs. Syscalls are documented as enforcing security rules yet the actual checks are //TODO comments (and they are still willing to assign CVEs so apparently they just forgot?!). The syzcaller tool is advertised as working with Fuschia, yet despite trying multiple different versions he can't even compile them due to API churn. Apparently downloading and executed a binary isn't even an option, despite their vision being that Fuschia is a sea of components downloaded and run from the internet.
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.
It's hard not to feel like maybe Google has lost the ability to develop operating systems.
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?
Yes. Android is sufficiently different from a stock Linux distro that it absolutely counts as a unique operating system. ChromeOS is also unique in interesting ways, although less successful. It's certainly a production quality OS.
Perhaps more importantly, both of those are complete and have real users who found value in them.
> ChromeOS is also unique in interesting ways, although less successful.
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.
That's just not true. It might not be seen in your particular country, but it's definitely not US centric. Canada, Sweden, and New Zealand are also countries where Chromebooks are sweeping education https://www.neowin.net/news/chromebooks-are-seeing-huge-adop...
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.
That's yet again not true. Parents are often paying for the Chromebooks used in some of these markets (eg, US & Canada at least). That the school requires a certain OS doesn't change who pays for it, just like parents are still buying TI graphing calculators.
> 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
"Scandinavian nations like Norway, Denmark, and Sweden are able to provide computing equipment to almost every single student and teacher within their borders"
Or maybe it's just that building a kernel, network stack, etc from scratch, and getting it to the point where it's stable, secure, sufficiently performant, compatible etc, compared to what's already out there is a massive undertaking - microkernel or not - and they just need more time.
Let's not forget that Android didn't even have smooth 60fps scrolling until well into the 2010s.
Building an OS takes time, they're doing it incrementally, the bugs were known and even had issues for them already. I wouldn't draw any crazy conclusions from this research, this is a hacker's exploration of a foreign OS, which is very interesting, but isn't something I'd draw judgments from.
Just because they have those banners up doesn't mean those point to some latent reason for whatever is responsible for their woes. Granted it gives a window in to the culture of the Fuschia team at Google, but to me, personally, it doesn't come off as virtue-signalling at all but rather a conscious effort to put diversity and inclusion in the front and center of what they do. As another example, Google has had socio-political doodles for decades, but I never considered those as virtue-signalling.
To me it comes off as inclusive of Americans while excluding the rest of the world. As a European I do not feel welcome, and I imagine people further from US culture feel even less welcome.
Not European, but not American either. It's weird to me whenever popular American (and they're always American) political issues get plastered all over tech documentation.
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).
It's relevant because it reflects their priorities and how they view developers.
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.
You’re comment and a sibling both express that these messages are off-putting to international audiences? Why is that?
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?
"I’ve seen plenty of tech companies with Ukraine banners on their websites, and have not seen a single criticism"
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.
>You’re comment and a sibling both express that these messages are off-putting to international audiences?
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?
I do feel that BLM is a worthy cause to support. This is mainly because I feel the movement can be seen separately from any formal organizations or individual people. I understand how you may disagree.
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.
I really can’t see the equivalency between a political stance (imo a movement for racial equality) and religion. The former mixes, often by necessity, with technical documents all the time. See GNU or the Apollo program.
> 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 think the issue is simpler than the above discussion.
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).
My guess is the only reason why Europe has a more sophisticated discussion about race and racism now than it did in the 50's is because of American influence. I say this as a European. There simply are not the sizeable minorities in europe to push these issues into the public discourse, and as such, without exposure to US culture, most people's views on race tend to be only lightly modified from traditional views, which are extremely racist.
Yes, I think you're right. And in many parts of Europe, there still isn't much sophisticated discussion about race and racism. (That's my observation as an outsider though; I'm not European.)
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.
> But pro-BLM is not the same thing as anti-racism, as I noted.
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.
>I really can’t see the equivalency between a political stance (imo a movement for racial equality) and religion.
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.
Let people say and express whatever they want. Why do you want to censor anything that you "hate" or anything that looks "ideological" to you? I don't see anything wrong with someone supporting BLM or mentioning a verse from the Quran or from the Bible on a technical website. For me, it would be an interesting short read/observation, I don't care if I don't agree, it doesn't matter. If I read a scientific paper from a Chinese researcher that mentions "Glory to the CCP", it would probably give me a short laugh, then I'll just move and focus on my goal (the science).
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.
> It's relevant because it reflects their priorities and how they view developers.
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?
>Having a large crowd of adults yelling "dentists! dentists!" or be it lawyers, accountants, etc in a frenzy would be seen as very unprofessional.
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.
My takeaway from the article is that Fuchsia exposes a capability-based interface externally, but uses the old kind of privilege-checking inside the kernel. Once a single sloppy check was found, the game was over: a privilege escalation and planting of arbitrary code into the kernel followed.
Yes - you can't run untrusted native code in the first place outside of the emulator ;)
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.
From the article, it looks like the syzkaller fuzzer integration was stale and not working, so there might still be some juice to squeeze if someone can get that running again : )
The intent of the post isn’t to claim that any Fuschia device currently sold is vulnerable. Unless Fuschia never graduates to running third-party code, that seemed like the right assessment to me.
That’s not really a “but” to the comment, which was that you need to find one bug and it’s game over. We’ve known for a long time that best practices aren’t enough to prevent memory corruption in large enough C++ code bases, so it’s likely a motivated attacker would eventually find something.
Sure - look i'm not gonna argue about C++ memory safety - i've funded and spent time trying to ensure we are funding figuring out how to get off of C++.
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)
What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel instead. I don’t mean that you can’t write bugs in memory-safe languages, but in the end the attacker still has to play by your rules. With a memory safety bug, attackers play by no one’s rules.
I admire your optimism, but the notion that missing access checks are somehow less dangerous in a memory safe language is nonsense on its face.
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.
No, logic bug consequences are fundamentally different from memory corruption bugs. A bug with an access check for one resource in the kernel means you get access to that specific resource. A missing bounds check in the kernel—anywhere in the kernel—means you get arbitrary code execution. Sure, _sometimes_ you can escalate from one resource to another with an access check issue, but that’s a _sometimes_. One memory corruption bug _anywhere_ defeats the protection of _all resources, all the time_. Not only that, but memory corruption bugs have well-understood exploit recipes that attackers can make once and reuse any time they find a new bug to save work, whereas an attacker has to write a new distinct exploit for most logic bugs.
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.
Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?
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.
Interesting. Is this in practice implemented as just capabilities being large numbers so it's impractical to guess them, or does the kernel have a table with all of a process's capabilities and when a message is sent to a process with capabilities the kernel adds them to the table?
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
The kernel maintains a table of which handle values each process owns and uses that to check the capabilities of the calling process when handling a syscall. Sending a capability in a message updates this table as the ownership changes.
We use (somewhat) large and non-dense numerical values for handle values to reduce the risk of accidental reuse of values.
> 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:
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.
> 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'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.
True. I was mainly responding to the ARM encrypted pointers part with that bit. ARM also didn't invent memory tagging, which might also have come from SPARC ADI (I'm not sure), but they also plan to include that. QARMA itself looks to be designed by Qualcomm engineers: https://eprint.iacr.org/2016/444.pdf
Yeah, ISA says you can. I wouldn't be surprised if other people pick other implementations, I'm not entirely sure why ARM felt the need for QARMA in the first place given there are already extensive choices for lightweight block ciphers, but... there you are.
You know a limited kind of capability - file descriptors (or kernel handles). Those are just a number that allow you to manipulate some object in a defined way. You can give this number to someone else, and they can't make use of it at all, you have to go ask the kernel (using e.g. a unix socket and ancillary messages) to pass the capability to another process.
That is sort of the opposite of a capability. In fact, files are capabilities exactly because you can hand off a file descriptor and, by virtue of that handle, you grant access.
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.
A leaked capability is indeed a critical failure. There are multiple ways to deal with that.
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.
It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to.
(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.
> It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to.
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.
I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzzy emulation"- you can in principle forge a URL in a way that you could never forge a file handle.
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.
Yes, accidentally sharing a capability is a leak. If I accidentally printed out a capability it would be 'leaked' and anyone who reads that capability now has obtained it an dcan use it.
> 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.
I'm specifically talking about Fuchsia and other kernel-based capabilities here. You fundamentally cannot print out that kind of capability in any way that matters- the only thing that determines whether a process has it is the table in the kernel, not whether it can produce a particular bit pattern.
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.
How so? The line you quoted from Wikipedia calls them unforgeable. If you can forge it (by printing it out and reading it back in from somewhere else, or by guessing a bit pattern) then surely it's not a capability?
So to recap, a capability is a value that represents authorization. The value must not be forgeable, the value must be communicable.
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.
> 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.
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.
No, it does not mean there is "a way", it means that the name is the permission. Period. That is what a capability is. If the name is not the permission, it is not a capability.
It can mean what the parent is talking about, and does in this case. It's an older morph of capability based security than the newer crypto enforced name concept, but equally valid.
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.
What you're referring to is how operating systems maintain the integrity of capabilities. This is addressed directly in 'Capability Based Computer Systems'. I would direct you to chapter 1 section 1.1.
> 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.
In these non crypto enforced capability systems, you don't have any control over other processes' names for resources addressed through capabilities is the point I'm attempting to get across.
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.
Semantics aside, is it accurate to say that schemes where the capability is represented as a signed token require care and diligence to mitigate leaks, and schemes where the capability is represented as a table entry (mapping a user/process to a permission) don't require any meaningful care/diligence?
Yes- the thing you didn't mention is the distinction I'm making between Dropbox URLs/UUIDs/etc and fds/Fuchsia capabilities, which is that the former are bit patterns and the latter are pieces of state in a trusted kernel.
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.
I wouldn't call it attack surface, I would call it a threat model. And yes, the threat model of capabilities includes the fact that knowledge of the capability connotes the capability. If it didn't, it wouldn't be a capability.
Then you've spent this entire thread arguing over clearly-explained terms of art, what a colossal waste of effort. I'm sorry to inform you: this is not how Fuchsia uses the word "capability."
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.
There's really no debate here. I'm right. A capability is defined as I have defined it. You can say "well Fuschia says otherwise", that's fine, people are wrong about things all the time. Such is life.
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.
To be clear, the answer to your question is "yes, you need a way to revoke capabilities if you care about them leaking", and the user who responded to you is incorrect.
In theory you could do even better than that -- you could make capabilities cryptographically signed tokens, so that you don't need to ask the kernel to verify the validity of your request every time. If your chipset supports crypto intrinsics this will almost certainly be better than an interrupted syscall.
Yeah, reminds me of biscuits[0] - because they're based on asymmetric cryptography they can be delegated, but also attenuated. If you just use a uuid that's not really going to work as well, unless you're willing to go back to some authority to forge a new, lesser capability.
Oh man KeyKOS, that brings back memories. I wonder if crypto intrinsics might breathe life back into something like KeyKOS. More contemporary, I think Sel4 does as well.
In my comment I meant "in theory fuscia could have been architected/could be rearchitected that way", sorry should have been more clear.
It's per process like the file descriptor tables under most kernels. Knowing that some other process has a certain socket open as fd '5' on their fd table doesn't give you enough information to attach the same socket to your fd table at fd 5 or otherwise.
Capability based operating systems require that your program possess something, like a handle, in order to do something privileged. Don't have the handle, can't do the thing. It's not about consulting ACLs or bitmasks or whatever.
Something that I haven't seen brought up yet is the "weird C++ vtable layout." This is actually the "relative vtable layout" that's first described here: https://bugs.llvm.org/show_bug.cgi?id=26723, and is usable in clang via the -fexperimental-relative-c++-abi-vtables option.
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.
Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway.
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.
Disclaimer: I made some contributions to Fuchsia and I am clearly biased.
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.
I just don't trust google to not abandon it like it has most other things they made that I invested in. It's brand erosion same as what's happened with Blizzard, used to have a lot of trust, lots of disappointments later and now I go in skeptical.
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.
Yes, it may well be killed, but that’s Ok - it’s an experiment. But, yes, you need to take that into account before investing time in it. The other mistake that I think people make is assuming that because Google is a giant Corp. these things will move quickly, when in fact Google often puts small teams on non-critical projects.
6 years of development and deployed to actual products is an experiment?
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.
> 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.
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.
> I am not sure why there's so much negativity around Fuchsia.
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.
Nobody has broken rules. The rules are simply permissive enough that you can still push out a Non-GPL drivers for a GPL mono-kernel.
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.
I love so many ideas Fuchsia brings in.
Blob storage as a primary FS type, software integrity, software archives that can naturally just pull blobs it requires from archives to name a few. A system that can as a first class, be atomically updated.
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.
> I am not sure why there's so much negativity around Fuchsia.
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.
> I am not sure why there's so much negativity around Fuchsia.
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 hilarious. I’ve been around long enough to remember people not trusting IBM and heralding Microsoft as the underdog with bright principles. Then it became Google being the white prince on a unicorn telling Micro$oft to eff off. For about a decade now we’re collectively in Not Trusting Google mode.
“It’s all just a little bit of history repeatin’.”
But given that's open source shouldn't it be a bit better? If I don't agree with some parts of the OS I can fork the project and remove some stuff. Given that's open source you don't have to fully trust Google, you can check things yourself. I know I'm probably bring native, but I am hoping to see some changes in the space.
MIT means it's only open source for as long as Google feels like it should be (and only the parts they want to keep open). Older versions will still be around to fork from, but maintaining a fork of an OS is a pretty large task.
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).
But that is a matter of licensing, not design (which I underdtand to be things like the capability system or the micro kernel). I'd prefer a Copyleft license too, but 1. it is not a suprise that Google is not interested in that 2. even with Android they are able to restrict the user.
Fuchsia still makes me deeply nervous inside. I get that linux has plenty of problems, but it really feels like Google have started to write an OS for the purposes of (a) having better remote control over the software that users run, and (b) being able to be free of the GPL. Security is the panacea that lets this happen, but I'm really not sure that it will inherently be better: iOS has effectively this model and it hasn't stopped a large number of nation-state actors effectively abusing it for hiding rootkits on victim's phones. The trade off for this is flexibility: the only reason I use an Android phone is because I can, with the right 3rd party OS, actually have a linux-based pocket computer that trusts me rather than its vendor.
People say this about a lot of security things. Ultimately, a lot of security is about constraining systems, and that makes people nervous. When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices.
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.
>When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices.
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.
> > When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices.
> 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)?
Please I beg you - don't let HN become another online discussion site. Aim for quality, give examples, don't just rely on vague comments that are meant to provoke emotion and nothing else.
Google won’t be producing Ad Campaigns against GPL, no. Yet the licensing model of the Linux Kernel & the kernel developer policy towards drivers & driver interfaces effectively renders Android hostage. This complicates Android’s architecture greatly which is why they’ve spent exorbitant sums of time trying to ameliorate the damage.
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.
The people who work on fuchsia are very good engineers - I’ve worked with many of them in person. But the project itself has always been a staff retention project. It only existed to keep said engineers from going to a competitor. I don’t know how any understanding of fuchsia is possible without this crucial fact
A company might persue projects for all kinds of reasons.
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.
This is not true and it’s odd people still take this bait voluntarily. At best this line used to be cheap PR to avoid GPL and Linux disciples going ballistic and to keep media off the project as much as possible.
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.
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.
I very much doubt you work at Google, and if you do, shame on you. This is quite an evil comment, thread, and line of thought.
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."
Right. This is what I think Fuchsia and Zircon probably are headed for long term but people really felt the compulsive contrarian need to stake out the experiment/retention project angle since so many saw the obvious but were hyperbolic about the timescale.
Not sure if it's ever feasible to replace Android (it's going to take at least a decade even assuming that Google becomes serious) but I think ChromeOS seems a reasonable target. It's not going to be as spectacular as Android but a decently successful migration if done properly. At that moment, I guess people can make more serious investments into Fuchsia.
You’re kidding right? Did you miss the parts about KASLR being broken and syscalls with TODOs for missing validations? And the CVEs created in relation to these?
I saw one CVE (CVE-2022-0882) for the innocuous kernel log bug. How many CVE's did you see? As for the KASLR, this was a known issue to the Fuchsia devs.
>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.
FTA: But to simplify my first security experiment with Fuchsia, I decided to disable SMAP and SMEP in the script starting QEMU and create the fake vtable in my exploit in the userspace
I don’t see them re-enabling it later, so yes, they found security problems, but they didn’t show a complete attack, either.
Also from the start they introduce a bug in the kernel (in the TimerDispatcher implementation), and this is the very bug they focus on and eventually write an exploit for.
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".
Exactly I also find it slightly silly to immediately declare this 'insecure' in this case here.
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 think this mostly happens to native English speakers for some unimaginable reason. I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.
I would guess that the difference native/foreign is simply due to the way language is learned: for native speakers, it's first and mostly orally.
This doesn't explain a later appearance of mistakes though…
As a nonnative English speaker (actually mostly reader/writer/listener), I started doing that at some point (many years after English proficiency), to my own dismay.
> I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.
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!
I was most disconcerted to find myself doing the same thing of late. It is very curious; like my brain internally just couldn't be bothered anymore to expend the energy to delineate their and there until I'm in the process of actually typing. But that means the signalling fires a tad late, so I'm going back and fixing stuff.
Hmm. By not providing a POSIX lemonade stand, would-be users are required to basically figure everything out for themselves; I wonder what the net impact of that is.
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?
The objective of computer security seems to have shifted from preventing someone else from running unauthoirzed software on your computer to preventing you from running unauthorized software on your computer. I would not describe this as security.
I would guess you have never worked as a technical suppport for your family’s computers? Because even if I very much understand your point, not being able to run untrusted code absolutely is a security advancement in certain situations. It is SO refreshing and liberating to be able to say: Do whatever you want with it, it’s very hard to damage on the software side.
That has nothing to do with untrusted code, but with how well programs are isolated from each other. You don't have to restrict the user for that.
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.
Ahh, the fix the "technical support" gambit. Good PR, connects with a sizable subset of the target.
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.
what kind of person who comments on hackernews doesnt do unpaid tech support for family members?
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.
Or you could just not give them admin rights and create limiter users for them. You do not have to surrender super-admin right to corporate overlords to solve this problem.
You want to limit what current and future generations of people can do with their computers because of something a computer illiterate grandma may have done in the 90s?
You badly overestimate both the ability and interest of average people in learning to administrate their computers. They just want to get shit done and go do something else. Computers are a tool at best, and more often a super-annoying thing they have to deal with but hate every second of it.
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.
You can have a locked down mode. You can even sell it turned on by default. But to exclusively prevent everyone from using their computers as they see fit because you think some people are too stupid to handle it? I don't believe you actually want that. I believe that's an excuse to ensure Apple gets a cut of everything that happens on their soon to be landfill machines.
I have almost zero interest in haxoring my phone, and just want it to always work and not let 3rd parties steal my info, automatically.
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.
For one, being able to use your computer/phone like a computer isn't 'haxoring'. Jesus. And second, Apple _lets you_ now (mostly anyways), because people with sense still raise a stink. So, basically, you're welcome. Stop screwing it up for the rest of us.
What's getting screwed up? It's cheaper and easier than ever to acquire a wide-open computer platform. There are also more of them than ever. There's just also a couple new categories of computing appliance—which is nowhere near being a new thing—that weren't around before.
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.
Phones and tablets are just locked down computers, not appliances. Do you want your laptop to be like that? Why not? Why is that any different than your tablet? Spoiler: It's not.
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.
Again: it is cheaper and easier than ever to get a "real" computer. They're at thrift stores for like $50-100, with peripherals. Raspberry Pi alone has sold over thirty million units. If a bright kid with a good idea asked for one on HN I bet a dozen people would ship their extras to them for free. Computers are given away for free pretty regularly on Craigslist and Facebook and such. Old but functional laptops can be had for tens of dollars on Ebay. It is wildly easier and cheaper to get into personal computing now than it was in the 80s, 90s, or even 00s. You can literally afford it by collecting loose change for a little while. A month of half-decent Internet service may well cost more than your entire computer set-up. This has been the consistent trend and it shows no sign of reversing, even after 15 years of iPhoneOS/iOS.
> the next Apple, only without the cruelty and greed.
But why is it necessary? It's not. We can have more if we work together, instead of against each other. The only thing locking phones down does is make everything worse _just_ for Apples sole profit.
Consoles play games and media, off course people like them. Did the PS3 having the Other OS feature mean people enjoyed gaming on it less? I don't think so. Piracy as the given reason to take the feature away is a poor one, they could've better isolated the gaming partition. Apple designs their products to be more user friendly than most, it shouldn't stop users from doing what they want. They don't on the Mac, but they do on the iPhone.
We’ve learned that most software that we run on our computers shouldn’t be completely trusted and most users can be tricked into running malicious software. Pretending that supply chain attacks don’t exist isn’t security either.
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.
I think the fact that Apple is a multi trillion dollar company from using basically that move plus aggressive marketing itself as high value means I'd expect more to try it. Luckily Linux exists to prevent the complete Appleization of computing (even if we did already lose cell phones to greed).
It was always been like that in properly configured enterprise systems, that is why we used to connect to UNIX development servers, instead of having a worstation on each desk.
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.
The computer doesn’t know whether it’s you or somebody pretending to be you. Unauthorised execution should be possible but should be off by default, that’s 100% better for consumers.
It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen.
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.
I like the idea of it being possible. Just because it's a feature doesn't mean you have to use it.
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.
Hi there, I work on Fuchsia, specifically on our Software Delivery system [1].
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!
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.
(At this point it's less "assume good faith" and more "halfheartedly check for the unlikely event that any good faith is present", but...)
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?
You have to chuck it in the bin and buy a new one, obviously. That's the state of the startphone world today, if you want to keep up on security updates
This is lamentable and I'd love to see longer periods of support for older devices, but I'm not sure what the ideal state is - beyond being able to install your own OS on your device, which will still require some level of support from someone.
These things work in tandem: the base system is pinned, but can also be easily updated with an OTA. Packages existing outside that set are resolved on-demand, and are thus updated when components in a package are run after a new version is published to the package repository.
until randomly without warning the latest version is broken, removes something, deprecates something, or is incompatible with something else. "always up to date" is something that sounds great but in practice has many many pitfalls.
Ironically, several folks who worked on Plan 9 later worked (or continue to work) at Google, although none of them worked on Fuchsia.
<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>
That’s fine as long as it’s open source and a self-contained local piece of software (as Fuchsia is). The problem with Google killing products is that they’re closed source and/or require huge server resources and/or ML models.
Operating Systems are not a very well defined subject. Linux doesn't include a UI layer for instance and that isn't considered a problem. Being tied to a particular experience limits the potential applications of the OS, so in many ways I would consider the lack of opinionated experience a good thing.
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.
Google's proclivity for aggressively wiping the spaghetti off the wall is starting to work against it. I think maybe they need to start promising to open source any products they lose interest in.
Every last bit of Zircon code he reproduced in the article was a woolly mess that the code's author (not the article's) should be ashamed of. That the author found it easy to code an exploit for a system he knew so little about shows that the code is not just woolly, but actually bad.
I'd encourage you to have a go at explaining nonetheless. I'm sure there are at least a few critiques you have which many here would miss, even if they are competent. There's always value in code review, no?
I didn’t downvote but I think it’s more because grandparent reads like a shallow offhand dismissal. Perhaps if GP provided examples of bad code and better ways to express them it would be a more productive comment.
I didn't see any actual technical content in that comment. I don't see any repliers commenting on tone but I do see a comment or remarking that they disagree with the technical assertion and asking for actual technical content to back it up.
So I think your assumptions about the reasons for the down votes are inaccurate.
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.