Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How sandboxing works in Fuchsia

fuchsia.googlesource.com

Post reply on HN
Print view View original

151–160 of 172 posts

Re: How sandboxing works in Fuchsia

#151

Post by unix1 »

DannyBee wrote: post #65
43224gg252 wrote: post #64

Earlier quoted context omitted.

How do you figure? I see you keep posting that Linux can run proprietary binary blobs. No one is arguing against this. The argument is that these binary blobs will ship by default inside fuchsia OS and that the creators of fuchsia have chosen a license that has no provisions against this. You can't change the Linux kernel and then close the source and sell it. That's why the GPL is much better for users and other lic…

First, it's already been done. Like, all the time. People already do this with Linux and ship it in user devices. Either you believe such a thing is GPL compliant, in which case, yay, they already could do it. Or you believe they are violators, but nobody has been able to stop them, in which case, that falls into my "in practice, ...". Because in practice, it has not stopped them Either way, nothing has changed :) As…

It would be hard to argue the inverse hypothetical outcome, but I do think that licensing (GPLv2) had a significant role in where Linux is today. It is precisely because the license obligates the distributors to share the code that made the whole a better software and a more attractive platform to contribute to. In fact, most contributors, big and small, work with the upstream to streamline their contributions. Having to share the source has worked out well for both programmers (individuals, companies) and end users in the long run.

Stating that there are some number of cases of GPL violations that haven't been enforced or are in the gray area is not a logical base for the argument that the idea of having to share the source code should be abandoned. In fact, history shows otherwise - that Linux has had more success (as measured by uptake globally) than any other non-GPL open source kernel ecosystem.

Similarly, just because there may be people who can find loopholes in certain well-intended laws and regulations is not a good reason to abandon their intents. Instead, the questions should be - can we keep these intents and fix the loopholes or make the enforcement more straightforward? I think Google could, but maybe it's not in their immediate interests, one of which may be closer to - how do I upgrade the kernel without recompiling that other stuff.

Re: How sandboxing works in Fuchsia

#152

Post by jstimpfle »

josefx wrote: post #150
jstimpfle wrote: post #138

Earlier quoted context omitted.

Typing assistants mostly suck. And it's not only about the typing. You still have to read the names or process them otherwise. "Self-explanatory": That doesn't exist. You always need context. The art is to use just enough verbosity. Say the interesting and distinctive things. Not the boring things that can be easily figured out (Singleton, Factory, boring. What kind of component?)

> You still have to read the names or process them otherwise. And how long does it take you to parse "svc" vs. "service" in average microseconds per day? With old unix there was at least a need to keep memory use low, today we are only limited by Microsofts MAX_PATH.

What I said was about typing assistants and about efficient naming. But after reading the article, I would make a point for svc being not a bad decision. Ask any otherwise uninitiated programmer what meaning she would associate with "svc" or "service". You don't get anything useful out of either without additional context. Even

    /svc, which is a bundle of services from the environment in which the application runs.
is not really enough for me to understand what this is about.

Now, since this is a distinctive concept that comes with a learning cost, why not make a short name like "svc" for it? That is actually more distinctive than "service". And you save 4 characters every time you read or write it.

Re: How sandboxing works in Fuchsia

#153

Post by naasking »

Except you can't sandbox or virtualize the clock because mx_time_get() doesn't require a handle, which makes timing attacks easier.

You also can't sandbox event and channel creation for the same reason. It looks like these can also DoS the kernel. In general, any operation you can perform without a handle tends to be subject to DoS and you can't virtualize it. They're also subject to a different access control policy than the rest of the system which is based around handles.

And it's not really necessary. Just reserve the first few handles in a process table for a clock handle, a channel constructor/factory handle and an event constructor/factory handle, and now these operations can be fully virtualized and they aren't subject to DoS because they can be rate-limited or at least traced back to specific handles which can be revoked.

Without tracing every operation to a handle, you have to pollute your model with more infrastructure to track this information, as with channels and events in Fuschia.

[1] https://fuchsia.googlesource.com/magenta/+/master/docs/conce...

Re: How sandboxing works in Fuchsia

#154

Post by geofft »

