Boot process of Tegra SoC's from Firmware to Operating System
UEFI Firmware is loaded by the BootRom which loads the UEFI Firmware.
UEFI Firmware will setup hardware like Display, USB, etc.
After hardware setup it will transfer control to /efi/boot/bootarm.efi
bootarm.efi has to be signed with the Microsoft SecureBootKey (SBK)
https://forum.xda-developers.com/showpost.php?p=82555449&postcount=126
coherixmatts - "This has been helpful to me, as I was able to quickly test changes to the BCD file. Changing the BCD file allowed me to replace test.efi with bootshim.efi from here: http://github.com/imbushuo/boot-shim/releases
Instead of loading EFI files like test.efi, this alternative loads ELF files. That isn't necessarily so exciting, but this BootShim also unloads elements of the original SecureBoot restricted UEFI. They are using this on Lumia devices (particularly the 950XL) to load a modified version of UEFI. After that, it seems they can boot most anything." This thread also seems interesting for reference https://github.com/rhboot/shim/issues/138
In the Surface RT UEFI there is a bug which prevents the display from working. This is because the standard GOP (Graphical Ouput Protocol) isn't hooked up to the Surface RT's display. This was fixed in the Surface RT 2.
UEFI can be set to require a trusted chain from boot to execution of OS - aka a Root of Trust. On the Surface RT/2, UEFI is setup to require a trusted chain "secure boot".
This was the main issue for development of other OS's on the Surface RT/2 hardware.
Secure Boot means that we are unable to replace the "bootarm.efi" bootloader with our own bootloader like GRUB as it needs to be signed by Microsoft.
Microsoft is unwilling or unable to provide the key to "unlock" the Surface RT/2 hardware, so we are "stuck" with using their bootloader. There are two possible options to bypass this - Yahallo and Test Certificate bypass.
A "golden key" bypass which allows us to insert a trusted test certificate into the UEFI Bios allows us to use a signed shim to boot into our own EFI loader (instead of booting into Windows). We still load Microsoft's signed bootarm.efi, which then loads a shim, to load Grub/EFI shell, which can then finally load a Kernel.
Further info on this bootmanager exploit bypass is here
A new, easier method for enabling test signing was discovered. It involves the same techniques, but you only need to boot from a USB twice, you don't even need a windows installed. (An EFI partition could be required, this needs to be verified)
Grab the ZIP file from here, extract it to your USB, and boot your Surface device from it. A menu should show up where you have several options (Install Golden Keys, Uninstall Golden Keys, Apply Yahallo, Undo Yahallo). Select "Install Golden Keys" to enable test signing (You have to use a USB keyboard to select an entry). Your device should reboot and you need to accept a warning.
With this you can also easily disable secure boot with the help of yahallo. Just make sure test signing is enabled and you can select "Apply Yahallo" in the menu to disable secure boot.
You can get further explanation of the tool / USB setup in the development section.
Note: This only works when you downgraded to Windows RT 8.0 you can brick your device if you use Windows RT 8.1.
Down in this section there is a download for the "golden key" you need to install it, by running InstallPolicy.cmd as admininistrator on your SurfaceRT. It is important that you don't run the file off a USB drive, copy it to your desktop. After running the file you need to reboot, a menu should open which should enable you to enable testsigning. Accept it. After the reboot open up a cmd, again with administrator privilegs and run the following command:
Reboot again, now testsigning should be enabled.
To use the test signing to boot from USB you need to extract the files from the usb-boot-setup.zip to the root of a FAT32 formated USB-drive. This setup doesn't include any bootable files, to add one place it into the root directory and name it BOOT.efi. Further reading on how the bootflow works at UEFI Boot Sequence.
Root of Trust combination with keys and certificates. Using SecureBoot your firmware will check if the operating system you are trying to boot and your bootloader are trusted by you. On each boot-up UEFI firmware will inspect what you are trying to boot and if it's not trusted a security violation will be triggered.
PK: The Platform Key, the master one, the ring to rule them all. The holder of a PK can install a new PK and update the KEK.
KEK: Key Exchange Key is a secondary key used to sign EFI executables directly or a key used to sign the db and dbx databases.
db: The signature databse is a list with all allowed signing certificates or criptografy hashes to allowed binaries. We will use THIS db key to sign our Linux Kernel.
dbx: The dark side of the db. Inverse db. "not-good-db". You name it. It's the list containing all keys that are not allowed.
https://news.knowledia.com/US/en/articles/secure-your-boot-process-uefi-secureboot-efistub-luks2-lvm-2fe5ab6e432ac7b6d0bb773cebe0363c41bef83c https://wiki.ubuntu.com/UEFI/SecureBoot/Signing https://bentley.link/secureboot/ https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd https://lwn.net/Articles/632528/ [The bootstrap process on EFI systems] https://community.arm.com/developer/ip-products/system/f/embedded-forum/7016/uefi-on-arm-v8-based-linux-embedded-system https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html http://weng-blog.com/2017/07/21/ARMv8-UEFI-manual-boot.html
https://ubuntu.com/blog/how-to-sign-things-for-secure-boot https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot
Refer to The exploit in the dev section to get further information about it.
The Exploit starts in App.c. App.c transfers controll to DeviceLut.c It will compare the UEFI version to some entrys in a lookupTable In case of sRT it will apply a display fix first. DeviceLut.c transfers control to Exploit.c
We suggest to only apply this if you need it. In most cases it is not necessary. At the moment you gain no advantage.
https://github.com/NekomimiRouter/yahallo
You can easily disable secure boot by booting the All-in-one Secureboot tool. Just download the ZIP, extract it to your USB and boot it. Select the options with an USB keyboard. For further information how to setup the USB go to the more detailed explanation bellow.
More details can be found in the Secure Boot page and in the All-in-one Secureboot tool page.
Prerequisites to start with the process!
Working USB drive formatted as FAT32
Surface RT/2 with 50% or more battery, can be plugged in
Yahallo files to boot from
Windows Boot Manager exploit, this one is important!!!
Prepare the USB drive and format as FAT32, doesn't matter if it's MBR or GPT. In my case I name the drives after their capacity.
Extracting the files, make sure the folder contents are on your USB drive's root directory (example: E:\ [stuff is here])
Once the files are copied over, unplug the drive from your PC and power off your Surface. Once powered off plug in the USB drive and boot from it by pressing power and holding volume down at the same time.
That's it! Exploit has been done and all you have to do is power off your tablet and turn back on. From my case at first it refused to display anything so I suggest leaving it for 5 minutes at most. Since SecureBoot is now disabled you can boot unsigned code like Linux, which is work in progress.
To re-enable secureboot replace the "Yahallo.efi" file on your USB with the file bellow, make sure the naming is correct.
Enabling secure boot brings you no advantage at all, you only restirct yourself with what you can do.
According to the UEFI spec a device will initially start up and look for a particular file based on the architecture of the system: As we need to bypass the standard boot, we use the jailbreak to hack the process using a supplemental policy, which enables testsignmode.
The CPU will load the boot setup, and then load up UEFI "bios". UEFI will then load /efi/boot/bootarm.efi (which needs to be signed with a secureboot-key) into ram and pass it control to then load other stuff in turn. We haven't been able to sign our own stuff yet ( if we could then we could just install uboot and bypass all the pain!). So.. we use Microsoft's, aka WindowsBootManager (/efi/boot/bootarm.efi) to eventually load our boot tool (i.e. grub2)
Microsoft's bootarm.efi checks for
efi/microsoft/boot/bcd (boot configuration data)
(which then loads our special "jailbreak" policy), then loads a test.efi shim, which finally loads a secondary EFI file - i.e. GRUB2 or uefi shell placed in the root.
/boot.efi Hardcoded bootloader boots "bootarm.efi"(1: windows bootmanager) Bootmanager loads BCD (2) Bootmanager loads SecureBootDebug.efi, and the SecureBootDebugPolicy.p7b Then loads a test.efi (lolhax? shim) [this can be changed to our own shim, eg https://github.com/imbushuo/boot-shim/releases ] Which finally loads our boot.efi
More detail here - https://forum.xda-developers.com/windows-8-rt/rt-development/wip-secure-boot-linux-surface-rt-t3653848/page12
https://wiki.debian.org/UEFI https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf (although we use GRUB2, the boot process is quite similar, and this is worth a read!)
The special FAT32 requirment of this device.
For a long time it has been thought that only some USB drives work on these devices. Now the issue is known: FAT32 isn't FAT32.
Windows's FAT32 is actually W95 FAT32 (LBA). But Linux creates proper FAT32. So a USB drive that is formatted with Linux won't work for these devices, because the UEFI firmware doesn't support proper FAT32.
Here is a comparison from the two possible partitions (Program used is Gnome Disks):
Type, (here german "Inhalt") doesn't matter. The parition type is meaningful.
Here is are steps to achive this with diskpart:
In the Start menu, type cmd
, and then click the entry for the cmd program.
At the command prompt, enter diskpart
(you have to approve this operation as an administrator). The prompt line should now display "DISKPART".
Enter list disk
. lists your drives.
Enter select disk X
, where X is the number of your selected disk.
(MAKE SURE TO SELECT THE CORRECT ONE!!!).
Enter clean
. wipes the selected drive partition table.
Enter create partition primary
. creates a partition and marks it as primary.
Enter select partition 1
. selects the partition number 1 (primary).
Enter active
. sets it as active (makes it bootable).
Enter format fs=fat32 quick
. formats the drive as FAT32 partition table (quick at the end indicates quick format).
Enter assign
. assigns the drive to a mount point.
Enter exit
.
Source: https://kb.iu.edu/d/bccm
Open a terminal and run this command to locate the right device:
Use fdisk
command accordingly:
sudo fdisk /dev/sdX
; X
stands for the right disk letter something in the region of b
, c
or d
Type o to change the partition table type to dos
When the command runs type d and enter to delete the existing partition, then
Type n to create new partition
Accept the defaults when ask for the partition type
and size
(assuming that is desirable),
Type p to see what you have done,
Type t to change the file system type,
Type c to create a W95 FAT32 (LBA)
partition,
Repeat step 2.5
, i.e. 5
above to see the created partition,
Type a to activate that partition so it automounts,
Type w to write the changes to disk
Format the again from the terminal:
Note: i
represents the partition number in this case it should be 1
Eject and replug the device