I got refind installed on my Asus Transformer T100TA. It has 32-bit UEFI and I imported the refind certificate in firmware, but it would not load with secure boot enabled because refind_ia32.efi is not signed.
Only the 64bit efi binary is signed but not the 32bit version. Is there a reason for that?
# pesign --show-signature --in=refind_x64.efi
---------------------------------------------
certificate address is 0xb73bcc88
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Roderick W. Smith, rodsmith@rodsbooks.com
No signer email address.
Signing time: Sun Jul 06, 2014
There were certs or crls included.
---------------------------------------------
# pesign --show-signature --in=refind_ia32.efi
No signatures found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-12-14
I have the same laptop/ tablet and im trying to get refind working or anything so i can get windows off it, i just need help getting a certificate running so i can book up refind. Windows has me locked out of everything in the uefi, they have an admin account that i cant figure out how to get into for the life of me so i cant shut off secure boot or change boot order
anything is appreciated,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know about the ASUS T100TA, but I do have an ASUS T100. With it, hitting F2 as you power on the computer should bring up the firmware setup utility. From there, you can go to the Security Menu, which has a Secure Boot submenu in which you can adjust Secure Boot options.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. The last I heard, there were no signed 32-bit versions of Shim. Thus, there's nothing to load the a signed 32-bit version of rEFInd. To get rEFInd working with Secure Boot on a 32-bit computer, you'll need to use the most complex method documented on my EFI Boot Loaders Secure Boot page:
Scroll down to the "Replacing Your Firmware's Keys" section. This procedure includes information on signing rEFInd with your own keys. (In fact, the install.sh script will do this automatically if it finds appropriate tools are installed on your computer.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I used the "Append KEK" and "Append DB" from the firmware setup to add refind.cer to these databases. Do I understand correctly that even if the 32bit EFI was signed with that key, that would not work unless I also replaced the platform key?
I run windows on this device, so I would not want to delete the microsoft keys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All I can suggest is that you try it. Although I did figure out how to replace my firmware's keys, that was some time ago, so my memory of the procedure is foggy. Furthermore, I was doing it with a 64-bit EFI and 64-bit binaries. The complexity of the procedure is such that signing the binaries locally is a minor addition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It works!
I have signed all the efi binaries with my own key. Then I appended my public key to the "Authorized signature database (DB)"
Here is a screenshot from my Aptio Setup utility: http://i.imgur.com/4B9M8Pd.jpg
Note that it only appends a new key, it does not replace anything. You do not need to change the platform key or add a key to the KEK. (But if you do add it to KEK, AFAIK it would give refind the power to add other keys to DB, if it had that option)
To remove the key and go back to factory defaults, use the "Set new DB" function.
Interestingly, this firmware comes with keys form Canonical included by default in KEK and DB. I found them when I used the "Save all secure boot variables" and inspected the files (they were still there after I reset the databases to defaults).
As you said, there is no signed 32bit version of shim. I compiled shim/mokmanager for 32bit on my Fedora box, signed them, but both just froze the computer when started from EFI shell. I guess 32bit is not supported at all, but given the recent popularity of Bay Trail tablets, that may change perhaps in the future. https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/
Ubuntu en Mint do not even support 32bit EFI booting, the installer ISO has no EFI folder.
Fedora supports 32bit EFI, but does not sign anything. To make it work with secure boot, you would have to sign grub and the kernel yourself I guess.
But refind32 works fine when self-signed. I can run efi shell, boot windows 8.1, run a microsoft-signed version of memtest86 or enter Setup. Just one little oops, it thinks it can run a 64bit Mokmanager. That should not appear on the tools menu on 32bit EFI ;)
Last edit: joost 2014-12-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When Secure Boot was first announced, Canonical tried to get its keys included in manufacturers' EFIs as a way of dealing with Secure Boot. Although Canonical switched to the Shim approach, many manufacturers still ship with Canonical's keys.
The Shim code includes architecture-specific components that work on x86-64 CPUs but not on others, including 32-bit x86. Thus, recompiling it for x86 simply won't work, at least not unless and until appropriate architecture-specific code is included for the target CPU.
Thanks for the bug report about the missing architecture-type check. I've added that check, and it's now available in source code in the git repository.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got refind installed on my Asus Transformer T100TA. It has 32-bit UEFI and I imported the refind certificate in firmware, but it would not load with secure boot enabled because refind_ia32.efi is not signed.
Only the 64bit efi binary is signed but not the 32bit version. Is there a reason for that?
I have the same laptop/ tablet and im trying to get refind working or anything so i can get windows off it, i just need help getting a certificate running so i can book up refind. Windows has me locked out of everything in the uefi, they have an admin account that i cant figure out how to get into for the life of me so i cant shut off secure boot or change boot order
anything is appreciated,
I don't know about the ASUS T100TA, but I do have an ASUS T100. With it, hitting F2 as you power on the computer should bring up the firmware setup utility. From there, you can go to the Security Menu, which has a Secure Boot submenu in which you can adjust Secure Boot options.
Yes. The last I heard, there were no signed 32-bit versions of Shim. Thus, there's nothing to load the a signed 32-bit version of rEFInd. To get rEFInd working with Secure Boot on a 32-bit computer, you'll need to use the most complex method documented on my EFI Boot Loaders Secure Boot page:
http://www.rodsbooks.com/efi-bootloaders/secureboot.html
Scroll down to the "Replacing Your Firmware's Keys" section. This procedure includes information on signing rEFInd with your own keys. (In fact, the install.sh script will do this automatically if it finds appropriate tools are installed on your computer.)
Thanks. I used the "Append KEK" and "Append DB" from the firmware setup to add refind.cer to these databases. Do I understand correctly that even if the 32bit EFI was signed with that key, that would not work unless I also replaced the platform key?
I run windows on this device, so I would not want to delete the microsoft keys.
All I can suggest is that you try it. Although I did figure out how to replace my firmware's keys, that was some time ago, so my memory of the procedure is foggy. Furthermore, I was doing it with a 64-bit EFI and 64-bit binaries. The complexity of the procedure is such that signing the binaries locally is a minor addition.
It works!
I have signed all the efi binaries with my own key. Then I appended my public key to the "Authorized signature database (DB)"
Here is a screenshot from my Aptio Setup utility:
http://i.imgur.com/4B9M8Pd.jpg
Note that it only appends a new key, it does not replace anything. You do not need to change the platform key or add a key to the KEK. (But if you do add it to KEK, AFAIK it would give refind the power to add other keys to DB, if it had that option)
To remove the key and go back to factory defaults, use the "Set new DB" function.
Interestingly, this firmware comes with keys form Canonical included by default in KEK and DB. I found them when I used the "Save all secure boot variables" and inspected the files (they were still there after I reset the databases to defaults).
As you said, there is no signed 32bit version of shim. I compiled shim/mokmanager for 32bit on my Fedora box, signed them, but both just froze the computer when started from EFI shell. I guess 32bit is not supported at all, but given the recent popularity of Bay Trail tablets, that may change perhaps in the future.
https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/
Ubuntu en Mint do not even support 32bit EFI booting, the installer ISO has no EFI folder.
Fedora supports 32bit EFI, but does not sign anything. To make it work with secure boot, you would have to sign grub and the kernel yourself I guess.
But refind32 works fine when self-signed. I can run efi shell, boot windows 8.1, run a microsoft-signed version of memtest86 or enter Setup. Just one little oops, it thinks it can run a 64bit Mokmanager. That should not appear on the tools menu on 32bit EFI ;)
Last edit: joost 2014-12-14
When Secure Boot was first announced, Canonical tried to get its keys included in manufacturers' EFIs as a way of dealing with Secure Boot. Although Canonical switched to the Shim approach, many manufacturers still ship with Canonical's keys.
The Shim code includes architecture-specific components that work on x86-64 CPUs but not on others, including 32-bit x86. Thus, recompiling it for x86 simply won't work, at least not unless and until appropriate architecture-specific code is included for the target CPU.
Thanks for the bug report about the missing architecture-type check. I've added that check, and it's now available in source code in the git repository.