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.
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.
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.
(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.
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.
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.
Unfortunately those people are often correct.
Wouldn't the easier path have been just for Google to contribute (or fork) Free/Open/NetBSD?
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.
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?
Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.
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.
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'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...
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.
This dreck would never pass code review at my shop.
It's becoming a kindergarten, really.
So I think your assumptions about the reasons for the down votes are inaccurate.
