We are excited to let you know about the refresh of the Android-IA project called Celadon. Celadon is the open sourced Android reference stack for Intel architecture that you are already familiar with, but now with more added to the stack. What started with a few open source drivers support including Mesa i965, I915 Linux Kernel Graphics Driver, and Video Acceleration API last year has since grown into a feature-rich Android stack for IA. Celadon will continue to be dedicated to driving Android support and innovation on IA in addition to providing a place for collaboration. We believe Celadon can help you enhance validation, debug and accelerate development across Android implementations on IA platforms.
Ilya Bizyaev posts on the Intel Android-IA mailing list about working to get Halium port of the ASUS ZenFone5:
I am writing to announce that I am working on a Halium (halium.org) port for ASUS ZenFone 5, a Clovertrail+ based phone. Porting Halium base to this Intel platform enables numerous open-source projects, including Ubuntu Touch (ubports.com), Plasma Mobile (plasma-mobile.org), LuneOS (webos-ports.org) and Mer (merproject.org) to use all of the Clovertrail+ devices for development and testing. I am proud to report that as of now, the Halium build system supports using custom Intel boot tools, and the device boasts a stable 3.10 kernel and Android 7.1-based system build that has Wi-Fi, touch sensor, hardware keys, LEDs and vibrator working.
Full post: email@example.com archives.
Hmm, I didn’t know about Halium…
From the Halium blog’s initial post:
Over the years, various efforts have been made to bring GNU/Linux to mobile devices (for example Maemo, Meego, Mer, SailfishOS, Ubuntu Touch, Plasma Mobile). They have either achieved their individual goals or are working in direction of achieving them. During the development of such projects it was suggested multiple times that these communities should work together as their ultimate goal is the same. However due to various reasons this never happened in the past. However we believe that it is time to change this situation. Currently distributions like AsteroidOS, LuneOS, Mer, Plasma Mobile, SailfishOS, and Ubuntu Touch have one thing in common that they use the libhybris to interact with the android binary blobs and they also run the various android daemons using different methods. And there is lot of fragementation on how this task is handled even though these parts don’t need to be different as their essential goal is to make use of android binary blobs. Project Halium is the effort by the community which aims to bring the common grounds for different distributions and have a common base which includes the Linux kernel, Android Hardware Abstraction Layer, and libhybris. Project Halium also aims to standardize the middlewares used to interact with the hardware of the device. By having these parts shared, we believe that it will reduce the fragmentation we have currently.[…]
Intel makes LUV, Linux UEFI Validation, to test Intel UEFI systems’s implementations. Intel also makes CHIPSEC, to test Intel x86/x64 BIOS/UEFI implementations for security issues, a firmware vulnerability management tool. Intel also makes Android-IA, the Intel fork of Android. It only boots via UEFI.
However, you apparently cannot use the Intel UEFI diagnostics (eg, LUV, CHIPSEC) to test Intel Android-IA systems. You can’t boot into LUV, and CHIPSEC doesn’t target Android. From a thread on the Android-IA mailing list on 01.org, on the topic of diagnosing a Baytrail-based Android-IA tablet, Christopher Price of Console OS mentions:
Production Intel Android devices do run UEFI, but it is for the most part today locked down. The only UEFI loader accepted triggers Android fastboot, which is baked into the UEFI payload. Secure Boot is on, basically – with no way to turn it off. Unfortunately, this cannot be unlocked today, as production Android devices do not respect the fastboot oem unlock command… aside from IRDA devices like the Trekstor tablet. Even IRDA does not have a UEFI config menu for the most part – it’s very locked down and meant to only run the UEFI apps related to fastboot and firmware updates. […]
And, as I understand it, Trekstor tablet is the only consumer device which permits users to configure things.
How do you test a device if can’t boot a clean OS to do diagnostics? With Secure Boot, it seems that they’ve forgotten that NIST permits owners to control their system locally, and make firmware and OS levels unmodifyable. OEMs can use their unlocked prototype boards to test security, but consumers have no option to test their device for security, in the name of boot lockdown security, with no way for user to configure.
How do sysadmins defend IoT things that you can’t run the only firmware security tools on them? Are Android-IA devices — except for some Trekstor tablets apparently — examples of the ‘undefendable’ subset of the IoT? How can an enterprise have a security policy to defend undefendable devices?? Do IoT vendors think about sysadmins, or just developers? How do I perform all of the recommended steps in the NIST SP-147 secure BIOS platform lifecycle, on IoT devices like this?
The firmware level of IoT devices are obscured by overloading firmware to mean all software on an embedded device, firmware security is a synonym for OS security or App security for embedded devices. 😦
With Microsoft hinting that Secure Boot will soon no longer be configurable, this seems like it’ll just get worse.
This issue impacts all architectures’s IoT devices, not just Intel Android-IA-based, UEFI-based devices.
If I had a Twitter account, I’d be spending half of my time online forwarding posts to the Internet of Shit account, sigh. 😦
Console OS is an Intel-based Android-based operating system that is funded via Kickstart. Before you fund/use it, please read this thread, starting with a message from Android-x86’s project leader:
[CC this to Android-IA list since the guy continues lying on Android-IA list]
Honestly speaking, I really have no time to check what Christopher Price and his crappy Console OS did recently. But I’m getting more and more private requests to ask me to stop him from stealing the Android-x86 effort. So as the project leader of the Android-x86 project, I think I need to do something. As a background for new comers who haven’t heard the story of Console OS, here is a brief: […]