UEFI:NTFS is a generic bootloader, that is designed to allow boot from an NTFS partition, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently.
In other words, UEFI:NTFS is designed to remove the restriction, which most UEFI systems have, of only providing boot support from a FAT32 partition, and enable the ability to also boot from NTFS partitions.
This can be used, for instance, to UEFI-boot a Windows NTFS installation media,
containing an install.wim that is larger than 4 GB (something FAT32 cannot
support) or to allow dual BIOS + UEFI boot of 'Windows To Go' drives.
As an aside, and because there appears to exist a lot of innacurate information about this on the Internet, it needs to be stressed out that there is absolutely nothing in the UEFI specifications that actually forces the use of FAT32 for UEFI boot. On the contrary, UEFI will happily boot from ANY file system, as long as your firmware has a driver for it. As such, it is only the choice of system manufacturers, who tend to only include a driver for FAT32, that limits the default boot capabilities of UEFI, and that leads many to erroneously believe that only FAT32 can be used for UEFI boot.
However, as demonstrated in this project, it is very much possible to work around this limitation and enable any UEFI firmware to boot from non-FAT32 filesystems.
The way UEFI:NTFS works, in conjunction with Rufus, is as follows:
- Rufus creates 2 partitions on the target USB disk (these can be MBR or GPT partitions). The first one is an NTFS partition occupying almost all the drive, that contains the Windows files (for Windows To Go, or for regular installation), and the second is a very small FAT partition, located at the very end, that contains an NTFS UEFI driver (see https://efi.akeo.ie) as well as the UEFI:NTFS bootloader.
- When the USB drive boots in UEFI mode, the first NTFS partition gets ignored by the UEFI firmware (unless that firmware already includes an NTFS driver, in which case 2 boot options will be available, that perform the same thing) and the UEFI:NTFS bootloader from the bootable FAT partition is executed.
- UEFI:NTFS then loads the relevant NTFS UEFI driver, locates the existing NTFS
partition on the same media, and executes the
/efi/boot/bootia32.efi,/efi/boot/bootx64.efi,/efi/boot/bootarm.efior/efi/boot/bootaa64.efithat resides there. This achieves the exact same outcome as if the UEFI firmware had native support for NTFS and could boot straight from it.
Secure Boot must be disabled for UEFI:NTFS to work.
Now, there are two things to be said about this:
-
If you are using UEFI:NTFS to install Windows, then temporarily disabling Secure Boot is not as big deal as you think it is.
This is because all Secure Boot does, really, is establish trust that the files you are booting from have not been maliciously altered... which you can pretty much establish yourself if you validated the checksum of the ISO and ran your media creation from an environment that you trust.
For more on this, please see the second part from this entry of the Rufus FAQ.
-
As a developer, I'd like nothing better than be able to sign UEFI:NTFS for Secure Boot.
However, this is not possible because Microsoft have arbitrarily decided that they would not sign anything that is GPLv3 under the false pretence that it would force them to relinquish their private signing keys.
Of course, this is hyperbolic nonsense since all the GPLv3 mandates is that your system cannot lock users out from running their own code if they choose so, which, as long as you follow the UEFI guidelines, Secure Boot should never do, as it has clear provisions for allowing users to install their own keys.
What this means is that, unfortunately, UEFI:NTFS cannot be submitted to Microsoft for Secure Boot signing, as it will be automatically rejected, and you currently are left with no choice but to have Secure Boot disabled for UEFI:NTFS to run.
And, because the NTFS driver being used is licensed under the GPLv3 (given that its source is derived from GRUB2, which itself is GPLv3, and I am not willing to rewrite an NTFS driver from scratch, especially it means giving up on the license that I see as best for user rights), it is not possible to relicense UEFI:NTFS to anything else but GPLv3.
Still, if you are unhappy about this situation in any way, I would strongly encourage you to contact Microsoft to complain about their blatant abuse of power, and their use of using easily refutable "arguments" to propagate their long standing dislike of the GPL license.
- Visual Studio 2017 or or MinGW/MinGW64 (preferably installed using msys2) or gcc
- QEMU v2.7 or later (NB: You can find QEMU Windows binaries here)
- git
- wget, unzip, if not using Visual Studio
For convenience, the project relies on the gnu-efi library (but not on the gnu-efi compiler itself), so you need to initialize the git submodules:
git submodule init
git submodule update
If using Visual Studio, just press F5 to have the application compiled and
launched in the QEMU emulator.
If using gcc, you should be able to simply issue make. If needed you can also
issue something like make ARCH=<arch> CROSS_COMPILE=<tuple> where <arch> is
one of ia32, x64, arm or aa64 and tuple is the one for your cross-compiler
(e.g. arm-linux-gnueabihf-).
You can also debug through QEMU by specifying qemu to your make invocation.
Be mindful however that this turns the special _DEBUG mode on, and you should
run make without invoking qemu to produce proper release binaries.
You can find a ready-to-use FAT partition image, containing the x86 and ARM versions of the UEFI:NTFS loader (both 32 and 64 bit) and driver in the Rufus project, under /res/uefi.
If you create a partition of the same size at the end of your drive and copy
uefi-ntfs.img
there (in DD mode of course), then you should have everything you need to make
the first NTFS partition on that drive UEFI bootable.
Please be mindful that, to enable ARM or ARM64 compilation support in Visual Studio 2017, you MUST go to the Individual components screen in the setup application and select the ARM compilers and libraries there, as they do NOT appear in the default Workloads screen:
