bestorworse

I want that as well, but I don't think it's practical to do that on the Linux desktop ecosystem. Too slow, too much politics. The gist of it is done by Android though, but that required extensive re-engineering of the user space.

Risking getting down voted but I don't want to repeat myself: https://news.ycombinator.com/item?id=43255985

Sure, like you said, having control of the endpoints you could communicate anything if you can transmit bits. That’s unavoidable.

But don’t lose the perspective on the benefits of such an architecture. Considering the networking access example:

* If your process gets compromised it won’t be able to access the attacker’s C&C server. It wouldn’t have access to any other stuff that the process didn’t already have for that matter.

* You wouldn’t be able to use http. It would be https only.

* Your process wouldn’t need a lib to talk HTTP. It would just need to talk the IPC protocol (whose wire-format and related details are standardized in Fuchsia which allows for the binding code for (de)serialization to be auto-generated).

* You wouldn’t be able (for better or worse) to mess with SSL certificates, proxies, DNS resolution, etc.

Consider another example -- file access. Say your app wants to access a photo. It doesn’t have access to the filesystem nor to the user’s folders -- it only has access to, say, an “app framework services” capability (eg. services from an UI-capable OS like Android) whose one of the “sub-capabilities” is requesting a photo. When your app does that request the ‘system’ opens a file selection GUI for the user to pick a photo. Note that the photo picker GUI is running on a different process and your app doesn’t know and can’t access anything about it. All that matters is that your app will receive an opened file handle in the end. The opened file handle is a capability as well. The file handle would be ready-only and wouldn't need to actually exist in any file system. In this example, before handing the file descriptor to your app, the “system” (or whatever process is implementing the ‘photo-picking’ capability) could process the image to remove metadata, blur faces, offer the user to edit the image (and maybe actually save it to a persistent store), log that access for reviewing later, etc.

(We already have something kinda similar in Android, but the implementation is not from first principles, so it’s very complex and prone to issues (requires an obviously non-POSIX Android userspace using lots of security features from the Linux kernel to sort of implement a microkernel/services like architecture)).

EDIT: adding the detail that Fuchsia's IPC lang ecosystem has autogen features due to its standardization.

Yeah, it's brand new as far as you would consider in practice (they use existing libraries and the like).

The answer is not much time. The real question is how long to develop good quality drivers for a give platform (say, an x64 laptop)? How long to port/develop applications so that the OS is useful? How long to convince OEMs, app developers and such folks to start using your brand new OS? It's a bootstrap problem.

The joy of having a properly implemented capability system is that, well, you can create arbitrary capabilities.

You don't need to give a process/component the “unrestricted network access capability” -- you could give it a capability to eg “have https access to this (sub)domain only” where the process wouldn't be able to change stuff like SSL certificates.

EDIT: and to be clear, fuchsia implements capabilities very well. Like, apart from low-level stuff, all capabilities are created by normal processes/components. So all sorts of fine-grained accesses can be created without touching the kernel. Note that in fuchsia a process that creates/provides a capability has no control on where/to who that capability will be available -- that's up to the system configuration to decide.

Yep. It's anyone's guess what's been going on there. Lots of theories out there. IMO Google doesn't consider this a high priority and the cost to keep the development going on considering the engineers working on it is low enough.

Also note that swapping the core of a widely used comercial OS like AOSP would be no easy feat. Imagine trying to convince OEMs, writing drivers practically from scratch for all the devices (based on a different paradigm), the bugs due to incompatibility, etc.

It's technically a general-purpose OS. They had a workstation build target sometime ago which was used for the desktop use-case. They've shipped only for an IoT device so far (Google Nest Hub).

Main goal would be to replace the core of AOSP considering the main work that's being done, but it seems like Google isn't convinced it's there yet.

> On mobile devices, the proprietary drivers are in user space.

So, the situation would stay the same regarding that.

> The drivers will probably be back in the kernel

Manufacturers putting drivers back into the kernel would be a step back for them since it would be more work than just using them in user space given there is a stable driver API.

> and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space

I think people forget that Fuchsia is more than the kernel. It comprises more things than Linux. Being based on a microkernel design, the kernel part represent just a small surface of the whole 'system interface'. All the rest is in the user space. The Android (platform) part of the system will be layered on top of this 'system interface', and will not define all the user space per se alone. This 'system interface' is well defined and documented [0] and, similarly to the Android (platform), they also have a CTS that tries to ensure that [1]. For example, the software layer implementing the product representing the Nest Hub is outside the Fuchsia platform, as will be with the Android (platform). So, a manufacturer implementing a particular feature inside the kernel, or in other component like drivers, will still result in its device having a 'system interface' at least compatible with the oficial Fuchsia one; if it's not, but offers something more, we all would be in the same situation where the provider bundles that features in closed blobs anyway.

I think Fuchsia's decoupled system architecture will make using an alternative user space not a big problem, if not even easier that it is with Android based systems.

[0]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0... [1]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

But that seems to be exactly what they are doing. They're surely porting the Android runtime to Fuchsia, or even already ported it.

