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.
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?
> 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)
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.
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.
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.
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.
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.
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.