How sandboxing works in Fuchsia | Hacker News Reader

How sandboxing works in Fuchsia

fuchsia.googlesource.com

243 pointsbtrask167 comments

"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.

Fully agree. No need for the shitty parts of UNIX to be in a new OS. Use full names. I've never used OSX/macOS but I do admire how they've gone about doing the whole UNIX thing, there seems to actually be some standard to it unlike the LSB and from what I gather to uninstall a program you just delete it's directory. Try doing that on literally any other mainstream OS!

Doesn't always work. Lots of apps end up leaving data Lyon around in Library, and some of the "big name" apps require a full installer and uninstalled, along with admin privileges (see adobe, autodesk, Microsoft)

Unfortunately not. You also have to delete from ~/Library/Caches at the least. If you want to delete the user data then you will need to delete from ~/Library/Application Support, Preferences, Containers, etc, etc...

I agree, I would much prefer short but full names (lowercase).

svc is especially cringy.

svc is very very common in Solaris based OSes.

Interesting. No reason to emulate mistakes though.

Does it have creat?

Given how they named everything else it's probable 'cre'.

skng th mprtnt qstns n mssng vwl t a tm

When programming, variables should be self-explanatory. However, things you re-type constantly (copy -> cp, remove -> rm, variable data -> /var) are fine to abbreviate with logical abbreviations.

I don't have trouble understanding dev, /svc and /pkg because they're already common abbreviations. The gn and PA_VMAR_ROOT I'd have to look up, but if I'm using it constantly, I don't mind needing to learn. I mean, I needed to learn to use Vim, too, and now I'd never want anything else.

I'd rather have typing assist than abbreviated names. To be self-explanatory, it's called ISingletonComponentFactory, but that doesn't mean I type all of that out.

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?)

Wait so you think "svc" is easier to read & process than "service"? What planet are you on?

It is, depending on how often it's used and how cohesive the implementation is. Anyway "service" is one of these terrible non-descriptive names. Is this some kind of abstract datatype? A reference to a system daemon? Or just a data value processed by business logic? You need context anyway.

> 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.

I'm hoping Fuchsia isn't being designed as an OS where you constantly have to type file paths.

Also you rarely need to type full paths even on Linux. I'm nearly all shells you can press tab to autocomplete them. I.e. you press "/d<tab>" and it will change it to /dev. That's exactly the same for dev and devices.

There's really no reason for short confusing names other than laziness and jargon-based egotism.

GoboLinux had an amazingly awesome alternative file system layout https://en.m.wikipedia.org/wiki/GoboLinux

Another positive of short names is that commonly used names occupy less screen real estate

I agree.

People who don't understand need to know that big / Retina displays are not accessible to people who, let's say it, are poor immigrant geniuses who only have access to a 1024*768.

Terminals are 80x24, and even system administrators need to have multiple terminal windows open.

Let's not forget that a lot of people learn through books, so print real estate is an issue as well.

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...

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?

I'm sure they're at least familiar with past capability operating systems given their design. Shapiro covered many of these issues in his EROS work.

The creation syscalls operated under the execution constraints of the Job in which your Process is contained. The APIs aren't fully landed, but it will (very soon) be possible to create Jobs where-in none of the kernel object creation syscalls will be allowed. You can think of the creation syscalls as taking an implied handle to the Process's Job, which is an "object factory" similar to what you suggest.

There are mechanisms in the works to allow the VDSO to be customized per-Job along similar lines (providing a way of addressing mx_time_get(), etc). mx_time_get() is actually provided entirely in userspace in the default VDSO, but of course we want to allow for runtime environments where we don't allow direct access to the TSC or equivalent.

There aren't any "known" handles in the Magenta design, as handles are not small integers nor aggressively reused (as fds are in unixen). The intention there is to make use-after-free errors with handles more difficult and to make guessing what handles a process has harder.

It's definitely not a "pure" capability design or a "pure" (read/write/exit) microkernel underneath. The goal is to try to be pragmatic and balance performance and api usability/convenience with the benefits of a capability system.

It's also a system in development and the shape of things has changed and almost certainly will change further before we're done.

