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

101–108 of 108 posts

Re: Hardening the Kernel in Android Oreo

#101

Post by _pmf_ »

yahna wrote: post #100
_pmf_ wrote: post #84

Earlier quoted context omitted.

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

I'm insure about who has the upper hand, but I feel like SoM manufacturers know what they are doing and are where they are based on merit whereas Android is there because it was available when it mattered and gained momentum, not because of any technical merit. Android as a developer ecosystem is a train wreck. I have better tooling for deeply embedded bare metal platforms than I have for Android userspace applications.

Re: Hardening the Kernel in Android Oreo

#106

Post by kelnos »

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

Apple seems to have no problem keeping drivers/blobs for their hardware working when they release new versions of iOS. Sure, they do have the advantage of tight control over their hardware and core software, and a vastly smaller number of pieces of hardware to target, but in that way they're not that much different than any random Android vendor, hardware-wise. Sony (for example) is perfectly capable of only choosing vendors that can keep up with kernel versions, or at least vendors that will be open enough with them (not even with the public, just Sony) so that Sony can hire a software team to keep things up to date.

But they don't care enough about this sort of thing (unlike Apple), and no one (such as Google) is forcing them, so it won't get done unless they see an economic upside.

Re: Hardening the Kernel in Android Oreo

#107

Post by kelnos »

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

That's a very good point.

My understanding, though, is that RH etc. do that mainly for stability reasons. Their customers don't want latest-and-greatest, they want small evolutions of the stuff they know works, with only bug-fixes and must-have new features.

Of course, that comes with downsides too: build your infra on RHEL 6.x, and then once 6.x becomes end-of-life, upgrading to the new latest release is a huge undertaking.

I think RHEL is doing the right thing because it's what their customers want; I would argue that in many cases their customers are doing the wrong thing and should make more-frequent, smaller upgrades rather than one giant upgrade twice a decade. But that's certainly open for debate and reflects only my experience managing infra ;)

With something like Android, I'd expect the pendulum to swing a bit the other way: you don't want bleeding-edge or unstable, but you probably do want something quite a bit more up-to-date than something that RH pushes out. To use your example, I'd say releasing a phone in 2017 based on 2.6.32 (released nearly 8 years ago!), even with 696 patch releases, would be unacceptable.

But yeah, where do you draw the line at acceptability? I personally think you shouldn't be going with a kernel release whose series was released more than a year or so before you start development (assuming getting to a release is going to take 6-12 months from that point), and ideally you just take whatever is the latest stable when you start development, if that's possible. Sure, opinions differ, but that's kinda the point... this is my opinion :)

Re: Hardening the Kernel in Android Oreo

#108

Post by lima »

gcp wrote: post #104
lima wrote: post #102

No credits given to the PaX Team / Grsecurity :( (PAX_USERCOPY)

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?

Yes. I'd expect them to take the high road and give credit.
Post reply on HN