<story><title>Hardening the Kernel in Android Oreo</title><url>https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html</url></story><parent_chain><item><author>mrhigat4</author><text>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.&lt;p&gt;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.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;copperhead.co&amp;#x2F;android&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;copperhead.co&amp;#x2F;android&amp;#x2F;&lt;/a&gt;&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.postmarketos.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.postmarketos.org&amp;#x2F;&lt;/a&gt;</text></item></parent_chain><comment><author>kelnos</author><text>Yes, this was my first thought as I was reading the article.  A better title for it would be &amp;quot;Backporting Modern Linux Kernel Features to Our Really Old Kernels Instead of Doing the Right Thing and Keeping Up To Date&amp;quot;.&lt;p&gt;I do -- I really do -- appreciate that version churn is difficult, and the Linux kernel also doesn&amp;#x27;t make it easy since they don&amp;#x27;t guarantee any stable internal APIs, but they&amp;#x27;re also adding a lot of work on themselves by having to maintain their own kernel trees that diverge significantly from mainline.  They&amp;#x27;re also at the mercy (to some extent) of many chipset manufacturers and whatever they&amp;#x27;ve chosen to base their efforts on.&lt;p&gt;A quick look at some kernel release timeframes from the versions they mention in the article:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    4.3  - 11&amp;#x2F;2015
    4.4  - 02&amp;#x2F;2016
    4.6  - 05&amp;#x2F;2016
    4.8  - 10&amp;#x2F;2016
    4.10 - 02&amp;#x2F;2017
&lt;/code&gt;&lt;/pre&gt;
The only kernel out of that list I&amp;#x27;d unquestioningly accept as it being unrealistic to upgrade to for Oreo is 4.10.  4.8 might be a stretch since I&amp;#x27;m guessing they&amp;#x27;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&amp;#x27;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&amp;#x27;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.&lt;p&gt;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.</text></comment>
<story><title>Hardening the Kernel in Android Oreo</title><url>https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html</url></story><parent_chain><item><author>mrhigat4</author><text>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.&lt;p&gt;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.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;copperhead.co&amp;#x2F;android&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;copperhead.co&amp;#x2F;android&amp;#x2F;&lt;/a&gt;&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.postmarketos.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.postmarketos.org&amp;#x2F;&lt;/a&gt;</text></item></parent_chain><comment><author>tadfisher</author><text>Agreed, but let&amp;#x27;s point fingers at the whole stack if we want this to happen.&lt;p&gt;Treble [0] will finally add a HAL to the base system, so updates to the kernel and drivers should in theory be easier on devices that ship with 8.0 (of which there are exactly zero so far). So at least Google&amp;#x27;s on the right track.&lt;p&gt;But Google doesn&amp;#x27;t create the drivers and Google doesn&amp;#x27;t ship the board support packages which vendors build upon. And so we come to Qualcomm, Samsung, Mediatek, and whoever else is shipping proprietary drivers for their SoCs and radios, and who don&amp;#x27;t provide binaries for new ABIs.&lt;p&gt;The workaround is libhybris, which Ubuntu Touch, Sailfish, and now PMOS are using to support drivers built against Android kernels and its userspace, but that is so fraught with issues that it can&amp;#x27;t possibly be supported by Google or the vendors.&lt;p&gt;So we have Android 8.0 shipping with a 4.4 minimum to support the lowest common denominator of BSPs, and it kind of has to be that way until some market force changes the landscape. I don&amp;#x27;t have high hopes for either of the projects you mentioned, sadly.&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;source.android.com&amp;#x2F;devices&amp;#x2F;architecture&amp;#x2F;treble&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;source.android.com&amp;#x2F;devices&amp;#x2F;architecture&amp;#x2F;treble&lt;/a&gt;</text></comment>