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

Hardening the Kernel in Android Oreo

android-developers.googleblog.com

Post reply on HN
Print view View original

91–100 of 108 posts

Re: Hardening the Kernel in Android Oreo

#91

Post by majewsky »

kuschku wrote: post #85
mrhigat4 wrote: post #21

Android should really use a modern kernel. All the forking mess involved in Android updates is a terrible problem predicated by the lack of generic drivers on mobile devices. Copperhead[0] has been working to apply security patches to the kernel for some time and PostMarketOS[1] has an eventual goal of using the mainline upstream kernel. Really pulling for PMOS. [0]: https://copperhead.co/android/ [1]: https://www.po…

The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers. A similar issue happened recently between AMD and the kernel maintainers (AMD wanted a stable API for GPU drivers that would allow the same drivers to run on Windows, Mac, desktop Linux, and Android; and AMD had already built this API and was willing…

> The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers.

It's not stupid. APIs need to change eventually. Even famously backwards-compatible Windows has its fair share of API changes. And when public APIs change, you can either drop support for the old one (thereby also dropping support for old hardware), or provide a compatibility mapping from the old to the new API (if that is even possible).

Linus knows that he does not have the manpower to do either. All he can realistically do is only support the current API, and require devs who change the API to update all usages inside the kernel source tree when doing so.

Re: Hardening the Kernel in Android Oreo

#92

Post by dmm »

thanksgiving wrote: post #79
zaphirplane wrote: post #60

Earlier quoted context omitted.

I expect if google had that strength in position, they would. Perhaps that would lead to more fragmentation and less vendors releasing the latest android, leading to a highly dominant maker squashing the others and then having a stronger position in negotiating with google.

Perhaps it would be more desirable to reduce dependency on blobs? What can we do to encourage manufacturers to release source for their hardware? I assume they care about selling hardware and the firmware is just incidental?

Even when full source is available it doesn't really solve the problem. Many of the drivers provided for android socs are very poor quality and would not be allowed in the kernel. Typical problems include not using linux conventions for config parameters(device tree) and duplicating large portions of existing kernel functionality.

Not getting into the tree is a problem because kernel interfaces change all the time. When someone changes a kernel interface they are expected to update all of the affected code, but out-of-tree drivers don't get that.

Re: Hardening the Kernel in Android Oreo

#93

Post by pjmlp »

majewsky wrote: post #90
pjmlp wrote: post #86

Earlier quoted context omitted.

For sure Google can do it, what would they do, sell handsets with their own OS, based on a fork from GNU/Linux? It has worked quite well for those that tried.

What would they do? Sell handsets with a years-old Android, of course. Experience shows that the average customer doesn't give a shit about Android versions.

Which in such scenario wouldn't be able to talk to Google Play Service servers any longer, if Google was actually serious about doing it.

Re: Hardening the Kernel in Android Oreo

#94

Post by [deleted] »

majewsky wrote: post #91
kuschku wrote: post #85

Earlier quoted context omitted.

The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers. A similar issue happened recently between AMD and the kernel maintainers (AMD wanted a stable API for GPU drivers that would allow the same drivers to run on Windows, Mac, desktop Linux, and Android; and AMD had already built this API and was willing…

> The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers. It's not stupid. APIs need to change eventually. Even famously backwards-compatible Windows has its fair share of API changes. And when public APIs change, you can either drop support for the old one (thereby also dropping support for old hardware)…

[deleted]

Re: Hardening the Kernel in Android Oreo

#95

Post by mrmondo »

khc wrote: post #4

"Android 8.0 makes KASLR available in Android kernels 4.4 and newer." And yet on my pixel with Android 8.0, I am only using 3.18.52. Who actually ships Android with kernel 4.x?

4.4 is old. Technology - especially software moves fast and it’s been 9 months since 4.4 was released. There’s been a lot of security, performance and feature improvements since 4.4 was released.

Major and/or userland problems don’t tend to occur as the kernel gets developed and released. There are major advantages in accepting new subsystem code over patched ‘legacy’ code.

Re: Hardening the Kernel in Android Oreo

#96

Post by kuschku »

majewsky wrote: post #91
kuschku wrote: post #85

Earlier quoted context omitted.

The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers. A similar issue happened recently between AMD and the kernel maintainers (AMD wanted a stable API for GPU drivers that would allow the same drivers to run on Windows, Mac, desktop Linux, and Android; and AMD had already built this API and was willing…

> The big issue with this is the – afterwards you always know better – completely stupid decision of Torvalds to never support a stable API for kernel modules, or drivers. It's not stupid. APIs need to change eventually. Even famously backwards-compatible Windows has its fair share of API changes. And when public APIs change, you can either drop support for the old one (thereby also dropping support for old hardware)…

There’s several problems with this.

(a) all drivers live in kernel space, even the sketchy drivers you have to download from NVIDIA

(b) if a driver wants to be included easily, it needs to become part of the kernel source tree, but that can only happen if Torvalds and his maintainers get full control.

(c) the API is broken with every release

As a result of all of this, the kernel maintainers refused even in any way to cooperate with AMD on their open driver (AMD needs a stable layer at some point to run the same additional functionality on windows, mac, and linux – the alternative is no linux support), we get ancient drivers on Android, with Google building their own HAL, and more shit.

At the same time, the syscalls, where maintaining a stable API is completely irrelevant and could simply be done via a small userspace library that you call to instead of doing actual syscalls, and which also massively would improve security if the translation between old and new syscalls would happen in userspace, is the one thing Torvalds maintains in the kernel.

The decisions made by Torvalds are reckless, massively hurt security and usability of open source, and the entire concept of open source ("we’d rather have only a proprietary AMD driver than an open AMD driver that relies on an HAL").

Re: Hardening the Kernel in Android Oreo

#97

Post by bostand »

srcmap wrote: post #46

I like to see Android add System GUI to monitor: * all apps (including daemon processes) that makes internet connections. * Where they are connecting to. * AND give user to GUI/Options block those connections. I also want Android give users option to audit/monitor all new programs, .so, files that has been added to the systems and by which program, time. If there are suspicious file that is added to the system, we ca…

Xprivacy?/

Re: Hardening the Kernel in Android Oreo

#98

Post by Kiro »

X86BSD wrote: post #22
nsxwolf wrote: post #15

Did they have to license the name?

My understanding was you can use a trademarked name but only if it was in an unrelated category. Clearly no one will confuse a phone running Oreo with a cookie you eat and dip in milk. now if google made a cookie and called it oreo, they would get sued. But IANAL and am probably totally wrong here.

https://www.android.com/versions/oreo-8-0/

See the huge Oreo cookie there? I honestly don't understand why you made this comment.

Re: Hardening the Kernel in Android Oreo

#99

Post by limeblack »

bingobob wrote: post #77
sigmar wrote: post #24

Earlier quoted context omitted.

You are dead on. The problem is incentives. There is no technical solution to solve the issue of OEMs not wanting to spend time/resources on updating older phones. Treble will help out LineageOS, CopperheadOS, and XDA devs. But it won't improve the update cycles for OEMs when their business (ie profit aims) pressures them to limit development resources to new phones.

but wouldn't treble allow for there custom Android to be updated across there fleet of devices where currently each product has to get its custom build with drivers etc.

Yes this is how I interpreted it but I'm sure the other people here probably know much more which leads me to believe that must not be the case.

Re: Hardening the Kernel in Android Oreo

#100

Post by yahna »

_pmf_ wrote: post #84
kelnos wrote: post #42

Earlier quoted context omitted.

Yes, and I addressed that in my comment. Google, however, can effectively do whatever they want. If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. I bet most of them do enough business supplying parts for Android phones that they'd get their shit together. And it' not hard! Writing an initial driver for some hardware might take a lot o…

> If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. This leaves Google with a version of Android that does not run on anything. There are less than a handful of relevant SoM manufacturers that are capable of delivering consumer grade SoMs capable of running hardware accelerated Android; Google can not alienate these.

It also leaves those manufacturers without anything to put on their hardware.

I would think they would start to take things more seriously at that point.

Post reply on HN