uefi ntfs
v2.5
UEFI: NTFS es un gestor de arranque genérico, que está diseñado para permitir el arranque de NTFS o Partitions Exfat, en modo UEFI puro, incluso si su sistema no lo admite de forma nativa. Esto está destinado principalmente a su uso con Rufus, pero también se puede usar de forma independiente.
En otras palabras, UEFI: NTFS está diseñado para eliminar la restricción, que la mayoría de los sistemas UEFI tienen, solo proporcionar soporte de arranque de una partición FAT32, y permitir la capacidad de también arrancar desde particiones NTFS.
Esto se puede utilizar, por ejemplo, a UEFI-BOOT un medio de instalación de Windows NTFS, que contiene una install.wim .
Como aparte, y debido a que parece existir mucha información inexacta sobre esto en Internet, debe enfatizarse que no hay absolutamente nada en las especificaciones de la UEFI que realmente obliga al uso de FAT32 para el arranque UEFI. Por el contrario, UEFI se arrancará desde cualquier sistema de archivos, siempre que su firmware tenga un controlador para ello. Como tal, es solo la elección de los fabricantes del sistema, que tienden a incluir solo un conductor para FAT32, que limita las capacidades de arranque predeterminadas de UEFI, y eso lleva a muchos a creer erróneamente que solo FAT32 se puede usar para el arranque UEFI.
Sin embargo, como se demostró en este proyecto, es muy posible trabajar en torno a esta limitación y permitir que cualquier firmware de UEFI inicie desde sistemas de archivos no FAT32.
La forma en que funciona UEFI: NTFS, junto con Rufus, es la siguiente:
/efi/boot/bootia32.efi , /efi/boot/bootx64.efi , /efi/boot/bootarm.efi o /efi/boot/bootaa64.efi boot/boot /booT Esto logra exactamente el mismo resultado como si el firmware de la UEFI tuviera soporte nativo para NTFS y pudiera arrancar directamente desde él. UEFI: NTFS es compatible con Secure Boot y ha sido firmado por Microsoft.
Puede encontrar binarios firmados seguros (para x86_64, x86_32 y arm64) en el archivo uefi-ntfs.img de RUFUS.
Sin embargo, tenga en cuenta que, debido a las restricciones arbitrarias de Microsoft con respecto a GPLV3, los únicos controladores que actualmente se pueden usar con UEFI: NTFS en un entorno de arranque seguro son los NTFS-3G con licencia GPLV2. Especialmente, los controladores NTFS y EXFAT de los EFIF, que se derivan de GRUB 2.0, y por lo tanto GPLV3, no se pueden enviar a Microsoft para su firma.
Finalmente, las políticas de firma de arranque seguras actuales de Microsoft requieren una validación adicional para un ARM de 32 bits, por lo tanto, los binarios del brazo de 32 bits no están firmados. Esto no afecta el ARM de 64 bits (también conocido como ARM64 / AARCH64 / AA64 ) para el cual tenemos binarios firmados de arranque completamente seguros.
Por conveniencia, el proyecto se puede compilar contra la biblioteca GNU-EFI en lugar de EDK2, por lo que es posible que deba inicializar los submódulos GIT con:
git submodule update --init
Si usa la solución Visual Studio ( .sln ), simplemente presione F5 para que la aplicación compilara y se inicie en el emulador QEMU.
Si usa GCC con GNU-EFI, debería poder simplemente make .
Si es necesario, también puede emitir algo como make ARCH=<arch> CROSS_COMPILE=<tuple> donde <arch> es uno de ia32 , x64 , arm o aa64 y Tuple es el de su compilador cruzado (por ejemplo, aarch64-linux-gnu- ).
También puede depurar QEMU especificando qemu para make invocación. Sin embargo, tenga en cuenta que esto vuelva el modo especial _DEBUG , y debe ejecutar la marca sin invocar qemu para producir binarios de liberación adecuados.
Si usa VS2022 con EDK2 en Windows, suponiendo que su directorio EDK2 esté en D:edk2 y que nasm reside en D:edk2BaseToolsBinWin32 , debería poder emitir:
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 usa GCC con EDK2 en Linux, y suponiendo que su directorio EDK2 reside en /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
Puede encontrar una imagen de partición grasa lista para usar, que contiene las versiones X86 y ARM del cargador UEFI: NTFS (tanto de 32 y 64 bits) y el controlador en el proyecto RUFUS, debajo /res /UEFI.
Si crea una partición del mismo tamaño al final de su unidad y copia uefi-ntfs.img allí (en modo DD, por supuesto), debe tener todo lo que necesita para hacer la primera partición NTFS en esa unidad de arranque UEFI.
Tenga en cuenta que, para habilitar el soporte de compilación ARM o ARM64 en Visual Studio 2022, debe ir a la pantalla de componentes individuales en la aplicación de configuración y seleccionar las herramientas de compilación ARM/ARM64 allí, ya que no aparecen en la pantalla de cargas de trabajo predeterminadas:
