Hacker News Reader

Comment by fabrice_d | Hacker News Reader

The biggest threat to Linux on phones could be Fuchsia. If/when Google decides to switch to a Fuchsia base for Android, all the chipset vendors will follow suit and that will make it even harder to find chipsets that can be used with a Linux kernel - upstream or not. That will dry up the amount of effort put into making Linux a good mobile platform.

Maybe the stable binary api of Fuchsia drivers will be usable on Linux with a wrapper, but that obviously won't be open enough for projects like the Librem5 (I'm not sure what is Pine64 position on binary drivers).

View on HN

Is something wrong with using Fuchsia kernel insted of Linux?

It's open source and it has a modern, secure capability architecture.

Running Linux binaries, not just source code, is a design goal of Fuchsia: https://news.ycombinator.com/item?id=26104667

Fuchsia has separated the drivers from the kernel[1], enabling proprietary drivers that are never updated to become acceptable. This can result in Blueborne[2], GPU vulnerabilities[3], and any other proprietary driver remaining permanently vulnerable as the hardware manufacturer has no incentive to update the driver.

In Fuchsia's model, you can run the latest OS with these vulnerable, non-updated drivers, or your device ODM could even release nothing and you don't have the GPLv2 to fall back on to get the Board Support Package for your hardware to build your own updates with.

1 - https://www.theverge.com/2020/12/8/22163225/google-fuchsia-o...

2 - https://en.wikipedia.org/wiki/BlueBorne_(security_vulnerabil...

3 - https://redd.it/s48lz

Those types of driver vulnerabilities are exactly why Fuchsia's sandboxed driver model is needed.

I see that as a sort of capitulation. What is actually needed is manufacturers who remain responsible and responsive when it comes to the quality of their drivers. They need to support them much longer than they currently do, and they need to release security fixes promptly.

I think having a sandboxed driver model is a great idea in general, but this will only encourage hardware manufacturers to care even less about supporting their drivers beyond the initial more-or-less-working release.

> What is actually needed is manufacturers who remain responsible and responsive when it comes to the quality of their drivers. They need to support them much longer than they currently do, and they need to release security fixes promptly.

That requires a level of investment in engineering competence that they aren’t doing because there is little incentive.

How would you suggest changing that?

When the support ends, drivers must be open-sourced.

That’s just a wish.

How do you create the incentive for it?

I think that just must be a law. I see no other possibility.

How would the law define ‘support ends’?

Also seizing source code at gunpoint seems antithetical to the notion of free software.

This is the question of security, see https://news.ycombinator.com/item?id=27387169.

> How would the law define ‘support ends’?

Whenever the company refuses to fix security bugs.

What if they don’t refuse - but are just slow or inefficient or produce bad fixes?

There exist more or less standard times for fixing security bugs. Let's say 90 days. If a company cannot provide security for their customers in a reasonable time, they must be held accountable.

Sure - typically the remedy for negligence would be compensation for the impact.

Seizing property at gunpoint doesn’t seem related to this.

Fuchsia has a lot of good features technically, there is no doubt about that - it was time to revisit how an OS should be designed given the usage patterns of devices it powers. I hope the capability model will put to rest the insanity that is SELinux (just look at the amount and complexity of SELinux rules in AOSP). The license choice for the kernel is more controversial, but no one expected Google to ship under the GPL.

It also happens to solve some of the pain points with Android: in a way it is "Project Treble on steroids" aiming to resolve the issue with fragmentation and lack of long term support from Android chipsets and OEMs.

Except there still won't be long-term support from OEMs, you've instead just pushed the security responsibility onto Fuschia and hoping that the kernel maintaining a strong sandbox will be sufficient to mitigate all driver security vulnerabilities (hint: it won't be).

Most (all?) the drivers will be closed source since the license allows it.

Worse yet, the OS itself is non-GPL, an OEM can modify Fuchsia outside just the drivers to support their device (eg: create a board support package) and never release their modifications to their customers, meaning the community can't compile their own updates to the software running on the device (worse than our current Android situation).

At least they won’t break with every minor update.

Unless the OEMs customize the whole stack to only allow the kernel to talk to their drivers. That is only enforceable by legal constraints from Google akin to the CTS [0].

[0] https://source.android.com/compatibility/cts

The pine64 position on binary drivers is not as hard as the purism one (perhaps they try to balance more with cost), but there are still projects to reverse-engineer and replace some non-free firmware, such as the modem firmware: https://github.com/Biktorgj/pinephone_modem_sdk.

I agree that Fuchsia will become a problem going forwards, even if Fuchsia drivers can be reverse-engineered. It's also possible that phone hardware is commodified enough that google will be unable to lock us out, or that google abandons or delays the Fuchsia project.

The PinePhone has the same security properties as the Nokia N900 where the modem is connected over USB rather than an interface with direct memory access (eg: PCIe) where the proprietary software running on the modem can read anything in main memory.

IOMMU groups are supposed to compartmentalise modems here, but as far as I know this tends to be blackboxed on Qualcomm processors.

Don’t you think we will see more general computing ARM chips with the M1’s success? Aren’t we approaching a world where your phone, tablet (hopefully eating the laptop…), desktop and server all run more or less the same chip?

CPU standardization is already here, your iPhone runs ARMv8-A does that allow you to replace the kernel on your iPhone?

What it is about android that allows you to do so is the copyleft license on the linux kernel. Chips can be locked down, and they generally are.

Yes, but I don’t understand how Fuchsia prevents pine64 to offer a Linux compatible chip. Not being able to unlock an android/fuchsia/iOS phone doesn’t really matter, does it?

Either way, I was hinting at a possible liberation through the laptop/desktop/server ARM SoC market, which is certainly coming. I think x86 is “over”.

Well: if fuchsia becomes the standard phone OS, the current practice of providing kernel source (to the point it can be compiled into working firmware) will end.

It doesn't prevent anyone from providing linux firmwares, but it takes away the reason they must do so.

No, because the M1 is like every other phone and tablet out there in that they're ARM SoCs. There are significant downsides to ARM SoCs compared to x86-64 machines in that they have no standardized architecture, nor enumerable buses.

Fuchsia is a much more secure and updatable platform. It'd be wonderful if there was a Pine-like for Fuchsia, especially if they can use open drivers.

It will definitely be more secure, but probably drastically less open, since there won't be any GPL code underneath for people to demand copies of.

Fuchsia, once it reaches the level of polish required of proper Google products, will be as closed as iOS. And security will be the justification for it.

The Fuchsia code itself is open, and while a vendor could make changes and not release them, a project like Pine wouldn't do that. That would indeed be a major motivation to use a Pine-like over other vendors.

> The Fuchsia code itself is open

For now. It doesn't yet have all of the proprietary bits added in, nor has it been shipped to OEM devices using mobile device hardware. Most of the proprietary Google bits of Android are proprietary by choice, there's no way Google is going to be any more open with Fuchsia.

Pine does not contribute device drivers, the SoC vendors and groups like Linaro&Collabora write them primarily.

Hopefully SoC vendors and IP vendors release the source for their device drivers.

Just like Darwin, the open source kernel of iOS…

pine64 and purism are lot smaller than qualcomm and the like. They don't have that type of leverage.

I disagree. Fuchsia will eliminate the need for the hardware vendor to supply open-source drivers. In this regard, it is a major step backwards in security and upgradability.

> Fuchsia is a much more secure

Secure from what? One of the major risks in the mobile phone threat model is surveillance carried by the vendor, the OEM and so on.

Closed source drivers, OS components and apps are themselves the attack vector.

Reply on news.ycombinator.com