SurfaceRT/RT2 Hacking Notes
These are my working notes, so will not likely make much sense (yet). I'm trying to paint a picture of whats needed, and what we have discovered so far, as the wiki seems a bit outdated. Ultimately would like to merge or update. Might be helpful to others.
The SurfaceRT /2 Wiki is here - https://wiki.adsj.be Discord is here - https://discord.gg/AkBtG7n
----
Notes
https://forum.xda-developers.com/showpost.php?p=83047245&postcount=138
The modified RT boot sequence still utilizes Microsoft's bootarm.efi, once this is loaded the UEFI environment is too contaminated to load a stock linux build.
If you could replace bootarm.efi entirely, then it would be much more manageable to get Linux going (since Tegra3/4 are supported in the mainline kernel). The problem is that bootarm.efi MUST be production signed by the Microsoft private key or booting fails.
The unlock we have currently does not change this behaviour, but it instead allows us modify BCD to allow loading shims from the Windows Boot Manager. What really sucks is that these 32bit UEFI firmwares (including the Surface and Lumia) usually lives at very low memory space, while arm32 Linux requires to be run at low memory space too. This causes overlap when Linux kernel is booted under UEFI, e.g. using GRUB. Therefore UEFI will be overwritten by Linux, which relies on UEFI runtime services. This confliction makes it almost impossible to boot Linux under stock UEFI. (Usually this causes an immediate reboot, or just stucks.) The only way to bypass this problem seems to be kicking the stock UEFI out(which is what those Lumia guys do), as Linux loading location isn't quite changeable. By kicking out stock UEFI from memory you can then load an alternative bootloader like u-boot or even nvaboot (Android bootloader used by Nvidia on tegras) if you managed to get the source. Or just cleanly load Linux kernel, which is more inconvenient.
---
build linux as efistub and sign with our key.
https://bentley.link/secureboot/
golden key notes.
https://gist.github.com/acepace/df34b5213f1e0fae6529eb703d947187
working key -
5D7630097BE5BDB731FC40CD4998B69914D82EAD CN=Windows OEM Test Cert 2017 (TEST ONLY), O=Microsoft Partner, OU=Windows, L=Redmond, S=Washington, C=US
use signtool eg
signtool.exe sign /tr http://timestamp.digicert.com /td sha1 /fd sha1 /sm /sha1 5d7630097be5bdb731fc40cd4998b69914d82ead *.efi
to build a signed efi.
Maybe good idea to run keytool.efi also to see if we can read the existing keys with our signed efi? Alternate method - we fusee-gelee boot in non secure mode, and flash our own uboot code, bypassing all the BS. There is a working uboot for both T30 and T40 soc's, so not out of the realms of impossibility.
eg
https://github.com/jelly/efitools
A 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.
We have a kek - aka 5d7630097be5bdb731fc40cd4998b69914d82ead -- the test key.
Further reading
Misc
https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions
https://designprincipia.com/compile-linux-kernel-for-arm-and-run-on-qemu/
https://oofhours.com/2019/09/02/geeking-out-with-uefi/
Kernel
https://sites.google.com/site/zhuoweisite/blog/baremetaldevelopmentonthenexus7 (direct framebuffer output example -) https://github.com/zhuowei/nexus7-baremetal https://bugsdb.com/_en/debug/194bace6c2623d050eb044ddff56c130 [How do I find ARM Linux entry point when it fails to uncompress?] https://people.kernel.org/linusw/how-the-arm32-kernel-starts https://stackoverflow.com/questions/33578993/base-address-at-which-the-linux-kernel-is-loaded/43223776 https://lore.kernel.org/patchwork/patch/1109905/ https://falstaff.agner.ch/2015/10/17/linux-earlyprintkearlycon-support-on-arm/ https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html https://www.kernel.org/doc/Documentation/efi-stub.txt https://lists.denx.de/pipermail/u-boot/2014-November/196394.html [tegra30 kernel boot example]
Ref:
https://github.com/NVIDIA/tegra-pinmux-scripts/blob/master/configs/tegra30.soc https://github.com/ARM-software/u-boot/blob/master/arch/arm/dts/tegra30.dtsi
https://github.com/ARM-software/u-boot/blob/master/arch/arm/dts/tegra114.dtsi
https://gist.github.com/acepace/df34b5213f1e0fae6529eb703d947187 [golden key boot]
DST UARTA example (mine) https://pastebin.com/DGkH4gGW
Secure boot /EFI
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
Other
https://forum.xda-developers.com/windows-8-rt
https://github.com/ms-iot/iot-adk-addonkit/blob/master/Tools/IoTCoreImaging/IoTWorkspace.ps1
MS Signing test key - 5D7630097BE5BDB731FC40CD4998B69914D82EAD CN=Windows OEM Test Cert 2017 (TEST ONLY), O=Microsoft Partner, OU=Windows, L=Redmond, S=Washington, C=US
Last updated
