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

71–80 of 172 posts

Re: How sandboxing works in Fuchsia

#71

Post by awqrre »

mythz wrote: post #6
pjjhdog wrote: post #2

So I'm not clear what the puropse of fuchsia is. I understand it's an os which may replace android or chomeos but why the move away from linux based systems? Both are open source platforms.

It's not clear because its purpose has not been made public. Google has the resources to undertake developing a new OS, which they obviously believe will have benefits over being based on Linux like ChromeOS is. Being free of legacy constraints gives them the freedom to explore better ways to achieve they're objectives, e.g Security and UI performance.

security and UI performance... color me doubtful...

Re: How sandboxing works in Fuchsia

#72

Post by solatic »

DannyBee wrote: post #24
catern wrote: post #8

Earlier quoted context omitted.

>open source platforms Part of the motivation is certainly to get away from the GPL requirements of using Linux, so that Google and its partners can release products to users that have proprietary modifications to the kernel, without giving those same users access to the source code of the kernel. That would of course be a disaster for user autonomy and freedom, but why should Google care about that... Edit: This isn…

"Part of the motivation is certainly to get away from the GPL requirements of using Linux," Certainly why? I know, in fact, this is pretty much a non-consideration, so i'm really curious what makes you believe it is. In fact, the fuchsia kernel is completely open source, so ... 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 co…

> why?

Because cloud providers have started to build their own hardware to eke out performance advantages versus other cloud providers. It's not a far stretch to conclude that Google will prioritize its kernel's development for its proprietary hardware and not have to release any of the secret sauce to the public.

Re: How sandboxing works in Fuchsia

#73

Post by 43224gg252 »

throw2016 wrote: post #53

Android for all practical purposes is as good as a closed ecosystem with apps tied to closed source Google services and the inability to run Linux on your Android phones. This kind of lip service and self serving tip toeing around the spirit of open source in many ways does more harm to open source than closed source. How is it that devices drivers that work on Android perfectly are not available for use on Linux? Wh…

Don't know why any hacker would argue against you, but for some reason I see people on HN making excuses for companies like google and Microsoft almost everyday.

These companies don't like Linux or FOSS, they just want to take advantage of it to make a profit. Google uses Linux to make the most popular OS in the world, and gives almost nothing back compared to what they could be giving back. "b.. but google is one of the biggest contributors to the Linux kernel" - it doesn't matter when their contributions don't serve the greater community. Even if they can't get some of their changes sent upstream, they could still provide patches for users for things like power management.

Microsoft is no better. They say they love linux, but you don't see directX coming to linux. You don't see a windows sub-system coming to Linux (even though they were able to code up a Linux sub-system in a matter of months). Why not open source Visual Studio?

They just don't give a shit about Linux.

Re: How sandboxing works in Fuchsia

#74

Post by btrask »

abarth wrote: post #34
stefankomatsu wrote: post #28

Earlier quoted context omitted.

Thanks. How about virtualization? Using an example from the doc, if your child process accesses "/dev/class/framebuffer", can you intercept its communications? Can a process create a custom sandbox and run, say, AppMgr with limited permission to limit the permissions of all apps it manages?

> Using an example from the doc, if your child process accesses "/dev/class/framebuffer", can you intercept its communications? Yes. When creating the namespace for the child, the parent can map names to what whatever communication channels it chooses. If the parent wants to interpose on the child's access to "/dev/class/framebuffer", the parent could map that name to a channel that leads back to the parent. > Can a…

Thank you for taking the time to reply, despite the sea of low quality comments on this HN thread.

Re: How sandboxing works in Fuchsia

#75

Post by pgeorgi »

catern wrote: post #17
djsumdog wrote: post #16

Earlier quoted context omitted.

Companies are embracing open source these days, but not the GPL. We see that with gcc and clang, or in the way MacOS uses older versions of tools just to avoid GPLv3: http://penguindreams.org/blog/the-philosophy-of-open-source-... The OSS utopia pushed in the the 1990s, with tools like Gimp being one day comparable to Photoshop, never really happened.

OK, but that's irrelevant. Kernels are an entirely different class of thing. I'm fine with permissive licenses for higher-level software such as clang or GIMP. But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. It's already painful to compile and run Android from source. Fuschia will make it just impossible.

It's a microkernel, somewhere in the middle of the spectrum. Not as extremly reduced as L4, but not the heavyweight that Mach is, either.

The kernel will probably be the one component vendors (chipset or OEM) won't ever feel the need to touch (except for new architectures), since they can put everything in userland processes that they want to keep hidden. Not even the GPLv3 would help there.

Re: How sandboxing works in Fuchsia

#76

Post by geofft »

kjksf wrote: post #48
themacguffinman wrote: post #14

Earlier quoted context omitted.

Fuchsia uses a microkernel (Magenta) which is more secure and technically elegant, but usually comes at the cost of performance. Google's position as the primary/sole developer of Fuchsia also gives them the control to build the OS in commercially lucrative ways that don't necessarily earn the approval of the Linux open source community (programming shortcuts, proprietary/non-GPL extensions, etc).

I'm guessing that you think it's a bad thing but I don't quite understand your position. Is it a new standard that if company develops code, they are morally required to seek "approval of the Linux open source community" ? Are we applying this standard only to Google, or all companies? If writing and open-sourcing code under permissive license is bad if it's done without "approval of Linux open source community", the…

I don't think that comment was expressing a clear opinion either way, just stating that as long as Google is basing their software on Linux they are definitely legally obligated to follow certain rules (e.g., no direct linking of proprietary drivers provided by a vendor) and vaguely politically obligated to follow others (e.g., there's a fair bit of C++ in Magenta; adding C++ to a fork of Linux is technically straightforward but would upset people and also make it hard for patches to your fork to go upstream).

Re: How sandboxing works in Fuchsia

#77

Post by catern »

DannyBee wrote: post #59
oconnor0 wrote: post #46

Earlier quoted context omitted.

You gain the knowledge that a device running Fuchsia is running code that's publicly available.

No, you actually don't. You gain knowledge that some of the code is maybe publicly available, just like linux. The rest, however, is often still kept secret, legally or not, and has been since time immemorial. You don't have to take my word for it though, go ask bradley kuhn if he thinks that vendors have a tendency to comply with the GPL for the kernel :)

Consider what happens if you're wrong. What happens if the GPL actually is the reason why Linux has such wide open-source hardware support? Then say goodbye to hacking on Fuschia on your own hardware...

I'm not willing to take that risk.

Re: How sandboxing works in Fuchsia

#78

Post by geofft »

DannyBee wrote: post #24
catern wrote: post #8

Earlier quoted context omitted.

>open source platforms Part of the motivation is certainly to get away from the GPL requirements of using Linux, so that Google and its partners can release products to users that have proprietary modifications to the kernel, without giving those same users access to the source code of the kernel. That would of course be a disaster for user autonomy and freedom, but why should Google care about that... Edit: This isn…

"Part of the motivation is certainly to get away from the GPL requirements of using Linux," Certainly why? I know, in fact, this is pretty much a non-consideration, so i'm really curious what makes you believe it is. In fact, the fuchsia kernel is completely open source, so ... 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 co…

> 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 forbidden from shipping kernels that incorporate other people's GPL-incompatible drivers.

It is definitely true that there are other companies who aren't happy to follow the law, from the Allwinners who just don't care to the VMwares who see the law differently to the Samsungs who seemingly honestly didn't realize what the law said. But given that Google is a large, relatively old company based in the US, you can't extrapolate very much from them being willing and even happy to follow the law in a straightforward fashion. It just means they know what the law is. It doesn't mean they like the law, or that they like the situation that caused the law to apply to them.

The explanation most consistent with the facts is that Linux being under GPLv2 allowed Google to get Android to market quickly with a robust, portable, well-designed kernel, and the things we like about free software (ability to hack on it and modify it, likelihood of gaining others' improvements) aligned with their business needs at the time, as a new entrant in a difficult market—but that Google, as a company, has no particular idealism regarding strong copyleft.

If they want to ship proprietary drivers from other vendors, they can't legally do that with a GPL kernel, and it's implausible to believe that they'll do so anyway and wait to get sued and try to play lawyer games. The simplest path forward is to keep making GPL reimplementations of those drivers for now... and to start making a non-GPL reimplementation of the kernel for the future.

If anything, the fact that they have been pushing vendors to open-source their drivers or rewriting proprietary drivers shows just how much they would have a business interest in a Linux-quality kernel that isn't under the GPL.

Re: How sandboxing works in Fuchsia

#79

Post by vertex-four »

catern wrote: post #68
DannyBee wrote: post #55

Earlier quoted context omitted.

The real answer is because the people involved believe the licenses they are using are even more free. IE they do not subscribe to the FSF's ideology. It's their software, so they get to choose. It's like arguing NetBSD should use the GPL license. As for why it generally doesn't make sense to use the GPL for this: Even the FSF doesn't think GPLv2 is the right license for linux? GPL'ing linux hasn't prevented any of t…

Sure. So why not GPL (v3) it anyway, if the GPL is so ineffective? After all, what you're telling me in your posts is that Google wants vendors to contribute back, but it can't force them. I don't want vendors to be able to create proprietary extensions. You claim Google also doesn't want vendors to create proprietary extensions. So: - If the GPL is effective, why not use it? - If the GPL is ineffective, it can't pos…

It sends a positive signal to a group of people who really don't matter - the very small minority of users who like open source and aren't already placated by AOSP existing - but a negative one to people who do - their vendors.

Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel. This is better than doing exactly the same thing as before which didn't work. It solves a practical problem (being unable to upgrade your phone's OS) through technology rather than licensing.

Re: How sandboxing works in Fuchsia

#80

Post by catern »

pgeorgi wrote: post #75
catern wrote: post #17

Earlier quoted context omitted.

OK, but that's irrelevant. Kernels are an entirely different class of thing. I'm fine with permissive licenses for higher-level software such as clang or GIMP. But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. It's already painful to compile and run Android from source. Fuschia will make it just impossible.

It's a microkernel, somewhere in the middle of the spectrum. Not as extremly reduced as L4, but not the heavyweight that Mach is, either. The kernel will probably be the one component vendors (chipset or OEM) won't ever feel the need to touch (except for new architectures), since they can put everything in userland processes that they want to keep hidden. Not even the GPLv3 would help there.

Yes, indeed, that makes it even more distressing that they didn't bother to license even the core of the system with the GPL. It sends a signal that they really completely don't care about the freedom for users to modify the software and run it on their own hardware.
Post reply on HN