With Android Oreo, Google Is Introducing Linux Kernel Requirements (betanews.com) 120
Mark Wilson shares a report from BetaNews: As is easy to tell by comparing versions of Android from different handset manufacturers, developers are -- broadly speaking -- free to do whatever they want with Android, but with Oreo, one aspect of this is changing. Google is introducing a new requirement that OEMs must meet certain requirements when choosing the Linux kernel they use. Until now, as pointed out by XDA Developers, OEMs have been free to use whatever Linux kernel they wanted to create their own version of Android. Of course, their builds still had to pass Google's other tests, but the kernel number itself was not an issue. Moving forward, Android devices running Oreo must use at least kernel 3.18, but there are more specific requirements to meet as well. Google explains on the Android Source page: "Android O mandates a minimum kernel version and kernel configuration and checks them both in VTS as well as during an OTA. Android device kernels must enable the kernel .config support along with the option to read the kernel configuration at runtime through procfs."
Re: (Score:2)
If the complete kernel configuration can be read, does this mean malware authors like NSA, CIA, criminals etc. will have an easier time getting inside your phone?
Obviously.
That's why I always use a Chinese android phone..... oh wait!
Re: (Score:3)
Hardware made in China, but the firmware, OS and software are made in the U.S.A. and other not-China countries.
Re: (Score:2)
Hardware made in China, but the firmware, OS and software are made in the U.S.A. and other not-China countries.
Is the hardware made in China now? I've seen breakdowns from when the iPad came out and the hardware was mostly made in Taiwan, Korea, and Japan and assembled in China.
Re: (Score:1)
Re: (Score:2)
Everyone use a chinese android phone.
Where do you think the SoCs come from?
Re: (Score:2)
Intel fabs? Taiwan (not Chinese) fabs?
Re: (Score:2)
Re: (Score:2)
Hong Kong?
Re: (Score:1)
Obviously.
To who?
Re: (Score:2)
Obviously.
To who?
Obviously a complete whoosh to the ass who downmodded. To make this perfectly clear: the "obviously" is flat wrong.
Re: (Score:2)
I'm not expert, but...
Actually, I think it is obviously true. Just not significant. Easier means a trifle less work, so there is less of a look-up required. Significantly isn't true, because library calls aren't that hard.
Re: (Score:2)
I'm not expert, but... Actually, I think it is obviously true. Just not significant. Easier means a trifle less work, so there is less of a look-up required. Significantly isn't true, because library calls aren't that hard.
Yes, it's clear you're not an expert. This fact is clear to all security experts: the bad guys do not give a rat's fuzzy behind how difficult an exploit is.[1] The only thing they care about is, is it possible. Essentially, the very first rule a security neophyte needs to learn is, there is no such thing as "making it harder". There is only possible and not possible.
[1] In fact, difficult exploits are preferred for a number of reasons, including bragging points.
Re: (Score:2)
Essentially, the very first rule a security neophyte needs to learn is, there is no such thing as "making it harder". There is only possible and not possible.
Making a brute-force search require 10000 centuries on average is just "making it harder", but it is in practice the same as impossible.
Re: (Score:2)
Essentially, the very first rule a security neophyte needs to learn is, there is no such thing as "making it harder". There is only possible and not possible.
Making a brute-force search require 10000 centuries on average is just "making it harder", but it is in practice the same as impossible.
Keep in mind, the boundary of what is vulnerable to brute force keeps moving, and quicker than you think. Anyway, omitting the kernel config is no serious obstacle to a skilled cracker, trust me.
Re: (Score:2)
Since you also have access to the kernel sources it would be easy to fake the interface and kernel version if you were to plan to use an unsupported kernel. Any problems would however be at your dime, not to be blamed on Android or Linus.
I can understand the minimum level requirements on the kernel and possibly also to allow the rest of Android to inspect the kernel configuration in order for the environment to be able to ensure that the platform it runs on is providing sufficient services. But these should
Re: Any experts who can elaborate on this? (Score:2)
Access to "the kernel source" is necessary, but mere availability doesn't necessarily assure the ability to build a working kernel for a particular device from scratch.
The sad fact is that many of the best Android ROMs at XDA are cut 'n paste "kitchen" ROMs that are no different from the way Windows Mobile ROMs used to be made, and plenty of others only run (limp?) with the phone's official OEM kernel.
Not even NEXUS phones are released with official build scripts capable of building the phone's complete 'st
Re: (Score:2)
Re:Any experts who can elaborate on this? (Score:4, Informative)
The Android OS is already running on your Android phone so what other code are you talking about?
This new Android Oreo requirement that the article is talking about only says that your kernel configuration must be made available via /proc/config.gz (CONFIG_IKCONFIG_PROC=y) which is readable by any user. It does not require any special script or code to read. It's a pseudo file that's a gzip compressed ASCII representation of the kernel's compile time configuration.
Re: (Score:2)
The Android OS is already running on your Android phone so what other code are you talking about?
I was answering a question. Don't expect to understand a conversation without understanding the context. Reading comprehension 101, fool.
Re: (Score:2)
You didn't answer their question. You made a loosely related statement that attempted to move the goal post of the argument to something new.
Here's their question:
"If the complete kernel configuration can be read, does this mean malware authors like NSA, CIA, criminals etc. will have an easier time getting inside your phone?" - Anon
Here's an answer:
No.
Google's intention for these changes is to facilitate faster patching of bugs and security vulnerabilities.
Re: (Score:2)
You didn't answer their question.
I did. I explained why it won't make it appreciably easier for the NSA/CIA/criminals to pwn your phone.
Re: (Score:3)
If the complete kernel configuration can be read, does this mean malware authors like NSA, CIA, criminals etc. will have an easier time getting inside your phone?
Not really. It seems to me all Google is doing is forcing Linux on these Android phones to behave closer to the way it already does on Linux servers and desktops.
Linux has never been about security through obscurity - that's just weirdness introduced by certain handset manufacturers.
Re: (Score:2)
Re: (Score:1)
It does help third party developers keep older phones updated with newer kernels. Starting with a known kernel config is a huge time saver.
Re: (Score:2)
If the complete kernel configuration can be read, does this mean malware authors like NSA, CIA, criminals etc. will have an easier time getting inside your phone?
Marginally. This helps the good guys way more than the bad guys. More precisely, obfuscating the kernel configuration closes exactly zero attack vectors, but does inconvenience detecting and removing malware, not to mention normal maintenance.
Re: (Score:2)
That you can't use the word "mandate" because it has the word "man" in it and that's a micro-aggression towards women in tech.
And "date" because its meaning either has sexual connotations or is ageist.
Re: (Score:2)
And when you use the two words together you get a "man date", which is coercion toward women, forcing them to use their phones wether they want it or not.
Re: (Score:2)
Let me just insert this here (Score:4, Funny)
I take offense at your use of "micro." You are impugning my manhood. My aggressions are a "good size." She told me so and that's why I know it's true.
Re: (Score:2)
That's impossible, this is slashdot, everybody has Data A Live running in a loop in the "living-room" half of the basement.
No deto, no social life. You can't take that away from them. Let them have their deto.
systemd here we come! (Score:1)
Re: (Score:2)
Whoooppeeee!
All we need now is Wayland and the Unity desktop
Already done (Score:2)
Re:systemd here we come!
All we need now is Wayland
Congratulation, you've successfully described Jolla's Sailfish OS....
and the Unity desktop
...and Canonical's attempts at Ubuntu Touch.
Re: (Score:1)
Gnome 3 bloat with all normal functions removed (you'll add them with extensions and addons that breaks when there's a new update)
echo "3.18" > /proc/version (Score:2)
I know it's a little more complicated than that, but I know that some of those handset devs will be tempted to try just modifying the kernel number to pass the test.
Re: (Score:2)
Then some app comes along that needs to do something different depending on kernel version, and uses the 3.18 which fails
App devs are practical, however, and will figure it out and add more specific tests. If they don't, they lose sales.
Re:echo "3.18" /proc/version (Score:2)
# echo "3.18" > /proc/version
bash: echo: write error: Input/output error
(because /proc/version is r/o)
Re: (Score:2)
Re: (Score:2)
What's weird though is that echo /proc/version yielded /proc/version even though kwrite /proc/version got the correct info.
Re: (Score:2)
Thanks. I thought that /proc/version was returning a text string, though in that case one has to wonder why I even tried kwrite.
ok (Score:5, Informative)
So, they want you to run a kernel that is younger than two years old, and they want to be able to see which features it has enabled. Both perfectly reasonable requirements, most likely based or real engineering issues.
Re: ok (Score:5, Informative)
Except that also means even older NEXUS devices might not be able to run newer versions once Google EOLs them. Remember, Linux kernel modules are specific to not only a particular VERSION of Linux, they're specific to a particular combination of build options on specific hardware (in contrast to Windows, which in many cases can be coaxed into using drivers that are literally 20 years old due to Windows' strong hardware abstraction).
AOSP might be open-source, but a real-world Android device built around a Qualcomm SoC is still 100% dependent upon Qualcomm making new binaries available (at least, if you want the radio modem, wi-fi, bluetooth, gps, camera, OpenGL ES, and everything else to work, too).
Re: ok (Score:4, Informative)
Which is, strangely enough, what this is all about.
Project Treble, basically a hardware abstraction layer to stop the SoC manufacturers holding up patching etc.
(https://source.android.com/devices/architecture/treble)
Re: (Score:2)
So you're saying Google will make an exception to the kernel requirements for themselves? Great way to be open and fair with other vendors.
Re: (Score:3)
Re: (Score:2)
Good post, except that Linux does not have user space device drivers, with a few exceptions such as X11 and FUSE. Especially where performance is an issue, kernel drivers are far superior. Many of the APIs you need to write a fully capable device driver, such as registering an interrupt handler, are simply not exported to user space. Lucky for you.
CUPS and SANE (Score:2)
Good post, except that Linux does not have user space device drivers, with a few exceptions such as X11 and FUSE.
Technically correct, as user-space driver subsystems like CUPS (for printing) and SANE (for scanning) don't depend much on anything specific to Linux proper. They're used with GNU/Linux, but they're also used with (say) FreeBSD.
Re: (Score:2)
You're right that CUPS drivers are in some sense device drivers. Of course those are stacked on top of "actual" hardware drivers that access the USB port, parallel port, etc.
Re: (Score:1)
It's shit just like the other mobileOSes!!!
3.18? (Score:4, Insightful)
With v4.13 [phoronix.com] just released!
It's a really new OS, then!
Re:3.18? (Score:5, Informative)
From the referenced page "All SoCs productized in 2017 must launch with kernel 4.4 or newer."
So it is only somewhat old, with a transition period to reduce the pain on their downstream.
More important is the signal that it sends to the manufacturers that they need to be using a recent kernel, not the dusty 2.6 they have on the shelf. A manufacturer designing a product now for launch in 2018/19 will be penciling in something much more recent, like the future 4.15 release, to ensure that they don't get caught out as Google steps the requirements.
Re:3.18? (Score:5, Informative)
Linux kernel drivers that are not open source are pure cancer. Lack of standard configuration specification and control methods are a secondary cancer. Given the state of things on non-x86 platforms, I'm surprised OpenWRT works at all. Bless those poor glorious developers at OpenWRT.
Re: (Score:3)
The biggest problem with Android in particular and SoC platforms like ARM or MIPS is that all the hardware stuff is closed off and there are no standards
The ARM subsystem was refactored [lwn.net] a few years back in view of this. There are perfectly good reasons why SoC can benefit by doing its own thing, but the general trend is in the direction of commonality, which lowers engineering costs for everyone in the long run.
Re: (Score:1)
How about Android 8, my slow, challenged friend?
The full list of requirements (Score:1)
All SoCs productized in 2017 must launch with kernel 4.4 or newer.
All other SoCs launching new Android devices running Android O must use kernel 3.18 or newer.
Regardless of launch date, all SoCs with device launches on Android O remain subject to kernel changes required to enable Treble.
Older Android devices released prior to Android O but that will be upgraded to Android O can continue to use their original base kernel version if desired.
step in the right direction (Score:3)
some phones use really horrible outdated kernel versions, mostly because they have blobs in them that aren't updated.
this is a good step in the right direction, but google could still do more.
Surprising... (Score:1)
I'm actually surprised that Android was (is, 3.18 is 2.5years old!) permitted to use old kernels with all the bugs they had (unauthorised remote access was rarely a problem... but quite a few bugs allowed privilege scalation provided physical access, and a phone is not a computer room).
Trying to kill Custom Firmwares? (Score:3, Insightful)
If Google wanted to be serious about this they had to at least demand of OEM's to publish hardware blobs from now on for newer kernels. But it seems that this action is just another another step by big G to help the OEM's to accomplish more easily their planned obsolescence for any device which is over a year old.
Re: (Score:2)
You have two choices, here. Stop using Android or stop using smartphones.
Re: (Score:3)
Ars think that Project Treble will make custom builds easier, not harder https://arstechnica.com/gadget... [arstechnica.com]
(I dunno I haven't used done the legwork to form an opinion)
Re: (Score:2)
You have this backwards. The goal here is to attempt to eliminate this tying of binary blobs to a kernel in a way that prevents updating. This should make it easier to do custom builds in the future.
Re: (Score:2)
You do realize that this is only a requirement for hardware manufacturers who want to bundle Google apps with their devices right? So far these apps don't even check much if you download them from the web and sideload. But even if some of them do in future, you can still install amazon app store and runs tons of other stuff.
Re:Trying to kill Custom Firmwares? (Score:5, Informative)
This seems to me like a major hindrance for developers of custom firmwares.
(Google Android engineer here, though please note that I don't work on either the kernel, or Treble, so take my comments with a grain of salt. I do own a couple of important Android hardware abstraction layer interfaces, and the client code that uses them, so I'm a knowledgeable user of Treble.)
This kernel version requirement should have no impact on developers of custom firmware, positive or negative. Project Treble, however, should make the lives of custom firmware developers much better.
Treble forces a hard boundary between /system and /vendor + kernel[1], with a consistent, tested interface between the former and the latter two components. This means that even after an OEM stops updating the kernel and hardware blobs, you will still be able to flash new system images, either official ones or custom, because those system images will have a fixed, reliable interface to the hardware using the kernel and firmware already on the device.
This doesn't mean that we want OEMs to ignore updates to kernel and hardware blobs. Security patches to those components are crucial -- especially the kernel, since that's where all of the most severe Android vulnerabilities are found. But the idea is to break the functional interdependency between specific kernel and firmware versions and the system that sits atop them, so the system can be updated at will even if the bottom layer is never updated.
This means that if you buy a phone that launches with Oreo, and can unlock the bootloader, you should be able to flash pure AOSP Oreo onto it instead of the OEM's system. Further, you should be able to customize AOSP in whatever way you like... and you should still be able to continue doing this when P, or Q, or S, etc., lands in AOSP.
Clearly there will have to be some point at which AOSP simply drops support for old hardware abstraction layer versions, and at that point the /vendor on your device will be providing APIs that AOSP refuses to use, so it'll stop working without heavier customization.
So what is the kernel version requirement about if it's all hidden behind a strong hardware abstraction boundary anyway? Security. As I said above, the most serious vulnerabilities we see in Android today are pretty much all in the kernel. If OEMs use ancient kernel versions, that means that all kernel security bugs have to be backported to those old versions. Such backporting is tedious and error-prone, and many OEMs -- especially smaller ones -- simply don't have the expertise to do it, so they don't. Google does a lot of kernel security patch backporting, but there are limits to how far back Google's engineers can reasonably support. By forcing OEMs to get onto more-current kernel versions, Google is better able to ensure that patches are at least made available to OEMs.
Note that this still will not force OEMs or carriers to actually deliver the patches. There are other initiatives under way that focus on trying to do that, but the first step is for Google to make it easy for them to apply the patches. That's what the kernel version requirements are about, setting up a situation where Google can provide the patches so OEMs can deliver them.
[1] I assume that "Treble" is a reference to the treble/bass line distinction in music, including the punning of "bass" with "base". So the /vendor partition, with all of the firmware blobs and implementations of the hardware abstraction layer APIs, plus the kernel, is the "base/bass", on which the code from the /system partition (treble) depends. Project Treble is about defining a bass line with consistent characteristics, to allow the melodic treble line to be swapped out at will, to replace an OEM melody with an AOSP melody or even a custom melody. Yeah, the musical analogy is a bit of a stretch, but it's still useful. And it's not even that much of a stretch, since some genres of music do have common bass lines which underlie a wide variety of melodies and even melodic structures.
Re: (Score:3)
Wouldn't a better solution be Google requiring the bootloader code to all be free and open source, and all phones to be rootable?
The biggest problem with Android right now is how vendors lock down phones and don't give the users control over the devices they literally own.
Re:Trying to kill Custom Firmwares? (Score:4, Interesting)
Wouldn't a better solution be Google requiring the bootloader code to all be free and open source, and all phones to be rootable?
I won't go into detail because I'm not sure how much I can actually say, but I'll just point out that Google has to walk a very fine line. Every player in the ecosystem understands Google's role in ensuring compatibility across the ecosystem, so they're willing to accept Google's imposition of the compliance test suite (CTS). Which isn't to say they don't grumble about it and roll their eyes when they think Google is quibbling over minor details that they think don't matter, but they accept.
And I think they'll be willing to go along with the new form of compatibility demanded by Treble and the vendor test suite (VTS). CTS ensures that apps run on all Android devices. VTS aims to ensure that future versions of Android run on all Android devices (up to a point).
But there are real limits. Android is open source, and any of the big players, or a consortium of smaller ones, could fork Android and run with it. If Google steps too far out of the compatibility-enforcement role and starts trying to dictate how OEMs can do business with their customers (the carriers, mostly), the OEMs absolutely will fork Android. You think there are fragmentation problems now? And how much do you think those leading the new fork(s) will care about unlockable bootloaders?
So Google has to step lightly with mandating anything outside of compatibility. And by "step lightly" I pretty much mean "not do it". What we can do is to try to engineer things so it's easier for OEMs to do the right thing, but if they don't want to, or carriers don't want them to, we can't make them.
BTW, one note on your use of the word "rootable". That's the wrong word. Rooting is neither necessary nor sufficient to actually take control of your device. Thoroughgoing application of SELinux is actually making rooting irrelevant. Since root can't violate the SELinux restrictions, it can't really do much anymore anyway. I think we're not too far from making root just another user.
No, what you want is to be able to unlock the bootloader so you can flash custom images to it. Your custom images, of course, can eschew SELinux and make root all-powerful again, if that's what you want (though it's a bad idea, and I strongly recommend against it). But the key is that with the bootloader unlocked you can do whatever you like with the device.
Re: (Score:2)
Thanks for your kind response.
All this was prompted by my phone randomly disconnecting and reconnecting when charging, which means late at night the screen turns itself on and off, waking me up. Google has apparently made no provision for a setting to turn off the screen when a charger is connected. The best you can do is download an app that will quickly turn the screen back off, but it will still flash randomly in a dark room, and this is annoying.
I want the ability to go through the source code for the k
Re: (Score:2)
in the current ecosystem, it is basically impossible unless you have an unlocked device. Please correct me if I'm wrong.
You are correct. My recommendation is to make bootloader unlockability a must-have feature when buying your next device. Sorry I can't offer more.
Re: (Score:1)
Re: (Score:3)
I realized that it could be just a way to allow OEM's to update their firmwares more easily without much effort on their part
In fact, the goal is to give OEMs the option to turn updating over to Google, making it literally zero effort (and cost!) for them. That's a pretty big step, though, so I don't think it will happen quickly, and when it does happen it will probably be second- and third-tier OEMs that do it. I hope I'm wrong on that last part.
It is quite obvious that almost all OEM's and hardware manufacturers have it on their business plan to not update older capable devices in order to force the users to change them frequently.
It may be "obvious", but it's simply not true, not that I've ever seen, and I've talked to a lot of people at a lot of OEMs.
That actual reason they're reluctant to do updates is not fo
Safetynet enforcement plot? (Score:1)
I wonder how much is to simplify life for project Treble, and how much to fuck everyone with safetynet?
Right now you can defeat the safetynet checks by having the kernel not report on the bootloader lock/unlock status, but if you enforce a 4.4.x kernel as well as publishing the config, safetynet will check the bootloader status and will see from the config if the kernel is reporting it or not. If unlocked or configured to not report it, safetynet will fail the basic checks.
This will quickly kill custom ROMs
Android O (Score:1)
Android? Oh.
best option for an Oreo kernel (Score:1)
CONFIG_DOUBLE_STUF
cause you know more is always better...
Funny - how are they enforcing this (Score:2)