Remember there are Android APKs containing native Linux banaries (made with Android's NDK) that you should be able to run. That is the whole main point of Fuchsia' starnix. I think this is even mentioned on starnix's RFC.

Isn't this growth pattern a straightforward consequence of disorderly growth?

When microorganisms divide, the children "appear" in the same location. Our species growth dynamics kind of has this same property in that it's easier to build something closer to the already established region than far away.

So, in the end, looking from far away, the growth pattern is the same.

"And you exist only because of us" - Neo

I think this pattern of exponential growth of human beings is a curse of their intelligence. All other animals end up being controlled by these large ecosystem dynamics because they can't adapt and/or do group work sufficiently. Species with this property are easily influenced/controlled by large scale dynamics.

Maybe, a species with more intelligence than us wouldn't grow so fast and unorderly because they can see the future consequences of their own dynamics more easily. We just happen to not deal with large temporal scales very well.

This can be done with a proper capability system.

Outch! Thanks for the refs.

Thanks! I searched for this rewritten version and couldn't find anything.

Functionally it's the same. The functions called could live in the kernel (a system call), in the process itself or in a shared lib loaded into the process address space.

Interpreting bytes is message passing and this communication happens through the handle/descriptor to the file/object/whatever. As above, this handle could have come from the kernel, another process or the executing process itself (the process opened some file or whatever).

I think the message passing version happening through a handle can be more versatile as you could send this handle over to another process. Could copy it and distribute it to other processes in a easier way than injecting/changing a (presumably C ABI) into a process address space.

IMHO this is the main objective. They even mention in the RFC the case of running Android native code.

This wouldn't solve the problem. It would push the problem one level lower.

> In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them

Yes, and then you would have to own a component in some route that received the driver exposed capability. Either way, the tight sandoxing and compartmentalization of functionality make things difficult.

There's an example of analysis here: https://blog.quarkslab.com/playing-around-with-the-fuchsia-o...

When looking more closely on Fuchsia architecture you might well be back into OS design obsession. As the kernel is, IMHO strongly based on a microkernel design, the OS APIs presents itself as userspace APIs. They are in fact, defined by what the userspace implements. And there is a lot of freedom on how to implement this API.

The majority of microkernel based OSes just implement these APIs to emulate UNIX APIs and that IMHO is a waste of potential but understandable in order to be backward compatible and not have to develop whole new userspace applications from scratch.

But I really like Fuchsia's take on the design of this userspace and the way the 'capability security model' is integrated into it. The amount of APIs built into the base 'Fuchsia platform' really blurs the line between and OS and a stack with OS plus essential services. Today, IMHO, things like automatic updates, software distribution, crash reports, and other low level application centric facilities should really be provided by the OS and that is done in the base Fuchsia platform.

That is true.

I think this is the greater challenge now for Google. A system being very well designed and implemented only attracts enthusiasts and people like that with free time. Even the 'better security' aspect doesn't convince the majority of developers. For general usage in IoT and primarily in smartphone/tablet devices, Google would have to:

1. Port ART together with all of Android's public facing APIs to Fuchsia. Evidence says they are doing it, at least for Android ART. As people say, "there's no way without Android app compatibility"...

2. Convince OEMs to switch to Fuchsia platform instead of Linux. That I believe is under way with project Treble, or at least has a path for a possible solution. And Fuchsia's architecture solving Linux big pain points would be a strong argument in convincing OEMs to switch. Woundn't be easy though as drivers would have to be (re)developed or some bridge would have to be built.

With above done, developers would have a push to develop targeting Fuchsia natively. Then Fuchsia's better system architecture together with security advantages would be more strongly perceived by end developers.

If Google managed to develop some new fancy end product on top of Fuchsia that got traction, then that process would be a lot easier for them...

> for malicious software you’re just looking for a process handing out high privilege handles In the end, that is true.

But the thing is the way Fuchsia's implementation of the 'capability security model' is done. The capabilities a process (or, a 'component' in Fuchsia's model) use/consume are explicitly given to it. And this scheme is implemented in a way that is easy to see and account for where/from these capabilities are going to/from. An process can do nothing that is not provided by the capabilities it got during creation.

Of course, components might be buggy/malicious and leak capabilities. But the security holes bottleneck in this capability routing scheme, so even with buggy/malicious components, it's much easier to audit and fix. And from an attacker perspective, it's much harder to reach a component given the routing path of capabilities that it's received.

I see it as better way of developing a product. Or actually, a foundational system, if Fuchsia really ends up becoming something like that. You see, lots of things that today are fundamental were just "developed organically", and that is OK because people never tought that it would end up being what it is.

Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "develop it, make it work, and ship so not to delay the schedule/budget so much". And that is OK too given that companies just want to develop a product and don't have lots of time, budget and resources... But, as things are in software engineering, that model doesn't produce as good a piece of software as it would with more iterations and refactoring seeking the best software model and implementation. In the end, that results in greater issues issues than what was really needed and the backward compatibility hinders an actual solution. But Fuchsia being meant as a foundation, cannot be developed like that. Like a product that "just works". It would end up being just another bad designed (and chances are, bad implemented too) system based on concepts of the beginnings of computer industry that doesn't necessarily apply for today's systems.

As I've loosely accompanied Fuchsia's development, they've done a lot of early bring up work just so that other parts of the system could be developed. And that is expected because they developed arguably almost everything from scratch. You cant expect ending up with really great system design and implementation just from these first iterations. Then, with the experiences from that, they've done lots of refactorings that refined system's abstractions, APIs and implementation. And, if they are serious about Fuchsia being a good foundational system, they have to solve these left over from the early development.

This resumes the desktop app development drama.

I hope Flutter will solve that