> You can think of the creation syscalls as taking an implied handle to the Process's Job, which is an "object factory" similar to what you suggest.

Implicit handles are not explicit handles, and capability security requires explicit handles. You're obviously familiar with capabilities and the problems inherent to breaking capability properties, so why violate them in this instance?

You mention API usability, but mx_get_time() and mx_get_time(clock_sys), where clock_sys is a static variable initialized by the runtime library at start isn't really any more unusable. Like printf, you can even wrap it in more convenient procedures with no parameters, but you can't go the other way and reify to the clock if that's not how it's designed to begin with.

> There are mechanisms in the works to allow the VDSO to be customized per-Job along similar lines (providing a way of addressing mx_time_get(), etc). mx_time_get() is actually provided entirely in userspace in the default VDSO

This is exactly what I was talking about though: it's totally unnecessary if the clock were accessed via a handle. Why build all of this extra infrastructure when it's completely unnecessary?

Every process would get a set of handles for its basic services, like clock, scratch folder, what-have-you, and building an isolated process just replaces the system handles with wrapped ones. What's the deficiency in this approach that you'd decided to build a more complicated infrastructure instead?

> The intention there is [...] to make guessing what handles a process has harder.

I'm not sure what the point of this is. Are handles not partitioned/per-process like file descriptors? Knowing what file descriptors another process has doesn't give you access to them or yield any advantages. This is how object capabilities should work.

Yes, handles are partitioned per-process. Having them be unlikely to be reused or collide with small numbers (locally) helps avoid some common failure cases (somebody uses a fd after close but somebody else has opened something else that got the same fd and now you have two problems).

Having them be harder to guess provides some (minor) additional defense against attempting to remotely exploit bugs in another process.

> Yes, handles are partitioned per-process. Having them be unlikely to be reused or collide with small numbers (locally) helps avoid some common failure cases (somebody uses a fd after close but somebody else has opened something else that got the same fd and now you have two problems).

This could be handled in user space without affecting kernel structures using opaque structs and some runtime bookkeeping.

Alternately, Kernel fds could use the low order 24-bits for the descriptor itself, with top 8-bits reserved as an allocation count. When a given fd is closed, increment the counter for the next time it's allocated. You've reduced the chance of already rare misuse by 256 fold with requiring some kind of sparse data structure in the kernel.

Perhaps the current handle design is even harder to misuse, but how defensive should you be for accidental misuse like this?

> Having them be harder to guess provides some (minor) additional defense against attempting to remotely exploit bugs in another process.

I've never heard of this kind of exploit. Do you have an example?

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.

How to request capabilities at run time?

Android has shown that the approach of asking for a list of capabilities while installing does not work for user-facing applications. Apps will grab just as much as capabilities as possible and users will blindly accept the long list without reading.

The same way mach does it.

You send a message to a process that dishes out capabilities and it responds with a handle/port/object that encodes those capabilities.

If the only options available are granting all requested permissions at once or not installing at all, they'll often blindly accept, yes.

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.

I can't say everything I've heard for NDA reasons but I've been under the impression its use is in future resource-constrained IoT devices, which tend to lack a secure, lightweight OS with a unified API. Reverse engineering a certain "smart" nightlight uncovered a minimal Linux 2.6.xx rootfs with telnet open and enabled by default

What does that have to do with Linux though? Surely it's the manufacturer's fault for leaving telnet open and not updating? How would a new OS solve any of these issues?

by making these services an OS level concern, the device manufacturer can't screw anything up anymore.

The OS is going to prevent you from running a userspace telnet daemon? Sounds unlikely.

Take a look at the repo. Fuchsia is an OS for mobile devices. The UI is clearly made for phones, they use the Flutter framework, which was made specifically for mobile app development and can target iOS and Android too.

Perhaps. The current set of boot instructions are for a NUC desktop, a laptop, and 2 ARM dev boards though. https://fuchsia.googlesource.com/magenta/+/master/docs/targe...

The hardware in that Acer laptop looks surprisingly similar to what a current flagship phone has in terms of resources if not exact architecture.

I guess generically in that it has a touchscreen, limited hdd size, etc. It's an i5 Intel x64 CPU though.