tonfa wrote: post #127
geofft wrote: post #78

Earlier quoted context omitted.

> If you were to bug the SFLC/others, you'd see Google is, in fact, quite happy releasing kernel changes, and is pretty much one of the only companies that has either pushed vendors to open source drivers, or, in a number of cases, rewritten proprietary android drivers as open source just so it can release them! "Happy" is a funny word though. Google is legally obligated to release kernel changes and legally forbidde…

> "Happy" is a funny word though. Google is legally obligated to release kernel changes and legally forbidden from shipping kernels that incorporate other people's GPL-incompatible drivers. I suppose the OP was also talking about the changes done to improve linux for datacenter workflows, afaik there is no obligation to release the changes there.

That's a good point, but the Linux development community also has a practice of very aggressively refactoring Linux internally / breaking internal APIs whenever it makes sense, and they update all code that's in Linux mainline but don't provide patches or migration guides for anyone else. I've definitely seen the perspective that this is not only done for technical reasons but to put pressure on people to incorporate their code into mainline when possible.

Newer versions of Linux get steadily better at performance, so it seems likely to me that Google is primarily incorporating their changes upstream to save effort over maintaining a local fork (and not risk that fork getting out-of-date), and not so much because they find that open-sourcing their code is inherently worth doing.

Re: How sandboxing works in Fuchsia

#155

Post by Apofis »

bitmapbrother wrote: post #69

Here are a couple of YouTube video's showing the early stages of the Fuchsia UI: https://www.youtube.com/watch?v=MPhQ-8fXft8 https://www.youtube.com/watch?v=Vu0VGj5xf60

Looks like they are already pretty far ahead. Wonder if they plan to replace both android and ChromeOS with Fuchsia.

Re: How sandboxing works in Fuchsia

#156

Post by mee_too »

theDoug wrote: post #10
mee_too wrote: post #9

Earlier quoted context omitted.

They can't be louder and prouder about it, because they know at one point they'll have to compromise it so that Google own apps can track the user.

Oh damn, you broke the triple secret NDA. Next people will find out that Fuchsia is the color faces need to get before the project is revealed to be a conspiracy theory generator. There are plenty of important reasons for this project, that plenty of people in the past have already made note of. If the one you're going for, already, is some ad/user tracking platform, you're purposely attempting to narrow the capabili…

Sorry, I wasn't aware there's triple secret NDA on the fact that Google's main business is advertising...

Re: How sandboxing works in Fuchsia

#157

Post by kyrra »

naasking wrote: post #153

Except you can't sandbox or virtualize the clock because mx_time_get() doesn't require a handle, which makes timing attacks easier. You also can't sandbox event and channel creation for the same reason. It looks like these can also DoS the kernel. In general, any operation you can perform without a handle tends to be subject to DoS and you can't virtualize it. They're also subject to a different access control policy…

I'd be interested if this has been brought up with the dev team via IRC, mailing list, or some other medium so they can explain their reasoning?

Re: How sandboxing works in Fuchsia

#158

Post by armitron »

bitmapbrother wrote: post #96
armitron wrote: post #39

Earlier quoted context omitted.

Linux is a disaster security-wise (look at how massive things like grsecurity are) and that won't change anytime soon. Android has inherited all of that and it's by far the shittiest mobile OS out there in terms of how easy it is to own. It makes sense that Google would like to move away from Linux given how important mobile security is and will become in the future. They certainly have the resources to get it right,…

>Android has inherited all of that and it's by far the shittiest mobile OS out there in terms of how easy it is to own. Then why don't you try? Google has $200,000 USD waiting for you to exploit a fully patched Pixel. Or are you too rich to make it worth your while? If you're going to say something that silly at least have the technical prowess to walk the talk.

First, is there a point that you are trying to make because I didn't see any.

Second, 200k USD for a vulnerability of such caliber is peanuts.

Third, you must have missed this: http://blog.trendmicro.com/results-mobile-pwn2own-2016/

Re: How sandboxing works in Fuchsia

#160

Post by naiveattack »

negus wrote: post #100

"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.

Another positive of short names is that commonly used names occupy less screen real estate
Post reply on HN