
Hardening the Kernel in Android Oreo - ingve
https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html
======
mrhigat4
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/](https://copperhead.co/android/)

[1]: [https://www.postmarketos.org/](https://www.postmarketos.org/)

~~~
kelnos
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 work on themselves by having
to maintain their own kernel trees that diverge significantly from mainline.
They're also at the mercy (to some extent) of many chipset manufacturers and
whatever they've chosen to base their efforts on.

A quick look at some kernel release timeframes from the versions they mention
in the article:

    
    
        4.3  - 11/2015
        4.4  - 02/2016
        4.6  - 05/2016
        4.8  - 10/2016
        4.10 - 02/2017
    

The only kernel out of that list I'd unquestioningly accept as it being
unrealistic to upgrade to for Oreo is 4.10. 4.8 might be a stretch since I'm
guessing they'd already branched internally for Oreo by then, though they
likely had a month or so of RCs that they could have used as a base before
that. There's certainly risk to basing your work on a newly-released (or soon-
to-be-released) kernel, but given the general high quality of kernel releases,
I imagine that'd be pretty far down on their list of risks. Regardless, 4.6 or
4.7 would be entirely reasonable to use as a base, and since they own the
conformance test criteria, they could also require that all their vendors use
that as a minimum version.

And yet, they are backporting some features as far back as 3.18, which was
originally released in December of 2014, and, while it was designated a LTS
kernel, it, at this point in time, has moved into end-of-life status. And we
wonder why Android security is a nightmare.

~~~
c2h5oh
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 because that
would block 2/3 of the phones from being upgraded because of Broadcom
bluetooth chips alone - Samsung might decide they are better off forking
Android than waiting for Broadcom.

Edit: Sony has a bunch of phones that can run on 4.4 kernel:
[https://developer.sonymobile.com/open-
devices/](https://developer.sonymobile.com/open-devices/)

~~~
kelnos
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 of effort, but keeping it
up-to-date as new kernel releases happen will not, at least in the vast
majority of cases.

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

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

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

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

------
limeblack
Glad we are making it more secure. On a side note I love that we now have
[https://googleblog.blogspot.com/index.html](https://googleblog.blogspot.com/index.html)
[http://blog.google](http://blog.google) and [https://android-
developers.googleblog.com/](https://android-developers.googleblog.com/) and
[https://googleblog.blogspot.com/](https://googleblog.blogspot.com/) (which
redirects to blog.google without index.html because it appears to be the new
site) which is slightly weird.

~~~
Pharaoh2
Did you mean [https://www.blog.google/](https://www.blog.google/)?

~~~
ehPReth
Hmm, I recall this being a much cleaner
[https://blog.google](https://blog.google) before. I wonder why they added
www. after some time? Anyone happen to know the story?

------
MBCook
Great to see Google linking to the LWN articles on these features. I always
like to see LWN get noticed for their fantastic kernel work.

It's the primary reason I've been a subscriber since they introduced
subscriptions all those years ago.

------
khc
"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?

~~~
trthomps
I also have 3.18 on my Pixel XL. I assume the unreleased Pixel 2 devices will
be running kernel 4.4 if that's what they targeted.

They probably wanted to back port it to 3.18 but it was too much work. I'm
pretty disappointed they didn't move the Pixel forward to a new kernel though,
this seems to be one of the biggest issues with Android.

~~~
wmf
This is an interesting case study in development cycles. The Pixel XL from
October 2016 uses the Snapdragon 82x released in July 2016 but first announced
in March 2015 and it uses a kernel from 2014 which gives us a hint about when
driver development started.

------
pjmlp
Nice set of features, that the majority of Android users will only get in a
few years.

Maybe we should start making bets if Android Oreo be able to beat Nougat and
be above 13.5% next year this time around.

~~~
limeblack
You probably know this but because of project Treble for future versions after
Android Oreo will probably be adopted more quickly. It is unlikely for Oreo to
do much better then Nougat then from what I have read.

~~~
pjmlp
Anyone beliveing that project Treble will change anything should listen to the
ADB Podcast about it.

[http://androidbackstage.blogspot.de/2017/08/episode-75-proje...](http://androidbackstage.blogspot.de/2017/08/episode-75-project-
treble-for-hal-of-it.html)

Key points:

1 - Google will keep on allowing OEMs to customize Android

2 - OEMs will keep being responsible for delivering updates

3 - OEMs are advised to push fixes upstream and provide updates

Given that they are just advised, and not required to act accordingly, do you
want to bet how many will provide Treble updates instead of selling new
handsets?

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

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

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

------
srcmap
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 can
audit/monitor/report/google where it comes from.

In Windows 10, I use netstat to monitor all TCP connections and get the name
of the programs and configure the windows firewall to only allow Windows
Firewall/Firefox and Chrome to access internet and block
IE/Edge/svchost/SearchUI and countless other SW from access internet. My
system is so much faster and stable, after I did this.

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

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

------
tptacek
For similar content but in much greater depth, this is a pretty excellent
series of blog posts:

[https://outflux.net/blog/archives/2017/07/10/security-
things...](https://outflux.net/blog/archives/2017/07/10/security-things-in-
linux-v4-12/)

~~~
nur0n
can you recommend any other blogs like this?

------
bhhaskin
I really wish Ubuntu touch was more complete. I would switch in a heart beat.

~~~
duskwuff
Don't hold your breath. The project was effectively cancelled in April.
There's theoretically a "UBPorts" project that may continue development, but,
without any sort of company backing it anymore, I doubt that it's going to
have much of an impact.

[https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-
cl...](https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-
iot-rather-than-phone-and-convergence/)

~~~
petecox
'theoretically?' It's happening, albeit without a corporation behind it.

They have a weekly youtube vodcast, if you're curious, and a Patreon page with
a couple of hundred subscribers.

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

~~~
_pmf_
Switching to Fuchsia (which will never happen because it is a toy project to
occupy bored engineers) does not magically solve the problem that device
vendors want to minimize the work in maintaining their drivers. Even enforcing
open source drivers (for the sake of discussion) will not help, because at a
certain complexity, the device driver writer requires knowledge about
undocumented internals of the device that is just not available outside the
manufacturer.

There must be an economic incentive for device manufacturers to
maintain/update their drivers, otherwise it cannot happen. Users want to buy
new devices, not pay directly or indirectly for updating their old devices;
this basically seals the deal.

~~~
afsina
Toy project? I doubt that. There is frantic work going on by perhaps more than
a hundred engineers if I am not mistaken: [https://fuchsia-
review.googlesource.com/](https://fuchsia-review.googlesource.com/)

------
lima
No credits given to the PaX Team / Grsecurity :(

(PAX_USERCOPY)

~~~
gcp
Are you surprised given the highly public pissing war that has been going on
between Google's kernel engineers, Brad Spengler, and the PaX people?

~~~
lima
Yes. I'd expect them to take the high road and give credit.

------
nsxwolf
Did they have to license the name?

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

~~~
acdx
Google extremely obviously did not use the name Oreo without asking for
permission

~~~
KGIII
From the last time this was asked, they asked permission. With KitKat, they
paid - someone linked a citation for it but it's not in my history.

~~~
snorlaxle
What I read at the time is that no money was paid to anyone. Hope you find the
linked citation

[https://techcrunch.com/2013/09/03/google-strikes-bizarre-
lic...](https://techcrunch.com/2013/09/03/google-strikes-bizarre-licensing-
deal-with-nestle-to-name-next-android-kit-kat/)

~~~
KGIII
I stand corrected. Well, at least I am not seeing their source.

------
tobiaswk
Hardening an old turd.