I believe my phone runs a 64bit ARM with eight 2.3ghz cores and has the same amount of ram as the base Acer model?

The i5 has 2 cores, different memory bus setup, cache setup, etc. If you're saying it has the same rough level of horsepower, that makes sense. Not at all the same architecture though.

> similar to what a current flagship phone has in terms of resources if not exact architecture.

>Take a look at the repo. Fuchsia is an OS for mobile devices. The UI is clearly made for phones

No it's not. Fuchsia is device agnostic. It's for mobile devices, personal computers, IOT devices, etc. Just because it uses Flutter does not restrict it to mobile devices.

>I can't say everything I've heard for NDA reasons but I've been under the impression its use is in future resource-constrained IoT devices.

I highly doubt that.

"Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation"

Magenta is the name of the Fuchsia kernel.

https://fuchsia.googlesource.com/magenta/+/HEAD/docs/mg_and_...

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...

>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't just about the license, but also about the structure of the code. Fuschia is based on a microkernel. "Microkernel" doesn't just mean "modular kernel"[1] it also means "run drivers and systems in a separate process with a separate executable". That imposes performance penalties, but it can enforce a better programming style... and it also allows low-quality proprietary vendor code to be isolated from the base system and not have to pass quality checks or open its source.

[1] Linux is very modular despite being monolithic, and there have been academic operating systems like https://en.wikipedia.org/wiki/Language-based_system which are extremely modular and well designed despite (or perhaps because of) operating entirely in ring 0. Microkernels of course require modularity; but modularity doesn't require microkernel. The key problem with having all your code linked into one executable, of course, is that it requires you to have all your code...

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.

"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. "

You literally live in this world right now.

"It's already painful to compile and run Android from source. Fuschia will make it just impossible."

You can literally go download and compile the entire fuchsia kernel, right now.

How is that "impossible"?

"You can literally go and compile the entire kernel, right now."

Android discussions started that way. Things changed after enough time and revenue with a huge gap between ASOP and Android experience. Their security fixes vs Apple are also now abysmal. Might be a hint at the future of Google's next OS.

"Things changed after enough time and revenue with a huge gap between ASOP and Android experience."

No, things changed for other vendors and for other parts. You can, AFAIK, still happily compile Google's entire kernels.

You are thinking of userspace.

> still happily compile Google's entire kernels

Google's, sure. Some vendors make it painful (and in some cases, even impossible) to compile kernels for their devices.

Google is legally obligated to release kernels for their device. With Fuchsia, neither it nor any of the other hardware makers would be. Google might still continue to release their kernels — say, for developer contributions — but other vendors are quite likely to not do so.

>vendors won't release their kernels

Vendors won't modify fuchsia or its microkernel (magenta). That's the point behind the driver APIs in fuchsia. This should allow Google to update the full system, kernel included, while leaving the vendor drivers, which run in user mode and will still work due to the API being still supported, alone.

If Android is ported to fuchsia, that would solve the android update problem for good.

"You are thinking of userspace."

Is it really Android advertised to the West that people want if it doesn't have the userspace? That's like Windows open-sourcing the kernel but all the needed apps are proprietary. Might as well consider the overall thing proprietary unless your customers exclusively want the kernel plus also-ran software.

> You can literally go download and compile the entire fuchsia kernel, right now.

Only the kernel Google puts out for the development image. I think the parent meant more in the sense of real devices. It is already quite painful to run custom Android builds from source in real devices, where at least the kernel has copyleft protections. It is quite likely that real hardware running Fuchsia will not come with their sources, since Fuchsia isn't copyleft.

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.

the "users" of fuchsia most likely will not be developers only, if GPL is just a symbol, a golden star to show you are a good kid then it does not look so foundamental to me.

as other have said the driver API should actually make that easier (in intents).

Why license the kernel GPL if it doesn't matter any because every vendor would be totally willing to put it up in any case (or defer to the official repo because they made no changes anyway)?

Such an approach smells of virtue signalling, and IMNSHO we have way too much of that already.

Don't forget the difference between "free software" and "open source". Open source was, from day one, pushed as a tool of capitalism: big companies could make more money if they collaborated on common code with each other. The free software movement (whence the GPL) always operated on the idea that, in an ideal world, software wouldn't be copyrighted at all and everyone would just publish their source because that was the right thing to do. The open source movement (whence the MPL) merely argued that open source was the profitable thing to do.

A lot of companies embracing open source have succeeded in building an OSS utopia for themselves internally, and selling software as a service to other people. There's an unprecedented number of people employed by big companies working on things that are nominally free software, but it's free software to do things like large-scale container management, not photo editing. (The free software folks, to be fair, did see this happening and responded with the AGPL, but that strategy seems to have had about zero effect.)

And even Photoshop has realized that switching to a billing model that more closely resembles SaaS than traditional proprietary software is more profitable. But a better comparison is something like Thunderbird vs. Outlook or LibreOffice vs. MS Office: those fights have ended up with both participants losing out to Gmail/Outlook 365/etc. and Google Docs/Office 365/etc., which are free-of-charge, high-quality, and even more non-free than proprietary software that in theory at least you could disassemble.

"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 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!

However, regardless, even assuming you were right, you end up having to put together a compliance release either way, and it's not like the kernel part of that compliance release is any more difficult than the other software.

"That would of course be a disaster for user autonomy and freedom, but why should Google care about that..."

This will be shocking, but the kernel people working on fuchsia do, in fact, care about that!

If they didn't, they wouldn't have open sourced everything, including the kernel.

I'm honestly having a ton of trouble following your logic here.

They want to be able to keep stuff proprietary, but have open sourced it since day 1. They want vendors to be able to release proprietary drivers, but those vendors can and already do so for linux?

What exactly do you think is different and horrible?

Then why is it not licensed under the GPL, like Linux?

I'll ask a related question: Why license it under the GPL? What does Google gain? (and what do you gain)

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

Do you though? Google, as the liscenser is free to keep portions of fuschia under lock and key, so that's not really the case.

You're really not convincing me that Google's intentions are good. Not licensing under GPL is a clear signal that Google is prioritizing hardware partners' needs over their users. Just like Android.

I'm not trying to, I just don't think that using GPL would make them any nobler, except in the eyes of GPL-fanatics.

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.

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 the problems you mention, either in theory or in practice, so why do the same thing and hope for a different result?

(If you've never read it, i suggest you go read the various threads where linus, etc explain that in practice, the only approach that works is carrot, not stick)

It would be the same for Mozilla or anyone else who got popular enough with GPL software and had lots of vendors and OEMs who used their software.

GPL'ing the kernel or not does not change that some people don't follow the rules. You can have them sign it in blood if you want. They'll just work around you or ignore you, as long as there is money to be made. Also, once you are big enough, cutting them off will just attract regulators.

In practice, you will not get them to follow the rules by having a "war on gpl violators" any moreso than we have solved the US drug problem by having a "war on drugs".

If you (or others here) dream is of an ecosystem where everyone is forced, under pain of death, to follow the GPL, it's pretty unrealistic. It's not what happens now, it will never happen.

Rather than pretend that's a realistic way to get people to release source, i'd rather not pretend. i'd rather see something different tried that may have some hope of success.

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 possibly hurt and at the very least it sends a positive signal. So why not use it?

Edit: I'm not sure why you edited your post rather than reply. But I don't think you have really answered my question as it is put here. Is the GPL effective or ineffective? Ineffective, you seem to say. So what's the harm? You claim you care about sources being released. Am I understanding you wrong?

Maybe some employees of Google don't like the GPL. But simultaneously they want all driver sources to be released? But simultaneously they think the GPL is ineffective and won't achieve that?

Your post doesn't really add up. Could you list the reasons why Google isn't using the GPL for Fuschia as bullet points, or something?

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.

Let me restate that: "GPLing Fuschia sends a negative signal to vendors that don't want to release the source for their drivers."

That is fine. Any hardware that is released should come with full source code for its drivers. Vendors that are unwilling to comply, should not be releasing hardware. Since it would be infeasible and restrictive to legally enforce, we can just forbid them to use our popular open source kernels instead.

Please, consider the alternative world you want us to regress to! The present reality is practically utopian, compared to a world where the majority of drivers are proprietary! You want desktop/laptop/server computers to have the same awful, unfixable drivers as Android!? Fuschia will not magically make vendor code any less crap!

And, the "practical problem" here is created by licensing. You said it yourself:

>Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel.

This is a problem of licensing. If we were actually talking about purely technical solutions to purely technical problems, this problem wouldn't even exist. We would never have this bizarre problem of unreproducible binary artifacts sitting on our hardware without the ability to rebuild them.

Here is a thought: Maybe if Google started (threatening to) enforce the GPL against vendors, this would be fixed. Sure, it would also destroy their business relationships. But it would actually fix this security problem, today, immediately.

So let me get this straight: your proposed alternative to Android is just... not having Android at all?

>Here is a thought: Maybe if Google started (threatening to) enforce the GPL against vendors, this would be fixed. Sure, it would also destroy their business relationships. But it would actually fix this security problem, today, immediately.

This is naive and you know it. In reality, what would happen is 3-4 years from now, once the lawsuit has run its course, maybe vendors would need to publicize their binary sources, but given that much time they might just develop in house solutions.

>That is fine. Any hardware that is released should come with full source code for its drivers. Vendors that are unwilling to comply, should not be releasing hardware.

Fine for you. Not fine for the vendors (or Google).

>Please, consider the alternative world you want us to regress to! The present reality is practically utopian, compared to a world where the majority of drivers are proprietary! You want desktop/laptop/server computers to have the same awful, unfixable drivers as Android!?

It worked very well for Windows and OS X, so?

I'd rather have proprietary drivers than no drivers because few vendors are willing to make them open source.

In fact, I'd rather have proprietary drivers than community made, reverse engineered ones too.

If we could have open source vendor provided drivers of course that could be ideal. But in reality we would just have less drivers.

"- If the GPL is ineffective, it can't possibly hurt and at the very least it sends a positive signal. So why not use it?"

1. Of course it can hurt. that's just silly to say. 2. As for why not use it? Because it's ineffective? You answered your own question?

This seems like a pretty basic GPL zealot argument at this point ("It's completely ineffective but you should do it anyway!") , and i'm pretty uninterested in continuing such arguments.

How, exactly, would it hurt? Perhaps by... discouraging use from companies that want to keep their changes private? I am completely fine with that. Proprietary code should not be allowed anywhere near the kernel or hardware support. Would it hurt in any other way?

As a concluding remark, I'll just repost what I posted elsewhere in this thread:

>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.

"I beseech you, in the bowels of Christ, think it possible you may be mistaken!"

Linux does not have wide open-source hardware support on mobile phones, so that argument simply doesn't work in this space - you're arguing in favour of a supposed status quo that doesn't actually exist in the first place.

>How, exactly, would it hurt? Perhaps by... discouraging use from companies that want to keep their changes private?

Yes. That would hurt, because as a user I am very much interested in the products of those companies.

And Google wants them as an OS vendor too.

>I am completely fine with that.

Well, the vendors and Google are not. And neither would I be.

Proprietary code should not be allowed anywhere near the kernel or hardware support.

So that only second tier vendors bother applying?

Your forgetting an important one. The default is a bsd-3 like license. Google prefers to release everything under that single license unless there are strongly compelling reasons to do otherwise, and "it can't hurt", even if it we're true, is not strongly compelling.

> (If you've never read it, i suggest you go read the various threads where linus, etc explain that in practice, the only approach that works is carrot, not stick) [...]

> If you (or others here) dream is of an ecosystem where everyone is forced, under pain of death, to follow the GPL, it's pretty unrealistic. It's not what happens now, it will never happen.

And in response, see Bradley Kuhn's talk at LibrePlanet this year: https://media.libreplanet.org/u/libreplanet/m/understanding-... or the LWN writeup at https://lwn.net/Articles/719610/

Kuhn's argument is that the actual world has involved the stick and not (just) the carrot: GPL enforcement lawsuits have actually existed, and we can't really distinguish people who claim to believe in the carrot from people who would totally have ignored the GPL if it weren't for the realistic threat of lawsuits.

We do live in a world where people are forced under pain of copyright infringement lawsuits to follow the GPL. It is literally what happens now. As you yourself pointed out upthread, Google is quite conscientious about following the GPL, to the point of rewriting proprietary drivers. Even Debian doesn't do that (Nvidia, Broadcom, etc. drivers are available in non-free). Do you think that's because Google thinks the GPL is a great idea? No! Google knows that losing their license to use the Linux kernel is a real possibility under GPLv2 section 4, and would in fact be death for the company.

> GPL'ing linux hasn't prevented any of the problems you mention, either in theory or in practice, so why do the same thing and hope for a different result?

It hasn't eliminated the problem, but it has worked in some cases to the benfit of the vendors and customers.

For example the open source Wifi router community sprung up from one such effort :

http://www.wi-fiplanet.com/tutorials/article.php/3562391

https://en.wikipedia.org/wiki/DD-WRT

> Even the FSF doesn't think GPLv2 is the right license for linux?

Yes, they want a stronger license---GPLv3.

(Edit: I read your statement as "GPL is the right license"; I corrected my post.)

> GPL'ing the kernel or not does not change that some people don't follow the rules. You can have them sign it in blood if you want. They'll just work around you or ignore you, as long as there is money to be made. Also, once you are big enough, cutting them off will just attract regulators.

Your argument could extend to the entire free software movement---to all software written under the GPL. Your argument could be extended to _any_ license! It's dismissive of the impact of the free software movement and the successes of the GPL, and it's dismissive of the legal system as a whole.

I'm being paranoid here, but would allowing an Apache license let vendors put custom spyware and DRM into the kernel that they wouldn't have to release the source for?

In practice: No more or less so than they could do under linux.

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 licenses are better for businesses.

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 for arguably-compliant ways:

Because they can already do like nvidia does, and just have the interfaces be in the kernel, GPL that, and then load binary blobs?

Also remember, even the company doing something more shady (as far as anyone knows), vmware, was not successfully sued for their kernel GPL violation.

So theoretically, they could just drop all pretense and not even do that.

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.

> 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.

If you aren't distributing the binaries, you don't have to release your changes to GPL software. That's what the AGPL tried to fix.

> 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.

> "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.

>In fact, the fuchsia kernel is completely open source, so ...

That's orthogonal. Open source != GPL (which lots of companies avoid). Or is it GPL too?

It is not.

https://fuchsia.googlesource.com/magenta/+/master/kernel/LIC...

>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...

I've heard this argument before without any factual evidence to back it up. Google could have easily used the FreeBSD kernel and not had to deal with the GPL if they had wanted to.

Google didn't invent Android though, they bought it. Fast time to market probably trumped all other concerns at the time. This project probably has a less aggressive timeline.

I'm not sure what that has to do with it. Apple didn't invent OSX/MacOS either, they bought it from NeXT and then used that base to build iOS. Google bought Android in 2005 so they had plenty of time to switch out kernels if licensing concerns were really a factor for them.

Would they? Especially given that they'd already heavily modified their fork to meet their specific needs with ashmem, binder, and logcat? And the fact that they pretty much completely changed direction with user-space development in 2007 to meet the iPhone and not BB?

I seriously doubt they had time to switch to a more user-hostile kernel, given what was already in place. Especially given that they had their hands full programming a user-hostile libc and a user-hostile driver framework that would help hardware vendors with their user-hostile driver-blobs.

GPL implicit patent grab, Google thus prefers more open licenses than GPL.

Probably the same purpose Singularity served for Microsoft. Researchers gotta research.

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", then how bad, in comparison, is what e.g. Apple or Microsoft do (not open sourcing iOS or Windows)?

As I interpreted it, that's not their position.

They're saying that if Google were to pursue their OS goals, specifically using Linux as a base, then they would likely end up doing things that would earn the scorn of the Linux community (at least; it's more likely that what they want to do is GPL-violating).

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).

The other way we get separation is run multiple VMs under KVM which also has an overhead. The Microkernel arch that Linus never wanted is in fact, what we have right now. Exokernels and safe languages are necessity for getting having a good lifetime under battery power and having decent level of security.

>but usually comes at the cost of performance.

Historically, with (ancient) 1st generation microkernels like Mach (used in OSX/IOS), sure.

Else, this article's decent: http://blog.darknedgy.net/technology/2016/01/01/0/

It looks to be a capability-based microkernel in the spirit of L4 and Green Hills' Integrity.

I don't know what Google's purpose for Fuchsia is, but Linux was originally designed for a security model which is uncommon these days. The Linux security model protects different users from each other, but these days it's much more common that a computer will only have one user, and you want to protect that one user from potentially harmful code.

Capability-based security is a big step in that direction. I don't know what "they're both open-source" has to do with it, obviously there are other reasons to choose between different pieces of software besides the license.

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, starting from a clean slate.

>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/

I think my point is pretty clear - your comments regarding the state of Android security are very lacking. I suggest you watch this video by Adrian Ludwig at Next 2017 for an overview:

https://www.youtube.com/watch?v=Zm6ziX5pqt8

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

I think that's the going rate offered by companies that buy exploits like Zerodium. Do you know of a company offering a better price?

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

First, the hack was impressive because of all of the exploits they had to chain. Perhaps this gives you an understanding of just how difficult it really is and why I called your comments regarding Android security silly. Secondly, I don't believe their hack was possible via RCE and needed physical access to the device. Third, you neglected to mention that not only was the iPhone hacked, but it was done so twice. Additionally, the 2 iPhone hacks earned more money than the Nexus 6P hack. Did you also want to comment on the state of iOS security?

You have little understanding of this space, as evident by your comments re: Zerodium. Allow me to inform you that there are plenty of buyers that are willing to pay top dollar for such exploits, as are plenty of people that keep such exploits to themselves or sell them to buyers that will not disclose them.

None of that takes place in the public eye, but of course one can figure some of it out if one pays attention. In some cases, one can also extrapolate what the state of this "underground" is by examining the research that does become public.

I could care less about the value of exploits on the black market. It is interesting, though, that someone that claims to have an understanding of the underground value of these exploits is unaware of just how complex it is to first find these exploits and then chain them together in order for them to work successfully.

I think it's pretty clear. They want an OS that can scale to any device. Whether Fuchsia replaces Android is unclear, but having their own PC OS in which Android can seamlessly integrate with much like iOS and MacOS can is very appealing.

Integration between iOS and Mac OS may just be because Apple controls both of them tightly. It doesn't tell us much about OS similarity or any deeply shared code. You can make two very different OSes integrate seamlessly with each other given full control over the OS code.

The other explanation is that it would be easier to maintain - right now Android kernel is not the same as mainline kernel and has a few rather large functional patches (things like Binder, some modified permissions, wakelock system, support for BIG.little) which are really tough to port ahead. This is why most of devices are still running rather old kernels - e.g. even Pixel is on 3.18.

Patches for these largest features weren't accepted into mailine - they're not really fully fit for a general-purpose kernel and Google's and Linux kernel teams differ in opinions if they're even required and how they should be implemented. As such, it probably makes sense for Google to use their own, fully internally developed, kernel which is built from ground up to handle IPC, security and mobile chips in the way Android/ChromeOS expect it to.

I'm interested in it from a purely technological point of view. Linux is almost 30 years old, and it's architecture is almost 50 years old. Xnu, which is the kernel of iOS is a bit more modern, but Apple has gradually moved it back towards a monolithic BSDish, posix-compliant kernel over the years.

We've actually learned a few things about operating systems since 1970, and today's hardware vastly different from the time-sharing systems of that day. It would be really useful to just implement an OS based on more modern ideas and see where it goes.

I have no idea what Google is planning for Fuscia, but I hope that's part of it.

>but why the move away from linux based systems? Both are open source platforms

Perhaps because whether it's "open source" is not that much of a concern, but rather whether it has the kind of control (over its evolution) and/or next generation design they want?

Proprietary drivers allow a lock in to fuschia os and devices allowing Google more control over the platform.

We probably need open source hardware for this to go away and to be free.

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? What purpose does this kind of 'open source' then serve?

Between Arm, its licensees and Google the ball is kicked around with open source devs struggling for years to make things work. Yet the narrative is this is no one's fault least of all Google and Arm, the 2 most powerful forces in the Android ecosystem.

