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.
Full message:
https://lists.01.org/pipermail/android-ia/2016-January/001135.html
https://01.org/android-IA
https://github.com/android-ia
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. 😦