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

51–60 of 108 posts

Re: Hardening the Kernel in Android Oreo

#51

Post by FuckOffNeemo »

limeblack wrote: post #47
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…

This can be done with apps already although you have to start them on reboot in my experience. Let me go fine the name. It is called NoRoot Firewall.

This is great, never knew of this before now. Thank you.

Re: Hardening the Kernel in Android Oreo

#53

Post by structural »

kelnos wrote: post #26
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…

Yes, this was my first thought as I was reading the article. A better title for it would be "Backporting Modern Linux Kernel Features to Our Really Old Kernels Instead of Doing the Right Thing and Keeping Up To Date". I do -- I really do -- appreciate that version churn is difficult, and the Linux kernel also doesn't make it easy since they don't guarantee any stable internal APIs, but they're also adding a lot of wo…

If they are backporting features well, they're approaching kernel development very similarly to the datacenter.

As an example, the standard server at $large-dayjob-server-farm runs on RHEL 6, with RHEL 7 (the latest release) being used for new machines. Both are still supported for quite a few years into the future. Let's look at their kernel versions: (per https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux)

"6.9, also termed Update 9, March 21, 2017; 5 months ago (kernel 2.6.32-696)"

"7.4, also termed Update 4, August 1, 2017; 28 days ago (kernel 3.10.0-693)"

Upstream release timelines: 2.6.32 - Dec 2009 3.10.0 - Jun 2013

Both of these upstream releases are YEARS older than both "current" and what many Android devices are using today - we'll have machines running some patched version of 2.6.32 a decade after its initial release!

So there's obviously a difference in quality of backports and updates here and some grey area in between. I can't with a straight face say that either Red Hat or Google are right or wrong in their approaches here, it's just very different than the frequent-release model that some people are used to.

Re: Hardening the Kernel in Android Oreo

#54

Post by dikaiosune »

Glad to see improvements are coming! Articles like this make me more and more curious whether Fuchsia is an alternative bid to resolve relevant kernel vulnerabilities in a more centralized, architecturally driven fashion, not just a way to get out from under the GPL.

Re: Hardening the Kernel in Android Oreo

#55

Post by kllrnohj »

MBCook wrote: post #45
gsnedders wrote: post #29

Earlier quoted context omitted.

> 3.x kernels with security patches. What seems to be the issue? Limiting the scope of vulnerabilities before they are patched. There's plenty of more recent defence-in-depth work that will make some vulnerabilities impossible to exploit on more recent kernels, and while they will get patched on the older kernels it'd still be nicer if they weren't exploitable in the first place.

Even without that there are lots of power saving fixes that get put into Linux with every release. That kind of stuff seems like it be very important in a phone as well.

Given Android has its own power management story independent of what upstream is doing those power changes are unlikely to be relevant or significant to Android.

Re: Hardening the Kernel in Android Oreo

#56

Post by khc »

tetromino_ wrote: post #48
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?

OnePlus ships modern kernels. My OnePlus 5 is using kernel 4.4.21 - this is with Nougat 7.1.1, by the way; no Oreo here yet.

Ok I am very disappointing with Google in that case

Re: Hardening the Kernel in Android Oreo

#57

Post by petecox »

tbrock wrote: post #44
c2h5oh wrote: post #32

Earlier quoted context omitted.

Main reason is that there is a lot of hardware that never got binary blobs / drivers updated for newer kernels. We're talking input controllers, wifi, bluetooth, nfc chips, gyroscopes, amps and half a dozen other parts that never attempted to have drivers mainlined in Linux kernel. It's a chicken and egg problem - they won't make updated blobs until Android doesn't include newer kernel. Android won't use newer kernel…

It's not like more than 1% of android phones that have shipped to date will actually get an android update to Oreo anyway so why not leave them behind and update the kernel? New phones need new drivers which must support the new kernel, period. I don't see what the big deal is. You aren't getting Oreo on your old ass Samsung Galaxy S2 anyway.

Nougat runs fine on a Galaxy S2 with Lineage OS. I would not be unexpected for them to port Oreo eventually too.

Re: Hardening the Kernel in Android Oreo

#58

Post by MBCook »

kllrnohj wrote: post #55
MBCook wrote: post #45

Earlier quoted context omitted.

Even without that there are lots of power saving fixes that get put into Linux with every release. That kind of stuff seems like it be very important in a phone as well.

Given Android has its own power management story independent of what upstream is doing those power changes are unlikely to be relevant or significant to Android.

I know (vaguely) that android has its own power management system, and I don't know how much it ties into what the kernel uses on a standard laptop.

But the changes to the normal kernel one as well as some of the changes in data structures are algorithms designed to be more efficient in the first place are probably still useful.

Re: Hardening the Kernel in Android Oreo

#59

Post by zaphirplane »

structural wrote: post #53
kelnos wrote: post #26

Earlier quoted context omitted.

Yes, this was my first thought as I was reading the article. A better title for it would be "Backporting Modern Linux Kernel Features to Our Really Old Kernels Instead of Doing the Right Thing and Keeping Up To Date". I do -- I really do -- appreciate that version churn is difficult, and the Linux kernel also doesn't make it easy since they don't guarantee any stable internal APIs, but they're also adding a lot of wo…

If they are backporting features well, they're approaching kernel development very similarly to the datacenter. As an example, the standard server at $large-dayjob-server-farm runs on RHEL 6, with RHEL 7 (the latest release) being used for new machines. Both are still supported for quite a few years into the future. Let's look at their kernel versions: (per https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux ) "6.…

The comparison isn't fair you as a user of RH, expend an effort to upgrade and the benefits are often not clear so you don't

RH as a vendor has to backport because their users demand a long supported and modern-ish kernel

Google spend time and effort to backport and this story is discussing the benefits vs putting that effort in upgrading.

Your analogy isn't fair, thou obviously android's customers here are the device makers and they are tilting the balance towards backport

Re: Hardening the Kernel in Android Oreo

#60

Post by zaphirplane »

kelnos wrote: post #42
c2h5oh wrote: post #32

Earlier quoted context omitted.

Main reason is that there is a lot of hardware that never got binary blobs / drivers updated for newer kernels. We're talking input controllers, wifi, bluetooth, nfc chips, gyroscopes, amps and half a dozen other parts that never attempted to have drivers mainlined in Linux kernel. It's a chicken and egg problem - they won't make updated blobs until Android doesn't include newer kernel. Android won't use newer kernel…

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…

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.
Post reply on HN