Google the planet's largest spyware and adware company is now making its own kernel. More power to them but given their track record healthy skepticism of their objectives and agenda is called for.

This is definitely true, and I have a lot of issues with Google and their lip service to open source. (People reading my history will attest, I'm sure.) But at the very least, Fuchsia will be a lot more secure by design than Android, and Android is the dominant OS platform on earth. The state we are right now, where 85% of mobile devices run Android, and 0.7% of them are actually up to date, is a terrifying place to be from a security standpoint.

Why am I not surprised that you can't even get your percentages correct.

Did you mean he was exaggerating? Because it's actually 0.6%.

Sorry, unfortunately I did get my numbers wrong. Based on a chart of Android versions taken from the Google site, it will probably be at least a month or two before 0.7% of Androids are running the latest version. My bad!

I keep a running copy of the stats here: https://oasis.sandstorm.io/shared/UtPbpOAW2OaV4QpkgwIclqGeGC...

Thanks for sharing but I am unable to scroll on Mobile

Fuchsia will be a lot more secure by design against user freedom.

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.

I agree but unfortunatly we are not that many to see it as a major problem.

My take is that Fuchsia is Google's attempt to unify their mobile ecosystem under one proprietary OS like Apple does with iOS (yes, yes I hear you, "But Darwin is OSS..." try making that into iOS though...): which is a good move for Google.

> under one proprietary OS

fuchsia and all it's components are licensed under BSD 3 clause, MIT, Apache 2.0

Which means they can fork it anytime into a proprietary one.

They can do that regardless of the license since they own the copyright. As long as they do not accept external contributions or require a CLA it does not matter what license they offer, they can still make future versions proprietary.

True, that's why there needs to be a distinction between "GPL" and "GPL with CLA".

> they do not accept external contributions

They do tho.

Even if they accept contributions normally (e.g. under the same license), the above licences will allow them (or anyone else) to make a proprietary fork.

Mac OS is bad on BSD which is FOSS. Yet...

If you're going to have capability-based security, please be louder and prouder about it.

Maybe. They start with names. However, the description looks more like access control lists than what I saw in KeyKOS, LOCK, EROS, E, or Combex's work.

> An empty process has nothing > Namespaces are the gateway to the world

Sounds like capability security to me. Although I wish they had said more about how these namespaces work. If they are inheritable and you can virtualize them for child processes (as you can in Plan 9/Inferno) then I'd say it qualifies.

When you create a child process, you can clone your namespace or you can construct a new one for the child.

(Disclosure: I wrote the doc linked above.)

Someone told me there were ex-devs of QNX microkernel doing Google's. Is that true?

Not sure about QNX, but the lead developers are ex Be, Danger, Palm and Apple.

Thanks for that clarification. That is an interesting mix.

As for QNX, one of its founders, Dan Dodge, is now at Apple.

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 process create a custom sandbox and run, say, AppMgr with limited permission to limit the permissions of all apps it manages?

Yes. That's useful for testing as well as for sandboxing.

Appreciate your your answers. This makes Fuchsia quite interesting to me.

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

In Unix, rights - even POSIX "cpabilities" - belong to the process. In Magenta, the rights are attached to the handle.

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 capability of your thinking.

(Disclosure: Google employee disappointed that Hacker News doesn't save the eye-roll emoji.)

Conspiratorial or not - on Google platforms, 3rd party applications are 2nd class citizens. Do you think an outside party could write Open-WIFI given the present service integration policies?

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

Judging by nomenclature it seems to be more influenced by Plan 9, which also adhered somewhat to capability-based security without advertising that fact.

The book's subtitle is literally "A modular, capability-based operating system"[1]

[1]: https://fuchsia.googlesource.com/docs/+/master/book.md

Too bad Fuchsia isn't also written in Rust.

Sound like Genode: http://genode.org/documentation/general-overview/index

Sounds kind of like the rebirth of plan9

Well they got the same artist that made glen the rabbit to make the gopher for Go.

Maybe they can get that artist to do a mascot for Fuchsia.

Renée French is the artist. She is married to Rob Pike.

Reply on news.ycombinator.com