It seems Google has opened up a little bit about its Fuchsia operating system. A (I think) new ‘Overview’ page details what Fuchsia is, what it’s not, and what it’s intended to be used for. Security is obviously a primary goal of the operating system:
Security and privacy are woven deeply into the architecture of Fuchsia. The basic building blocks of Fuchsia, the kernel primitives, are exposed to applications as object-capabilities, which means that applications running on Fuchsia have no ambient authority: applications can interact only with the objects to which they have been granted access explicitly.
Software is delivered in hermetic packages and everything is sandboxed, which means all software that runs on the system, including applications and system components, receives the least privilege it needs to perform its job and gains access only to the information it needs to know.
Google seems to want to make really clear that Fuchsia is diametrically the opposite of Android when it comes to updates. They don’t mince words here, and it might as well read “everything Android is not”:
Fuchsia works by combining components delivered in packages. Fuchsia packages are designed to be updated independently or even delivered ephemerally, which means packages are designed to come and go from the device as needed and the software is always up-to-date, like a Web page.
Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers.
There’s more information about Fuchsia on the page, but the final paragraph should finally shed some light on that Google is definitely serious about the new operating system, and is intending to actually, you know, use it for stuff.
Fuchsia’s goal is to power production devices and products used for business-critical applications. As such, Fuchsia is not a playground for experimental operating system concepts. Instead, the platform roadmap is driven by practical use cases arising from partner and product needs.
If Google is “serious” about this, they should spin it out as a separate company so that it might survive longer than their famously short attention span 😉
Android/Linux kernel have so many extreme issues, you may bet your house that Fuchsia is not just an experiment – it will replace Android.
birdie,
Do you think it will “replace android” or do you think it will replace linux and “become android”? Those aren’t exactly the same.
I have to reserve judgement on fuchsia until I see it, but I’ve got mixed feelings about a new kernel to replace linux. I know linux, a lot of my work is vested in linux and for all it’s known issues it remains an independent FOSS platform. Replacing linux with a google kernel risks loosing the independence of linux. On the other hand fuchsia’s stable driver ABI could finally provide much needed de-coupling of the kernel from the hardware, which has been a huge problem with linux where we’re often stuck using a specific vendor provided kernel especially on ARM, ugh… For their part, many in the linux community have put philosophy (drivers should be open sourced and upstreamed) over pragmatism (kernel drivers should be robustly decoupled from kernel versions). While I get the philosophy part, there’s no denying that the bundling of kernel and hardware drivers has had a regressive effect on me as a consumer, like having to buying more hardware to get a new kernel.
Of course it remains to be seen if fuchsia ends up botching things or having a good execution. but if it solves the driver-coupling issue then conceivably I might even turn to fuchsia for my own personal projects where I’m currently using linux. Fuchsia devices could end up using crypto to lock owners out of control, in which case I’ll condemn the whole damn thing as anti-consumer haha. We all have to wait and see where this goes.
What extreme issues does linux have?
I can’t speak for what issues [Joshua Clayton] might have but here are two things I can name off the top of my head:
1) Linux stores wifi passwords in cleartext. Now these files are restricted to root permission, but many embedded devices run as root by default. Also any security hole that lets you get root access means that these passwords are exposed.
These should be encrypted by the OS and stored in a secure way. I have no idea how fuscia addresses this, but it is something I would address
2) Fuscia sandboxes access to files and other resources so a process cannot get access to files it isn’t allowed to see. Linux doesn’t have a good way to do this, at least out of the box.
I think you meant birdie, whose reply is right below. I’m on the “move Android towards mainline Linux on mobile” bandwagon myself. I like that O.S.’s that don’t belong to Google can also boot. Its one of the things that makes ARM development fun.
* No stable APIs/ABIs (exactly why Zircon was created in the first place)
* A ton of regressions for each kernel release
* No revoke() support
* FUSE performance is horrible
* Certain drivers can’t be reloaded (e.g. video/KMS)
* Can’t recover from drivers crashes (e.g. video)
* In case the kernel panics you often don’t see any indication of that (e.g. visual BSOD in Windows) – your PC just dies silently
* Tons of devices are not properly supported, even … CPUs : https://www.phoronix.com/scan.php?page=article&item=ryzen-4700u-windows – granted it’s not Linux’ kernel issue per se but it just shows how vendors treat Linux and as a user you can’t do anything about that
They want to replace Linux with Fuchsia in Android, no doubts anymore.
I never had a doubt. They want to replace Linux and Java.
Remember Microsoft wanted their own mobile OS as well. Wanting something like that does not mean you can get it.
The hardware support in the Linux kernel is very hard process for any party at this stage to take on.
They had their own mobile OS (Windows CE on phones), but didn’t adapt fast enough. They’ve even said they didn’t because they were in anti-trust trouble at the time, and that gave Android the footing to take over as the other smartphone platform.
Hardware support of the Linux kernel doesn’t matter in the mobile space. They are devices with no interchangeable parts, and the manufacturers will be happy to provide drivers for the new Android system that don’t require updating.
oiaohm,
Microsoft was late to the game, lacked mobile market share, and couldn’t convince developers or consumers to switch. It’s a rather different position than google is in.
I disagree, hardware is an obstacle for indy development, but it is not going to be an obstacle for google. The main obstacle for google is whether it can complete with the incumbents android and ios. Trying to compete against android head-on would put fuchsia in a weak position, however considering that google controls android they could simply replace linux in a future version and continue calling it android. As long as the android userspace programming APIs have a compatibility mode, it would be a rather uneventful transition.
The linux crowd are probably not going to like this, but conceivably over time android devices running linux would naturally become obsolete and future models would be replaced with fuchsia as consumers go about their way without caring about the underlying kernel.
You are overlooking that google still needs to get soc vendors on board to make drivers for items.
“Hardware support of the Linux kernel doesn’t matter in the mobile space. They are devices with no interchangeable parts, and the manufacturers will be happy to provide drivers for the new Android system that don’t require updating.”
This is forgetting history. Windows CE was sold to manufactures with the same idea. Yes that gave us security faults in drivers.
Android also had the idea that they could release devices without updating kernel. Yes android had a lot of security problems at the kernel level caused by drivers. Now google with android Linux kernel is pushing upstream first to hopeful get to the point of being able to update kernel so close security faults.
https://source.android.com/devices/architecture/kernel/future-versions
Basically google android developlers have hit a lot of problems getting to this point with android. Including learning that you cannot trust upstream SoC vendors to make quality kernel code. I remember when samsung added a driver to the Linux kernel of their android devices to bring /dev/mem back so they did not have to rework their userspace driver with the total system wide security hole.
SoC vendors with Fuchsia for quality of work without third party review will be no better. Even Microsoft with Qualcomm has had trouble getting quality drivers.
Hardware support is one hell of a obstacle.
1) convincing the SoC vendors to put developer time to your platform.
2) Getting those SoC vendors to provide quality drivers(Mega teeth pulling this point).
Google is not their own CPU/SoC vendor like Apple in the mobile space. Now if google buys a SoC company Fuchsia will stand a chance but this will also put current Android partner SoC vendors noses out of joint at well.
oiaohm,
No, you are the one overlooking that google is a $769B dollar company, they do not have a hardware problem, haha. Many companies have failed to break into the mobile market, but it was not due to lack of hardware but rather lack of consumer demand. I promise you this will be what makes or breaks fuchsia. Consumers reaction will be the ultimate test, but if google uses fuchsia as the new android kernel then most consumers won’t care about the loss of linux if we’re being honest.
“No, you are the one overlooking that google is a $769B dollar company, they do not have a hardware problem, haha. Many companies have failed to break into the mobile market, but it was not due to lack of hardware but rather lack of consumer demand.”
I have not overlooked that Google is a $769B dollar company. That 769B dollars if you cost out the different groups analyzing code added to the Linux kernel would last all of 4 weeks. The cost of the Linux kernel development to keep goodish code quality more than any single company can pay.
You are also overlooking consumer demand is also partly driven by quality of drivers. If the kernel mode drivers are glitch and the product performance is glitch because of it consumer demand will be harmed at lot.
” if google uses fuchsia as the new android kernel then most consumers won’t care about the loss of linux if we’re being honest.”
Maybe they will not care if the product is equally stable. Without the resources to get good quality drivers for the hardware this will not be the case. Google is not rich enough to put the money up to do it.
oiaohm,
You can tell yourself that, but frankly it’s quite egotistical of you to assume that linux has a monopoly on “goodish code quality”. It’s possible to do better than linux on quality. Linux certainly wins on code quantity as a FOSS kernel given it’s decades of legacy hardware support, but as dark2 mentioned that’s unlikely to matter for whatever new devices they’ll be shipping.
Look, I can see why you want to be critical of fuchsia given your attachment to linux. Honestly I don’t know much about fuchsia, so I encourage you to go ahead and point out fuchsia’s real technical shortcomings, I’m game for that! But don’t let a superiority complex compromise your objectivity.
What makes you think SoC vendors aren’t already on board? These are companies that have mostly never cared about open source, or spending $$ on third party developer documentation, or wasting time updating/maintaining code for drivers that previously worked well; who have been putting up with “GPL kernel with unstable driver API” (despite never wanting to do that in the first place).
I’m sure they’ll jump at the chance to provide proprietary drivers for a stable API; for better or worse (mostly for the better if you care about being able to update your phone’s software after the manufacturer stopped bothering to update drivers).
“so I encourage you to go ahead and point out fuchsia’s real technical shortcomings,”
Alfman it starts with the license.
“I’m sure they’ll jump at the chance to provide proprietary drivers for a stable API; for better or worse (mostly for the better if you care about being able to update your phone’s software after the manufacturer stopped bothering to update drivers).”
Note I said two points 1 is getting soc vendors on board 2 is getting quality drivers out of them.
Brendan this means you have not looked at what they have done to the Linux kernel and FreeBSD and windows and android userspace drivers.
Lets start with the technical problem of using very liberal license with these soc vendors.
“who have been putting up with “GPL kernel with unstable driver API” (despite never wanting to do that in the first place).”
Lets do some looking into what these SoC vendors will want to do.
Lets look at what they do with a GPL kernel to start off with. You see patches from SoC vendors to the Linux kernel in the 5 million lines of code +. This is not hardware support alone this is like replace the complete OS scheduler with their own. GPL they have to publish this stuff to their users even if they don’t mainline it. This is not a good sign.
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/
This goes detailed into the non upstreamed work with the Linux kernel its not quality.
FreeBSD is used in a lot of different custom items again the vendors makes these don’t send their drivers upstream. Most of the security faults is in the vendors code.
Windows Microsoft does a kernel update and someone driver breaks some where because people writing drivers have not followed Microsoft documentation on how to write drivers. Microsoft has attempted to fix this by mandating all drivers signed yet they still have this happening today. Mostly because without the source code to the drivers you cannot really see that its quality.
Android Userspace drivers not used by SoC vendors because they are classed as not performing enough.
There is a old saying.
Security by obscurity. The reality here is the reverse. The more hidden the SoC vendor gets to be with their drivers construction the worst the quality of code comes. Why if no third party can see it and we are doing something really bad someone will not notice right other than the people hacking the platform.
1) With a GPL license soc vendors are willing to replace all core parts of the Linux kernel at times to out do their competition. Linux having a unstable ABI in kernel space forces SoC vendors to upstream and have their code peer reviewed to get cost down.
This one means the Fuchsia google makes and the one SoC vendors end up providing will be nothing like it. Heck Linux kernel by SoC vendors at times user is only using 5 percent upstream code 95% soc vendor code. Remember with Fuchsia license vendor does not have publish how much they have in fact changed.
2) if you cannot get the source code of the drivers you cannot have them effectively peer reviewed that they are in fact conforming to the policy for how drivers should be constructed. This is the Microsoft problem and they have thrown billions of dollars at this problem without mandating source code and still suffer from update windows kernel and system bricks.
The reality is the way SoC vendors behave when they don’t have peer review is 100 percent predictable. Yes the way they behave is quickly constructed barely works code that has not been properly security audited with items done so they out benchmark their competition.
“It’s possible to do better than linux on quality. Linux certainly wins on code quantity as a FOSS kernel given it’s decades of legacy hardware support, but as dark2 mentioned that’s unlikely to matter for whatever new devices they’ll be shipping.”
95% of the high cost of code audit for the Linux kernel is not about the decades of legacy support drivers. Its the cost to audit all the new drivers. There are multi server farms around that there job day in day out is auditing all new submitted code to the Linux kernel looking for flaws. Linux kernel broad platform targeting means more parties are willing to put in resources into this pool quality control than what the SoC vendors and Google have combined. Quality Assurance is not a cheap process.
Yes to make new quality devices you need to take on how to get Quality Assurance like the Linux kernel has or be more buggy than the Linux kernel particular with how under handed the SoC vendors are.
Yes SoC vendors may ask for what Fuchsia is but they are also Fuchsia worse enemy for it being a quality OS due to what they will want/willing to-do to it SoC vendors are not your friend when it comes to making a new OS in the market. Apple has not gone to the effort of being their own SoC design firm for no reason this gets the SoC vendor under their own roof so they have some control over them. Yes SoC vendors will be frenemy to google Fuchsia. A very non restrictive license plays SoC vendors hands to ruin the platform.
oiaohm,
This license?
fuchsia.googlesource.com/fuchsia/+/refs/heads/master/LICENSE
It’s pretty much the 2 clause BSD license…
en.wikipedia.org/wiki/BSD_licenses
If you don’t want to use fuchsia on account of it not using GPL, then more power to you, but realistically most consumers aren’t going to care about that.
Your argument idealizes the SOC situation under linux, but that’s part of the problem. We can’t just keep ignoring the recurring trouble there year after year. Fuchsia is not a response to the idealized linux you are thinking of, but rather a response to the shortcomings that linux has created in practice. I will not deny the SOC vendor support issues are problematic, but you should not deny they are a problem on linux too. You’re accusations of implicitly poor quality on fuchisa are hitherto unfounded. At least fuchsia has a plan to deal with proprietary hardware and a stable ABI that allows the kernel to be decoupled from the hardware.
I’m not anti-linux by a long shot, however the linux community has largely been too stubborn to improve things. Maybe a competitive threat from fuchsia is exactly what linux needs right now: necessity is the mother of invention!
oiaohm, you seem to be facing the existential crisis Linux people can never overcome. You can’t convince people Linux is better by trying to win technical arguments. What writes good drivers? Money, which will be in no short supply for Android devices. What are the disadvantages/advantages to this over Linux? The hardware driver bs ends and any tablet/smartphone gets the latest update. It’s objectively a better plan for end users in the most important ways, but the stuff you’re preaching about is based on religious sections of Linux users’ brains rather than practical business decisions. You’re literally attempting to spread FUD about moving to a BSD license system right now.
“At least fuchsia has a plan to deal with proprietary hardware and a stable ABI that allows the kernel to be decoupled from the hardware.”
Never read Linux kernel history right. 1995 with Linux kernel 1.2.8 stable ABI was proposed to decouple kernel from hardware. This does not happen performance raised as why not.
There was another one in the 2000s that was to have a stable kernel driver ABI for Linux, Freebsd and Unix. This was rejected by Nvidia and other close source vendors because it was going to be under performing. So this dies as well. Notice same issue.
https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst
The issues listed here still apply to why a stable ABI in kernel space fails. Nothing fuchsia is doing is preventing it from being screwed over by what is listed.
So fuchsia goes microkernel and runs drivers in userspace. Remember the old one where there was a plan to have a universal ABI for drivers between Linux, FreeBSD and Unixs. Now fuchsia is under a highly librial license. Exactly why is a soc vendor not going to add syscalls to the kernel so their product benchmarks better. We already see today with vendor provided OKL4 that is under a BSD license where the microkernel has grown extra syscalls to make X vendors drivers better.
Basically Alfman and dark2 you need to wake up. Linux short comings as horrible as it sounds exist the way they do because that is exactly what the SoC vendors do by deed.
Remember actions speak louder than words. SoC vendors will tell you in words over and over again they want a stable ABI to save on development but then in actions destroy your stable ABI just to get greater performance over their competitors.
Microsoft who kernel is closed source so vendors cannot modify it has not prevented those making drivers doing things against what Microsoft has recommend just for higher performance over competitor.
Remember SoC vendors will have no issues modify the microkernel at the core of fuchsia for performance so breaking the ABI if there is no legal barrier or unaffordable extra costs to them doing just that.
Linux kernel unstable API/ABI exists because the kernel developers of Linux are aware that is the way its going to be no matter what they do. GPLv2 license does not prevent Linux kernel core from being modified because some SoC vendor thinks this will allow them to win some benchmark so look better to consumers.
Fuchsia is in the same position with a more open license and now with a so called stable ABI that is absolutely not going to stay that way once the SoC developers start fighting with each other for who has the best performing chip.
Google need to put up a really solid plan to control the SoC vendors making drivers or in time fuchsia will be turned into a mess as SoC vendors go after performance. BSD based license that gives the SoC vendors open hand to modify the kernel is not a good plan.
Horrible right that one side of SoC vendors tell you that they want stable ABI then the other performance optimizing side to win in benchmarks don’t give a rats how fair they ruin a stable ABI just as long as their product wins the benchmark. Please note this behavior applies to windows and why Microsoft started doing driver certification to try to stop this with limited success.
Windows CE devices back in history use to brick at times when you applied updates from Microsoft because the vendor had written drivers disobeying Microsoft directives.
SoC vendors will not be Fuchsia friend. They will be Fuchsia enemy if Fuchsia does not have suitable items in place to control them.
Its really simple say give as a stable ABI for drivers this will fix things. This totally ignores how much a vendor can gain in marketing by having a high performing product and how much money they can get by breaking the rules.
dark2,
Obviously you and I want & expect a reasonable debate on the technical merits of fuchsia, but the reason he keeps deferring to philosophical arguments rather than technical arguments is that he doesn’t actually have any technical argument to discredit fuchsia. It’s not just him, many linux elites have gotten too comfortable in their dominant position in the FOSS world and it’s had a stifling effect on the project. There’s too much complacency and no sense of urgency in addressing the problems that we’re facing with linux on android and IOT platforms. Well, overconfidence is a dangerous thing against credible competition. I for one welcome new competition from fuchsia to give linux a much needed kick in the butt (I really hope google doesn’t screw owners with restrictions though…).
oiaohm,
You’re entitled to your opinions and philosophy, but I’m not going to debate that. Let’s talk when you come up with specific technical criticisms for fuchsia.
Yes; but you’re also complaining that the drivers they put out for Linux are bad, and not providing any clue why the drivers will be worse than the existing “already bad” code they use on Linux.
The assumption that vendor’s drivers will magically become worse for some unspecified reason is less logical than the assumption that (with a stable API) they’ll be spend time improving the quality of the drivers instead of fixing breakage caused by an unstable API.
Far more likely (than either of those dodgy assumptions) is that the quality of vendor’s drivers won’t change; however this depends a little on how Google have designed the driver API/s, how they implemented “API caller” code, what kinds of utilities they provide in their “driver developer kit” to make things easier for driver developers, etc.
There’s a much simpler explanation for that. Linux was primarily designed for server workloads, and for modern “interactive user with strong power management goals” (smartphones) the original scheduler is extremely bad. Heck, even for modern servers the scheduler is bad, and Linux developers have added multiple hideous hacks (e.g. cgroups, etc) in an attempt to ease symptoms while not bothering to fix the root of the problem (which would not be easy to do).
More specifically, Linux scheduler (excluding “real-time” stuff that nobody can use because it require root) doesn’t take into account how important any task is so the OS wastes time doing unimportant work while important work waits; which is fine when almost every task is the same (HPC workloads, most server workloads) and “workable” if you throw 8+ cores at it (to increase the chance that important work actually gets done) or when the computer is mostly idle (doing nothing in the background); but awful for everything else. The reason is that scheduler isn’t provided this information by most user-space tasks (because most user-space tasks know Linux won’t do anything with the information anyway so developers don’t bother). For Andriod (for Java) there is effective thread priorities and the user-space (the parts users actually care about) is mostly replaced, so the whole “user-space doesn’t tell scheduler anything” problem disappears.
No; the reality is that for security “open source” is a joke because no sane person ever bothers looking at the source code anyway (can you imagine a world where normal consumers carefully examine and understand all of the source code before they decide which smartphone to buy? I can’t – it’s ludicrous). The reality is that running each driver in its own isolated address space is inherently more secure (for a small performance cost) than the “open source Linux cluster-bork of stupidity” where every driver has complete access to every piece of data in RAM (and every “minor bug” in any driver becomes a critical vulnerability because of that). If you truly believe vendor drivers are low quality then Android should make you very scared.
Google have been fighting the “update problem” for years. I think their plan is that they provide the OS direct to the consumer (not the vendor) and the vendor only provides their drivers (and never touches the rest of the OS). Of course this can’t happen without “stable driver API” so it can’t happen with Andriod.
You can confirm that a driver doesn’t attempt to access resources it shouldn’t by isolating it (denying any access to those resources). You can confirm that a driver complies with various requirements of its API using compliance testing. These things can be automated; without the need to wonder why nobody wasted their time doing a peer review sooner after you find out that the vulnerabilities have been exploited for the last 3 months; and without “false positives” caused by source code that doesn’t actually match the released binary.
Brendan,
Oiaohm is our resident flat earther. You can point out facts, but if those facts contradict doctrine they’re just ignored. The more you prod though the more you see a philosophy built around “linux is best” by definition and everything else can be argued away.
Actually I’m curious to prod further…
oiaohm, can you list some faults and weaknesses for linux compared to let’s say windows? Obviously there are pros and cons to everything: linux is only one tool for the job but it isn’t the end all be all. Where is linux objectively worse? I ask because I want to see if you are able to overcome your own biases.
Actually, Microsoft was too early.
They were the dominating smart phone platform right until the iPhone showed up.
However, MS reacted with a brain dead roadmap involving incompatible revisions when they introduced Metro. Which made developers not bother.
It’s weird, MS had a very developer-oriented culture on the desktop. But they literally went out of their way to alienate devs on their mobile platform.
If I were them I would begin with replacing Chromecast and Wear Os because they would have less problems with legacy supp.. Perhaps they would be able to get a decent battery life.