uefi ntfs
v2.5
UEFI: NTFS est un chargeur de démarrage générique, conçu pour permettre le démarrage à partir des partitions NTFS ou EXFAT, en mode UEFI pur, même si votre système ne le prend en charge nativement. Ceci est principalement destiné à être utilisé avec Rufus, mais peut également être utilisé indépendamment.
En d'autres termes, UEFI: NTFS est conçu pour éliminer la restriction, que la plupart des systèmes UEFI ont, de fournir uniquement le support de démarrage d'une partition FAT32, et de permettre de démarrer également à partir de partitions NTFS.
Cela peut être utilisé, par exemple, pour UEFI-Boot un support d'installation NTFS Windows, contenant une install.wim .
En passant, et parce qu'il semble exister beaucoup d'informations inexactes à ce sujet sur Internet, il faut souligner qu'il n'y a absolument rien dans les spécifications UEFI qui force réellement l'utilisation de FAT32 pour le démarrage UEFI. Au contraire, l'UEFI démarrera avec plaisir à partir de n'importe quel système de fichiers, tant que votre firmware a un pilote pour cela. En tant que tel, ce n'est que le choix des fabricants de systèmes, qui ont tendance à inclure uniquement un pilote pour FAT32, qui limite les capacités de démarrage par défaut de l'UEFI, et qui conduit beaucoup à croire à tort que seul FAT32 peut être utilisé pour la démarrage UEFI.
Cependant, comme démontré dans ce projet, il est très possible de contourner cette limitation et de permettre à n'importe quel firmware UEFI de démarrer à partir de systèmes de fichiers non-FAT32.
La façon dont UEFI: NTFS fonctionne, en conjonction avec Rufus, est la suivante:
/efi/boot/bootia32.efi , /efi/boot/bootx64.efi , /efi/boot/bootarm.efi ou /efi/boot/bootaa64.efi qui y réside. Cela atteint exactement le même résultat que si le firmware UEFI avait une prise en charge native pour les NTF et pourrait démarrer directement à partir de lui. UEFI: NTFS est compatible avec Secure Boot et a été signé par Microsoft.
Vous pouvez trouver des binaires signés de démarrage sécurisés (pour x86_64, x86_32 et arm64) dans l'archive uefi-ntfs.img de Rufus.
Notez cependant que, en raison des restrictions arbitraires de Microsoft concernant GPLV3, les seuls pilotes qui peuvent actuellement être utilisés avec UEFI: NTFS dans un environnement de démarrage sécurisé sont ceux NTFS-3G sous licence GPLV2. En particulier, les pilotes NTFS et EXFAT des EFIF, qui sont dérivés de GRUB 2.0, et donc GPLV3, ne peuvent pas être soumis à Microsoft pour la signature.
Enfin, les stratégies de signature de démarrage sécurisées actuelles de Microsoft nécessitent une validation supplémentaire pour le bras 32 bits, donc les binaires de bras 32 bits ne sont pas signés de démarrage sécurisé. Cela n'affecte pas le bras 64 bits (AKA ARM64 / AARCH64 / AA64 ) pour lequel nous avons des binaires signés de démarrage entièrement sécurisés.
Pour plus de commodité, le projet peut être compilé avec la bibliothèque GNU-EFI plutôt que EDK2, vous devrez donc peut-être initialiser les sous-modules Git avec:
git submodule update --init
Si vous utilisez la solution Visual Studio ( .sln ), appuyez simplement sur F5 pour que l'application soit compilée et lancée dans l'émulateur Qemu.
Si vous utilisez GCC avec GNU-EFI, vous devriez être en mesure de simplement délivrer make .
Si nécessaire, vous pouvez également émettre quelque chose comme make ARCH=<arch> CROSS_COMPILE=<tuple> où <arch> est l'un des ia32 , x64 , arm ou aa64 et Tuple est celui de votre compositeur croisé (par exemple aarch64-linux-gnu- ).
Vous pouvez également déboguer via QEMU en spécifiant qemu à votre make . Soyez à l'esprit cependant que cela allume le mode spécial _DEBUG , et vous devriez faire de la marque sans invoquer qemu pour produire des binaires de libération appropriés.
Si vous utilisez VS2022 avec EDK2 sur Windows, en supposant que votre répertoire EDK2 est en D:edk2 et que nasm réside dans D:edk2BaseToolsBinWin32 , vous devriez pouvoir émettre:
set EDK2_PATH=D:edk2
set NASM_PREFIX=D:edk2BaseToolsBinWin32
set WORKSPACE=%CD%
set PACKAGES_PATH=%WORKSPACE%;%EDK2_PATH%
%EDK2_PATH%edksetup.bat reconfig
build -a X64 -b RELEASE -t VS2022 -p uefi-ntfs.dsc
Si vous utilisez GCC avec EDK2 sur Linux, et en supposant que votre répertoire EDK2 réside dans /usr/src/edk2 :
export EDK2_PATH="/usr/src/edk2"
export WORKSPACE=$PWD
export PACKAGES_PATH=$WORKSPACE:$EDK2_PATH
. $EDK2_PATH/edksetup.sh --reconfig
build -a X64 -b RELEASE -t GCC5 -p uefi-ntfs.dsc
Vous pouvez trouver une image de partition de graisse prêt à l'emploi, contenant les versions X86 et ARM du chargeur UEFI: NTFS (32 et 64 bits) et le pilote dans le projet Rufus, Under / Res / UEFI.
Si vous créez une partition de la même taille à la fin de votre lecteur et copiez uefi-ntfs.img là-bas (en mode DD bien sûr), vous devriez avoir tout ce dont vous avez besoin pour faire la première partition NTFS sur ce lecteur UEFI Bootable.
Veuillez être conscient que, pour activer la prise en charge de la compilation ARM ou ARM64 dans Visual Studio 2022, vous devez accéder à l'écran des composants individuels dans l'application de configuration et sélectionner les outils de construction ARM / ARM64, car ils n'apparaissent pas dans l'écran de charges de travail par défaut:
