It's hard not to feel like maybe Google has lost the ability to develop operating systems. Fuschia has been in development for years now, it has no users outside of Google yet if you flick through their docs you'll notice a whole bunch of pages talking about deprecated components, migrations, etc. When I last looked at their docs, they read like it's been around for 20 years and has millions of apps, even though that's not true. Oh yeah and of course the giant BLM banners everywhere they have/used to have. Just checked, now those banners are replaced with "Honoring Asian Pacific American Heritage Month", lol. Apparently their vision of a futuristic OS is one in which every page in the docs has some random totally US centric bit of virtue signalling in it. No wonder they somehow can't even finish a microkernel, a design that reduces performance in return for a much smaller syscall surface area.
Did they ever have that ability? I know they did a bunch of work for Android/Chrome OS. But both of those are Linux, have they tried to develop an OS from scratch before fuschia?
Perhaps more importantly, both of those are complete and have real users who found value in them.
Chrome OS absolutely dominates the education market. So less successful than Android, sure (but so is literally every other OS at this point), but still very successful.
Everything else, including driver subsystem (Android docs even calls classic Linux drivers legacy), doesn't have anything to do with GNU/Linux.
Let's not forget that Android didn't even have smooth 60fps scrolling until well into the 2010s.
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.
Did I miss anything?
That's why the bug says: "The overall impact of this bug is pretty minimal in our current set of supported products, since none support running untrusted native code, and if you can run your own code on the system, then (at present) you can also use other existing supported workflows to obtain kernel logs, but it does seem to be a useful stepping stone towards privilege escalation if you have already obtained code-exec in some process through another exploit."
So while not awesome, also not possible on a real device right now without a code-exec exploit.
The fact he got KASAN working and talks about fuzzing suggests he looked for one, but couldn't find one, which is a good sign.
The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you).
In other words, a capability is like a key in a hash table, and unlike an index in an array.
That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a message to send them
(caller_capabilities[WHATEVER_CAPABILITY])(...);
when the capability is not present, then you get no_method_found or something similar.
The basic idea is that you don't need to waste a whole 64 bits for vtable entry, especially since you can usually assume that code within the same DSO will be within 32 bits of each other. So, instead, you do a 32-bit offset from a known address (the vtable's address) to get the function pointer, and in the rare case you need a cross-DSO entry, just emit a thunk for the symbol that's in the same DSO to get an address within 32 bits.
Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of back.
Code that has a preponderance of vtables is usually bad code written by Java transplants who haven't learned the right way to code C++. But that code has to run, too.
From the link: "I can report that a prototype of this was able to shrink Chromium's code size by 9%."
I am not sure why there's so much negativity around Fuchsia. From a technical point of view it's finally a serious attempt to do something new in the OS space. It might not be the right and perfect answer, but it might introduce new paradigms and maybe some fork of the project might be able to provide additional benefits for end users down the road. I know that there are lots of hobby/research projects trying out new stuff, but i think Fuchsia stands out because it might be able to land the innovation and make it accessible for a larger user base.
Personally I think Fuchsia is cool, and there is a lot to like, but I expect to hear it was killed by google anyday now.
The issue I have with Google is it's never clear to outsiders when projects are simply "experiments" that google is going to kill later. Dart, GWT, Angular Dart, for example, seemed like more than "experiments" yet google did a soft kill on Dart and effectively a hard kill on GWT.
You learn that something is "an experiment" when all the sudden updates slow or stop and the mailing list stops getting responses.
I don't trust google software because google bureaucracy is fickle and unpredictable.
Because the real reason for its existence seems to be to slowly kill open source, by not requiring hardware vendors to provide kernel/driver source anymore.
Yes it does. The GPL literally does exactly that.
As to why there’s so much negativity: no clue. I quite appreciate the idea of a blank slate devoid of cruft.
I'm concerned that it may not get real use or that Google might poison the well it dug.
But I would love to see it become a minimum viable desktop/embedded platform. But looking at CLs, sometimes the enemy of better/good is perfect.
Change is quite scary for some judging from the responses and there is finally a serious new OS that abandons the legacy Unix model and gives a refreshing approach to doing something new with support for only modern architectures.
To see it already running Chrome, Flutter, and being deployed on a Nest Hub without the users noticing tells me it is likely going to be the base of ChromeOS first and then it will replace Android in a couple of years with all Flutter and Android apps all running on Day 1 on the first phone running Fuchsia.
Won't be surprised to see Fuchsia on Chromebooks.
Easy: this is not the future we want. We don’t trust google. We don’t want an OS designed to further their goal of total control and surveillance capitalism.
“It’s all just a little bit of history repeatin’.”
What parts of the operating system design do this?
And for the same exact reason that I have less control over my phone, I also trust it radically more for my current threat model.
iOS is maybe a counter-example. It relies a lot more on the walled garden, which helps a ton with malware, but not as much with "legit app got owned".
It's worth noting that you explicitly believe Android to be "free-er", even though I would say the average Android device is safer. The two things aren't always at odds, and with Android it's also very device specific.
Another good example is HSMs and TPMs. Many people fear that these devices are inherently untrustworthy, but they also drive a lot of important modern OS security.
My position here is that Linux is something of a disaster with regards to security and it truly can not get better for a number of pretty fundamental reasons. If I had Google money I'd absolutely be investing in ways of removing Linux from my security boundaries - something they've already done to some extent with gvisor.
Some of the easiest phones to do this to today, namely the Pixel phones, are also some of the most secure stock Android phones on the market. Freedom and security are not mutually exclusive.
> Some of the easiest phones to do this to today, namely the Pixel phones, are also some of the most secure stock Android phones on the market. Freedom and security are not mutually exclusive.
What's so safe about it once you unlock the bootloader and install a custom ROM / rootkit (since by disabling boot verification you don't actually know that what you're booting is the custom ROM you intended to to boot or something else)?
Unfortunately those people are often correct.
Wouldn't the easier path have been just for Google to contribute (or fork) Free/Open/NetBSD?
Anyways, if you’re going to build an alternative or fork another stack —- you might as well hit two birds with one stone. Fuchsia’s relatively distinct capability-based, quasi-microkernel (it is not in fact a microkernel on a strict read) architecture is a chance to cleave off technical debt and start anew on security, and it’s relative modularity dovetails into the whole driver, kernel interface issue.
As a research project to inform design design, as a long term bet and sure, for staff retention.
You have more insight, but it's sort of hard for me to see even Google put that many millions into an OS and, more importantly, put it into production usage on actual hardware (Nest) if that were the case.
One factor here is that Fuchsia is in direct competition with both Android and Chrome OS.
Maligning it as just a staff retention project might serve those teams quite well... either as a coping mechanism or as a political tool to kill it off.
They’ve shipped Fuchsia on a real product now - the Nest Hub - they have Chrome working on Fuchsia, and an Android syscall interface in the works.
They removed this line from the site, possibly since it read as provocative, but for a few recent years they had updated Fuchsia.dev with “Fuchsia is not a science experiment”. Anyways, Google has a tendency to scrap projects as we all know but I don’t know if the recent trends point in that direction just yet, but it is possible - the project lead did leave recently and reportedly Meta were going to use Fuchsia for an AR/VR platform and switched to Android, likewise Google.
Google is one of few companies with capacity, capital and mindshare to make these kinds of projects.
It's under MIT (the kernel Zircon specifically since comparing with Linux). Whether a license allowing even more freedom is worse is arguable.
Yay for arguable freedom.
None of what you're saying is true, you've gone for extreme hyperbole in every comment you've made, from Fuchsia being a "retention project", to the Nest Hub being the "least important device" to "all users hate it" "it crashes daily now."
https://android-review.googlesource.com/q/fuchsia
What is more likely to happen is to replace Linux with the Fuchsia infrastructure.
Otherwise, why is Fuchsia already running the Chrome web browser? [0]
[0] https://9to5google.com/2022/03/04/full-google-chrome-browser...
Who in this day, and hour tries to make an OS as a commercial product?
Yes they do; they run code written by Google. The only thing worse would be Facebook; the literal NSA are more trustworthy.
Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.
>This is a known-issue. KASLR support on the zircon kernel is just there so that it doesn't bit-rot. We are always picking up a static address instead of a dynamic one.
>Once physboot rollout is complete, that should make it easier to support kaslr.
I don’t see them re-enabling it later, so yes, they found security problems, but they didn’t show a complete attack, either.
They explain why they do so, and the article is extremely valuable as a first step and tutorial to get started in Zircon kernel hacking. They also find some actual issues, including one CVE. But I disagree the article shows how "unsecure Fuchsia is as a result of being unfinished".
You start with something secure and rudimentary and add features over time.
You don't start with something unsecure and then add security to it.
(yes... it's also a very limited OS... maybe someday it gets a decent GUI and starts to get more attention)
On the one hand POSIX et al is effectively impossible to deploy in a secure way, so there is a reasonable argument for going back to the drawing board; but on the other hand there isn't really a well-defined go-to alternative How To Computer model that is friendly to provable security, so everyone has gets to reinvent that wheel every time
Considering the contemporary status quo in terms of independently-implemented OS projects and platforms (eg, my ever-so-slightly-wobbly VxWorks-based TP-LINK consumer ADSL modem), I do wonder how good seL4 implementations end up working out in practice - the kernel might be rock solid, but what about all the bits on top of it, some of which presumably communicate with the outside world, consume various protocols, need to control the hardware in various ways (which includes relying upon reading the hardware state/status), etc?
Take the Web, we all run untrusted programs 24/7 there, every single snipped of Javascript is an untrusted program. Yet it neither does damage to our systems nor does it prevent the user from opening up the developer tools, hacking away on existing websites or making their own.
The Web isn't perfect either, but it's worlds better than Android and Co.
Susceptible to damage by inkjet cartridge DMCA attack.
Replace by "email support", nobody likes spam, much harder to defend. They've been softening up people with the anti-social media work, so it's palatable.
Good catch! I really am sorry if that's damaging or condescending, it's meant as a golden rule thing.
yes, i do, and the thing that i mostly find is people paying for "legitimate products" that their computers can do for free with essentially no additional hassle. Apple and google arent in the business of protecting your naive family members, they are in the business of monopolizing the exploitation of your naive family members.
Just yesterday i discovered that jpeg compression is broken in preview, and has been for years. The top result for what to do about it on the macos subreddit is to pay for image editing software.
i suspect you of arguing in bad faith.
That didn't go away because people learned. And it never would have.
That's the opposite of what is being said.
The ability to sandbox software (with a lot of effort) means that you can run software you don’t trust. The web is built on this.
The ones being sandboxed is the user.
Try getting investor dosh without it. Not happening.
And later moved into having workstation VMs accessed on the network as soon as PC virtualization catched with what mainframes have been doing for decades.
Sorry if I got your point wrong :)
Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function.
Correct me if I'm wrong on any of this.
For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from.
Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.
You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products.
The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs!
[1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...
For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:
* a hardware key (on hardware that supports it), which checks the signature of
* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.
* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).
* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.
* base packages are then launched upon demand.
This establishes a direct line of trust from the hardware key to the base packages.
For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.
[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...
[2]: https://theupdateframework.io/
[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...
I guess I was thinking more Laptops and Phones.
The bad thing about Fuchsia is it's like a Google version of Plan 9.
<ramble> To me the major overlap between them is their designs are clearly informed by the contemporaneous shape of network architectures. Fuchsia is a take on what an OS design would be as a set of named microservices that can be routed. Plan 9 noticed network topologies of compute labs and clusters weren't too different, and both graphs could be represented in filesystems. The major visible difference to me is that the visibility of routing is much more apparent in Plan 9 than it is in Fuchsia. It's still a little difficult to understand how and where capabilities propagate through the system.
Implementation-wise, FIDL is a much different take than 9P2K. Though much simpler, 9P2K forces every API to exist via a filesystem interface (many of the higher level protocols also involve quite a lot of string passing) and struggles with throughput of streaming operations. Individual FIDL APIs might have similar problems, but the message encoding itself is relatively more efficient. </ramble>
They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.
But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.
This dreck would never pass code review at my shop.
I'm doubtful many people would be able to read it or contribute to it very effectively.
It's becoming a kindergarten, really.
So I think your assumptions about the reasons for the down votes are inaccurate.
