Secure Booting Android-x86

1,550 views
Skip to first unread message

Charles Milette

unread,
Jan 16, 2016, 4:15:20 PM1/16/16
to Android-x86
Could the next version use the Microsoft signed shim ("shim-signed" package in Ubuntu) for loading Canonical's signed GRUB ("grub-efi-amd64-signed" package in Ubuntu)? I have secure boot activated on my computer, and I don't want to disable it for security measures. Also, when GRUB2 EFI is installed:

bootx64.efi -> Microsoft-signed shim
grubx64.efi -> Canonical's signed GRUB

That would allow to use secure boot for booting into Android even after the install. Also, the installer tries to install GRUB in the first partition, but on default Windows installs, this is the WinRE partition (I broke Windows' automatic repair and currently hoping that the next Insider update will install a new WinRE). EFI is second. Checking the GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B on GPT and the 0xEF ID in MBR for finding the EFI partition is the best way to accurately locate it.




Also, on the next release, signing the kernel and the initramd.img and providing the public key for regitering into shim's MOK would be great, it would allow GRUB to verify Android before booting instead than blindly boot into it and therefore expose to viruses. (The UEFI specification wants that when secure booting, each stage checks the next before booting it, and GRUB actually doesn't check, it just blindly boots the next stage)

Povilas Staniulis

unread,
Jan 16, 2016, 4:38:16 PM1/16/16
to andro...@googlegroups.com
If you really care so much about secure boot, you should really get a spare system for testing Android.
(or reduce your virus fear level...)
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

Charles Milette

unread,
Jan 16, 2016, 4:46:39 PM1/16/16
to Android-x86
If you really care so much about secure boot, you should really get a spare system for testing Android.

I don't want to test Android on my machine, there are plenty of testers already, I want to use it.

(or reduce your virus fear level...)

Too much is better than too little
 

Povilas Staniulis

unread,
Jan 16, 2016, 4:56:16 PM1/16/16
to andro...@googlegroups.com
On 2016.01.16 23:46, Charles Milette wrote:
If you really care so much about secure boot, you should really get a spare system for testing Android.

I don't want to test Android on my machine, there are plenty of testers already, I want to use it.

Well then wait until someone provides a signed kernel.
Or just use what is available.



(or reduce your virus fear level...)

Too much is better than too little

Well, all secure boot really does is prevent you from booting stuff not signed by MS. It is not an antivirus.

Charles Milette

unread,
Jan 16, 2016, 5:21:14 PM1/16/16
to Android-x86

Well then wait until someone provides a signed kernel.
Or just use what is available.

I'm gonna cite myself:

"Also, on the next release, signing the kernel and the initramd.img [...] would be great"


 
Well, all secure boot really does is prevent you from booting stuff not signed by MS. It is not an antivirus.

Wrong, secure boot is fully customizable (You can add your own keys) and specified in the UEFI Specification, it is just that almost all computers includes Windows and therefore where configure to boot Windows with Secure Boot activated. Almost all Linux distros uses secure boot. It is not an antivirus, I agree, but it is a good protection for virus trying to infiltrate the boot process

Making Android compatible with Secure Boot would allow to install and boot it on ARM computers, the secure boot and it's database being locked at it's default on those.

Povilas Staniulis

unread,
Jan 16, 2016, 6:03:03 PM1/16/16
to andro...@googlegroups.com
On 2016.01.17 00:21, Charles Milette wrote:

Well then wait until someone provides a signed kernel.
Or just use what is available.

I'm gonna cite myself:

"Also, on the next release, signing the kernel and the initramd.img [...] would be great"


 
Well, all secure boot really does is prevent you from booting stuff not signed by MS. It is not an antivirus.

Wrong, secure boot is fully customizable (You can add your own keys) and specified in the UEFI Specification, it is just that almost all computers includes Windows and therefore where configure to boot Windows with Secure Boot activated. Almost all Linux distros uses secure boot. It is not an antivirus, I agree, but it is a good protection for virus trying to infiltrate the boot process

Then what prevents you from making your own keys and signing ?

This is an FOSS project and things are only done when there's a demand for them.
If there aren't many users who need Secure Boot support (and I think most users don't really care about it), nobody will bother supporting it.


Making Android compatible with Secure Boot would allow to install and boot it on ARM computers, the secure boot and it's database being locked at it's default on those.

You mean Windows RT ? I think those systems are locked to MS signed stuff and there's no MS signed GRUB available for ARM.

Also, this project targets the x86 architecture (hence the name, Android x86), not ARM.

Charles Milette

unread,
Jan 16, 2016, 6:36:17 PM1/16/16
to Android-x86
 
Then what prevents you from making your own keys and signing ?

