Comparing Fuchsia components and Linux containers [video] • Hacker News Board

Re: Comparing Fuchsia components and Linux containers [video]

#91

Post by ggm » Tue, Mar 04, 2025, 5:02 AM UTC

supriyo-biswas wrote: post #81

ggm wrote: post #74

Earlier quoted context omitted.

Yes. And without over stating it, iOS is an amazingly robust, very secure OS. it has high trust and low trust models, a secure zone, special purpose hardware and an operating system designed around minimum access rights models which manages to keep going, despite app authors worst intentions. At one level, it proves the model. The shame is that Mach otherwise has kind of not taken off. Gnu the OS was going to be Mach…

I'd have to disagree -- the lack of OS-level sandboxing primitives such as seccomp-bpf and SELinux[1] means that exploits happen rather regularly in iOS rather often ([2], among others). [1] https://source.android.com/docs/security/app-sandbox#protect... [2] https://www.csoonline.com/article/3811322/iphone-users-targe...

Not to deny that, but it didn't (for example) break the Secure Enclave. Key exfiltration didn't happen AFAIK.

Re: Comparing Fuchsia components and Linux containers [video]

#92

Post by intexpress » Tue, Mar 04, 2025, 5:34 AM UTC

tbodt wrote: post #50

fishtoucher wrote: post #39

Earlier quoted context omitted.

Fuchsia may not be outright dead, but it's definitely on life support and would've been killed a long time ago if senior people at Google weren't personally backing it. It had great foundations but without a concrete use case or product development was constantly pulled in different directions. It seemed like every year a new niche for Fuchsia was on the horizon, 6 months of development time would be dedicated to it,…

I work on Starnix and I've never heard of anything meant to replace it. What are you talking about?

They might be thinking about POSIX Lite losing favor

Re: Comparing Fuchsia components and Linux containers [video]

#93

Post by __MatrixMan__ » Tue, Mar 04, 2025, 5:35 AM UTC

vlovich123 wrote: post #76

bestorworse wrote: post #15

Earlier quoted context omitted.

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…

Ok, give me access to a subdomain I control and I’m phoning home and there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal - and even if you tried to do path restrictions, I can arbitrarily side-channel phoning home with normal access (which by the way you can’t unless you’re sniffing the encrypted HTTP session somehow). Also imagine you are trying to run a browser. It’s implicit…

I imagine one could create a capability such that the app gets a way to shove bits in and a way to get bits out, but no knowledge of the IP address or anything like that. A phone (or set of phones) that are already connected and have no keypad.

Re: Comparing Fuchsia components and Linux containers [video]

#94

Post by __MatrixMan__ » Tue, Mar 04, 2025, 5:38 AM UTC

dekhn wrote: post #26

bestorworse wrote: post #15

Earlier quoted context omitted.

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…

In my experience lots of folks simply won't work with capability systems no matter how good the implementation is or whatever level of security and configuration granularity is provided. For many people it's just extra friction in search of a use case.

I'm just hearing about capability systems today, so your experience is undoubtedly richer than mine, but I'd estimate that we're just scratching the surface re: ways to harm somebody by making their tech behave in surprising ways.

Maybe once those harms are all grown up, we'll find that fancier handcuffs for our software is worth a bit more than "just extra friction."

Re: Comparing Fuchsia components and Linux containers [video]

#95

Post by stouset » Tue, Mar 04, 2025, 5:54 AM UTC

vlovich123 wrote: post #89

surajrmal wrote: post #86

Earlier quoted context omitted.

While there is no direct UX exposing this to an end user, it hypothetically be used as the basis of such UI. The parent of a component gets to ultimately decide what capabilities it routes to a child component. It's not like landlock where the process decides to sandbox itself after it's already running. Similar to a user constructing a VM to run a hypothetically malicious program, the same could be done much more li…

All I said is that in the general case you’re not going to be able to rely on capabilities to do things like prevent phoning home or otherwise doing things you semantically define as harmful. This isn’t a UX issue - this is a technical issue. Capabilities, outside from very rare circumstances, can’t enforce it no matter how you structure this. The only rare circumstances is if you can restrict access to servers that…

Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way.

Sure, a web browser that needs to open arbitrary network connections can be built to phone home. But nearly none of the components it’s built out of can. The image decoding and rendering libraries can’t touch the network, the rendering engine can’t touch the network, and nor can the dozens of other subcomponents it needs to work.

Your installed editor extensions can’t phone home even if the editor itself can. Or perhaps even the editor itself wouldn’t be able to, if extensions are installed out of band.

Your graphics driver vendor can’t phone home, your terminal can’t phone home, and on and on and on.

A solution doesn’t have to be perfect for it to be an improvement, so stop acting like it does.

Re: Comparing Fuchsia components and Linux containers [video]

#96

Post by throwaway48476 » Tue, Mar 04, 2025, 6:19 AM UTC

kyrra wrote: post #66

throwaway48476 wrote: post #58

Earlier quoted context omitted.

The point of linux is to upstream drivers so that devices just work.

The problem is the release cadence, especially around mobile devices. Driver packages for them tend to be worked on right up to shipping, because they are developed in parallel with the hardware. Android using the absolutely most head or tip version of the Linux kernel sounds like a QA nightmare of its own. Mobile SOC has to have everything to start up the phone, as there is no bios like system that the driver is kin…

In PC land linux driver support is not always day one as they are working on the drivers up to and sometimes after the release. Somehow the mobile vendors aren't capable of this.

Re: Comparing Fuchsia components and Linux containers [video]

#97

Post by Jyaif » Tue, Mar 04, 2025, 6:25 AM UTC

vlovich123 wrote: post #76

bestorworse wrote: post #15

Earlier quoted context omitted.

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…

Ok, give me access to a subdomain I control and I’m phoning home and there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal - and even if you tried to do path restrictions, I can arbitrarily side-channel phoning home with normal access (which by the way you can’t unless you’re sniffing the encrypted HTTP session somehow). Also imagine you are trying to run a browser. It’s implicit…

> there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal

Of course you can!

With capabilities you can tell a program: "if you want to communicate with the external world here's the only function you can use :

`void postToMySubDomainSlashWhatever(char* payload, size_t size)`

Re: Comparing Fuchsia components and Linux containers [video]

#98

Post by shocking63 » Tue, Mar 04, 2025, 6:29 AM UTC

saghm wrote: post #29

mdhb wrote: post #9

Earlier quoted context omitted.

I think the lack of public information about their future plans for the project combined with the “killed by Google” meme got smashed together here and that is actually a really common perception but also one that is completely made up out of thin air. It has been under heavy heavy development for many years now. The fact that they are now starting to talk about it publicly now is probably a sign that they are lookin…

I think the problem is that "lack of public information about their future plans" is hard to differentiate from "no future plans exist". For a company that's in the past been known for their willingness to go for low-likelihood but high impact "moonshot" projects and seemingly open with some of their long-term plans (like everyone knowing that they were working on self-driving cars years before self-driving became a…

To me, one of the best features of ChromeOS is that it runs both Android and Linux. I have a number of telescopes that are controlled via Android apps, and being able to run astronomy processes apps like siril on the same platform is wonderful.

Re: Comparing Fuchsia components and Linux containers [video]

#99

Post by raggi » Tue, Mar 04, 2025, 6:42 AM UTC

spankalee wrote: post #70

tmp-fuchsia wrote: post #36

I haven’t watched this talk, but I worked on Fuchsia from the start (I’m no longer at Google) and want to clear up some common questions and misconceptions: 1. Fuchsia is a general-purpose operating system built to support Google’s consumer hardware. 2. It’s not designed to compete with or replace Android. Its goal is to replace Linux, which Android is built on. One big challenge it addresses is Linux’s driver proble…

I was never that close to the Fuchsia project, but knew quite a few people who worked on it. My understanding from them was, as much as I can remember it now, something like: 1. That yes, Fuchsia was originally intended, by at least some in senior leadership on the team, to replace both Android and ChromeOS. This is why Fuchsia had a mobile shell (or two?) at one point. 2. The Android team wasn't necessarily on board…

You got the high drama stories with the timelines re-arranged to fit the narrative :D

Fuchsias underlying goals are to be a great platform for computing. This is distilled in its current incantation into a short tagline on fuchsia.dev: simple, secure, updatable, performant.

The details of how when and where Fuchsia might fit / gets exercised are nuanced and far more often about other factors than those which make great stories. Maybe there will be some of the good stories told one day, but that'll need someone from the team to finish a book and take it through the Google process to publish :D

In the meantime, here's Chris interview: https://9to5google.com/2022/08/30/fuchsia-director-interview...

Re: Comparing Fuchsia components and Linux containers [video]

#100

Post by raggi » Tue, Mar 04, 2025, 6:47 AM UTC

ggm wrote: post #32

I wish message passing and capabilities based OS had taken off stronger in the 80s because I sometimes feel like there are design goals and approaches latent in what we do now, which we could have been advanced in before now, beyond research models.

I don't think they were as tenable then as they are now.

When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide or simply aren't worried about latency increases on that scale.

A counter case though, as an example, is building the system using a traditional C-style build system that basically spams stat(2) at mhz or these days ghz speeds. That's basically a pathological case for message passing at the filesystem layer, and it's a good example of why few microkernels which aimed at self-hosting made it over the line. It's probably possible to "fix" using modern techniques, but it's much easier to fix by adjusting how the compilation process works - a change that has major efficiency advantages even on monolithic kernels. Alas, the world moves slow on these axes, no matter how much we'd rather see everything move all at once!