uefi ntfsダウンロード-uefi uefi ntfsソースコードのダウンロード

uefi ntfs

C# ソースコード

v2.5

ダウンロード

uefi：ntfs -uefiのntfsまたはexfatパーティションを起動します

UEFI：NTFSは、システムがネイティブにサポートしていなくても、純粋なUEFIモードで、NTFSまたはEXFATパーティションからのブートを許可するように設計されています。これは主にRufusでの使用を目的としていますが、独立して使用することもできます。

言い換えれば、UEFI：NTFSは、ほとんどのUEFIシステムが持っている制限を削除するように設計されており、FAT32パーティションからのブートサポートのみを提供し、NTFSパーティションから起動する機能を可能にします。

これは、たとえば、Windows NTFSインストールメディアをuefi-bootに使用することができます。 install.wimには、4 GBより大きい（FAT32がサポートできないもの）、または「Windows」ドライブのデュアルBIOS + UEFIブーツを許可するinstall.wimが含まれます。

余談です。また、インターネット上にこれに関する多くの不正確な情報が存在するように見えるため、UEFIブートにFAT32を実際に使用することを実際に強制するUEFI仕様には絶対に何もないことを強調する必要があります。それどころか、ファームウェアにドライバーがある限り、UEFIはファイルシステムから喜んで起動します。そのため、FAT32のドライバーのみを含める傾向があるシステムメーカーの選択であり、UEFIのデフォルトのブート機能を制限し、UEFIブートにはFAT32のみが使用できると多くの人が誤って信じています。

ただし、このプロジェクトで実証されているように、この制限を回避し、UEFIファームウェアが非FAT32ファイルシステムから起動できるようにすることは非常に可能です。

概要

uefi：ntfsがrufusと併せて動作する方法は次のとおりです。

Rufusは、ターゲットUSBディスクに2つのパーティションを作成します（これらはMBRまたはGPTパーティションになります）。 1つ目は、ほぼすべてのドライブを占めるNTFSパーティションで、Windowsファイル（Windowsの場合、または定期的なインストール用）が含まれており、2番目は非常に小さな脂肪パーティションで、ntfs Uefiドライバーを含む非常に小さな脂肪パーティションです（https://efi.akeo.ieを参照）。
UEFIモードでUSBドライブがブーツをブーツすると、最初のNTFSパーティションはUEFIファームウェアによって無視されます（ファームウェアには既にNTFSドライバーが含まれている場合を除き、この場合は2つのブートオプションが利用可能になり、同じものを実行します）と、起動可能な脂肪パーティションからのUEFI：NTFSブートローダーが実行されます。
UEFI：NTFSは、関連するNTFS UEFIドライバーをロードし、同じメディアで既存のNTFSパーティションを見つけ、 /efi/boot/bootia32.efi bootia32.efi、 /efi/boot/bootx64.efi bootx64.efi、 /efi/boot/bootarm.efi /bootarm.efiまたは/efi/boot/bootaa64.efiを実行します。これにより、UEFIファームウェアがNTFをネイティブサポートし、そこから直接起動できる場合とまったく同じ結果が得られます。

安全なブート互換性

UEFI：NTFSはSecure Bootと互換性があり、Microsoftによって署名されています。
Rufusのuefi-ntfs.imgアーカイブで、Secure Boot Signed Binaries（X86_64、X86_32、ARM64の場合）を見つけることができます。
ただし、GPLV3に関するMicrosoftのarbitrary意的な制限により、現在UEFIで使用できるドライバーは、安全なブート環境でntfsであることに注意してください。特に、Grub 2.0から派生しているため、GPLV3から派生したEFIFのNTFSおよびEXFATドライバーは、署名のためにMicrosoftに提出することはできません。
最後に、Microsoftの現在の安全なブート署名ポリシーには、32ビットアームの追加の検証が必要なため、32ビットアームバイナリは安全なブート署名ではありません。これは、64ビットアーム（別名ARM64 / AARCH64 / AA64 ）には影響しません。

前提条件

Visual Studio 2022またはMINGW/MINGW64（できればMSYS2を使用してインストール）またはGCC
QEMU V2.7以降（NB：QEMU Windowsバイナリはこちらから見つけることができます）
git
Visual Studioを使用していない場合、Wget、Unzip

サブモジュールの初期化

便利なため、プロジェクトはEDK2ではなくGNU-EFIライブラリに対してコンパイルできます。

 git submodule update --init

編集とテスト

Visual Studio Solution（ .sln ）を使用する場合は、 F5を押して、QEMUエミュレーターでアプリケーションをコンパイルして起動するだけです。
GCCをGNU-EFIで使用する場合は、単にmakeを発行できるはずです。
必要に応じて、 make ARCH=<arch> CROSS_COMPILE=<tuple>ようなものを発行することもできます。ここで、 <arch>はia32 、 x64 、 armまたはaa64 aarch64-linux-gnu-およびTupleの1つです。
qemuをmakeすることでQEMUをデバッグすることもできます。ただし、これにより特別な_DEBUGモードがオンになっていることに注意してください。適切なリリースバイナリを作成するためにqemuを呼び出すことなく実行する必要があります。

WindowsでEDK2を使用してVS2022を使用している場合、EDK2ディレクトリがD:edk2にあり、 nasmがD:edk2BaseToolsBinWin32に存在すると仮定すると、発行できるはずです。

  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

LinuxでEDK2でGCCを使用し、EDK2ディレクトリが/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