1. HP badly made their BIOS
2. I prefer having all already set up and ready to boot after install
3. I only have a live Linux distro and messing with things out of an OS means a lot of restarts, long Wi-fi password typing and installs.
 


This is an FOSS project and things are only done when there's a demand for them.
If there aren't many users who need Secure Boot support (and I think most users don't really care about it), nobody will bother supporting it.

Come on, it's not complicated:

Download and add shim as \EFI\Boot\bootx64.efi
Download and add Canonical's signed GRUB to \EFI\Boot\grubx64.efi
And do the same thing while installing GRUB2 EFI

If Chih-Wei Huang was able to add GRUB to its IMG and installer, he does the exact same thing, but with two files instead of one. And prevent future Secure Boot-locked user complaining about Secure Boot (because Microsoft might decide to force OEMs to lock Secure Boot to have their discounts on Windows keys and their nice little "Windows" sticker). There's already a patch about that, it's on the rails for being pulled.
 



You mean Windows RT ? I think those systems are locked to MS signed stuff and there's no MS signed GRUB available for ARM.

There's now Windows 10 tablet with an ARM architecture, and here's why shim was made: Making users with computers for Windows allow to keep secure boot on and boot something else. Shim is signed by Microsoft and allows to boot anything in the same folder name "grubx64.efi" if it is signed by a key in it's MOK (Canonical's CA is included by default on it). Once the first stage is loaded by the EFI system, it doesn't make any other check and thus allows to boot GRUB on a Surface RT, the only problem is to have version of GRUB and shim for ARM.

 



Also, this project targets the x86 architecture (hence the name, Android x86), not ARM.

*Facepalm* ... Android was originally for ARM. But some users managed to make a version bootable on ARM computers.

Ravi

unread,
Jan 16, 2016, 6:43:22 PM1/16/16
to Android-x86
I agree with Povilas, disabling secure boot isn't going to make your device any less secure.

However, if we can add secure boot support, then it should be considered - but only since there are some Atom-based tablets that can't disable secure boot that we would be able to support in the process.

Povilas Staniulis

unread,
Jan 16, 2016, 6:58:35 PM1/16/16
to andro...@googlegroups.com
On 2016.01.17 01:36, Charles Milette wrote:
 
Then what prevents you from making your own keys and signing ?

1. HP badly made their BIOS
2. I prefer having all already set up and ready to boot after install
3. I only have a live Linux distro and messing with things out of an OS means a lot of restarts, long Wi-fi password typing and installs.
 


This is an FOSS project and things are only done when there's a demand for them.
If there aren't many users who need Secure Boot support (and I think most users don't really care about it), nobody will bother supporting it.

Come on, it's not complicated:

Download and add shim as \EFI\Boot\bootx64.efi
Download and add Canonical's signed GRUB to \EFI\Boot\grubx64.efi
And do the same thing while installing GRUB2 EFI

If Chih-Wei Huang was able to add GRUB to its IMG and installer, he does the exact same thing, but with two files instead of one. And prevent future Secure Boot-locked user complaining about Secure Boot (because Microsoft might decide to force OEMs to lock Secure Boot to have their discounts on Windows keys and their nice little "Windows" sticker). There's already a patch about that, it's on the rails for being pulled.
 


I said it will be added if there's a demand for this.
Until then, you are free to do it on your own.





You mean Windows RT ? I think those systems are locked to MS signed stuff and there's no MS signed GRUB available for ARM.

There's now Windows 10 tablet with an ARM architecture, and here's why shim was made: Making users with computers for Windows allow to keep secure boot on and boot something else. Shim is signed by Microsoft and allows to boot anything in the same folder name "grubx64.efi" if it is signed by a key in it's MOK (Canonical's CA is included by default on it). Once the first stage is loaded by the EFI system, it doesn't make any other check and thus allows to boot GRUB on a Surface RT, the only problem is to have version of GRUB and shim for ARM.


"the only problem is to have version of GRUB and shim for ARM"
I don't thing we're ever going to have those. Unless MS changes their mind.


 

Also, this project targets the x86 architecture (hence the name, Android x86), not ARM.

*Facepalm* ... Android was originally for ARM. But some users managed to make a version bootable on ARM computers.
--


*LOL*

Since when Sony Vaio Tap 11 is an ARM computer ?
Working ARM means that Houdini translator is included to allow ARM apps to run.

Charles Milette

unread,
Jan 16, 2016, 7:06:19 PM1/16/16
to Android-x86

I agree with Povilas, disabling secure boot isn't going to make your device any less secure.

One day, someone might think "Let's make a virus that is gonna use that `it isn't going to be less secure` thing from all those Linux users", and it will it hard. I prefer keeping it active to prevent something like that. By the number of virus that come out each month, there is surley going to be one like that one day.
 

However, if we can add secure boot support, then it should be considered - but only since there are some Atom-based tablets that can't disable secure boot that we would be able to support in the process.
I agree, changing settings in a very old-style configuration utility might make freak out some, thinking they might "break" something. When I do this at my school, everyone freaks out and say that I'm a "hacker", so not everyone wants to touch at that or does know how to browse in that, even less with only a touch screen.

Microsoft might decide at any time they want to change their Windows Hardware Certification, that all OEM are required to respect, to lock Secure Boot on and it's not gonna hit here, it will already support Secure Boot.

Charles Milette

unread,
Jan 16, 2016, 7:08:51 PM1/16/16
to Android-x86
 
"the only problem is to have version of GRUB and shim for ARM"
I don't thing we're ever going to have those. Unless MS changes their mind.
 
True
 
Since when Sony Vaio Tap 11 is an ARM computer ?
Working ARM means that Houdini translator is included to allow ARM apps to run.

Sorry for not reading more than the title...

Luke

unread,
Jan 18, 2016, 1:07:42 AM1/18/16
to Android-x86
I've added tickets to sourceforge to address your problems. I will look into signing the kernel and adding the keys when more important bug are resolved.

Charles Milette

unread,
Jan 18, 2016, 8:16:11 AM1/18/16
to Android-x86
Thanks

Chih-Wei Huang

unread,
Apr 18, 2016, 3:13:19 AM4/18/16
to Android-x86
2016-01-18 14:07 GMT+08:00 Luke <hath...@gmail.com>:
> I've added tickets to sourceforge to address your problems. I will look into signing the kernel and adding the keys when more important bug are resolved.
>

Hi Luke,
Do you have any update about the secure boot support?
I think we have a ticket for it but I couldn't find it now.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Charles Milette

unread,
Apr 18, 2016, 8:12:16 AM4/18/16
to Android-x86

Luke

unread,
Apr 18, 2016, 11:11:45 PM4/18/16
to Android-x86
Hi Luke,
Do you have any update about the secure boot support?
I think we have a ticket for it but I couldn't find it now.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Secure boot is working fine for x64 systems. x86 systems are unsupported due to Canonical not having a signed x86 grub.

The ticket was for grub installing to the wrong partition which has now been resolved.

Chih-Wei Huang

unread,
Apr 19, 2016, 12:27:28 AM4/19/16
to Android-x86
2016-04-19 11:11 GMT+08:00 Luke <hath...@gmail.com>:
>> Hi Luke,
>> Do you have any update about the secure boot support?
>> I think we have a ticket for it but I couldn't find it now.

We still use a unsigned kernel, right?
I remember you said to support self-signed kernels,
a x509 certificate will need to be created, used to sign the kernel
and added to bootx64.efi and grubx64.efi's key db.

Are you working on this?

> Secure boot is working fine for x64 systems. x86 systems are unsupported due
> to Canonical not having a signed x86 grub.
>
> The ticket was for grub installing to the wrong partition which has now been
> resolved.

Then please create a ticket for it.

Luke

unread,
Apr 19, 2016, 1:37:54 AM4/19/16
to Android-x86


On Tuesday, April 19, 2016 at 4:27:28 PM UTC+12, Chih-Wei Huang wrote:

We still use a unsigned kernel, right?
I remember you said to support self-signed kernels,
a x509 certificate will need to be created, used to sign the kernel
and added to bootx64.efi and grubx64.efi's key db.

Are you working on this?
 
Not at this moment in time.
 

Then please create a ticket for it.

 
I'll create a ticket and get testing.

Charles Milette

unread,
Apr 19, 2016, 8:05:32 AM4/19/16
to Android-x86

We still use a unsigned kernel, right?
I remember you said to support self-signed kernels,
a x509 certificate will need to be created, used to sign the kernel
and added to bootx64.efi and grubx64.efi's key db.

AFAIK, adding a certificate to the MOK requires user action, with the MokManager.efi app, or a "mokutil" command line on Ubuntu. You can directly embed them into bootx64.efi, but that would break the certification. How are you going to do that?


Secure boot is working fine for x64 systems. x86 systems are unsupported due
to Canonical not having a signed x86 grub. 

It's been a while a saw a x86 Windows device in sale. Most of them now are x64, and since UEFI Secure Boot is a new technology, it is not present on many x86 devices.



Also, can the public part of the certificate be available separately, because I use the Secure Boot db directly, and not shim, since I can add keys in them. If I had the public key, I could add it to my Secure Boot db and use it to boot Android-x86 without shim and the MOK db.
Reply all
Reply to author
Forward
0 new messages