Skip to content

Add AArch64 boot handoff support - #47

Open
0x1337F00D wants to merge 1 commit into
veracrypt:masterfrom
0x1337F00D:pr/windows-arm64-boot-handoff-clean
Open

0x1337F00D wants to merge 1 commit into
veracrypt:masterfrom
0x1337F00D:pr/windows-arm64-boot-handoff-clean

Conversation

@0x1337F00D

@0x1337F00D 0x1337F00D commented Jul 29, 2026

Copy link
Copy Markdown

Summary

This adds the DCS half of Windows system encryption support for ARM64. It introduces an AArch64 build, an explicit DCS-to-Windows boot-argument handoff, and fail-closed rescue-decryption finalization. The companion Windows driver and application changes are in VeraCrypt#1838.

Development and validation were performed on Windows 11 ARM64 in a Parallels VM.

AArch64 support

  • Adds AArch64 EDK2 build support and architecture-specific output/staging paths.
  • Adds the required AArch64 CPU halt implementation and uses the portable AES fallback where the x86 CPU path is unavailable.
  • Makes LegacySpeaker a no-op on unsupported AArch64 firmware instead of assuming PC speaker hardware.
  • Keeps the x64 build working; both AArch64 and x64 Release builds pass with VS2022/EDK2 /W4 /WX.

Boot handoff protocol

DCS allocates and owns a 4 KiB EfiRuntimeServicesData page for the VeraCrypt boot arguments. A small, versioned descriptor is exposed through a volatile UEFI runtime variable and contains:

  • protocol magic/version and bounded payload size;
  • the runtime-page address;
  • payload CRC;
  • an ownership tag used by the Windows driver before zeroization.

The descriptor is not the password payload itself. The Windows driver validates the descriptor and ownership metadata, copies only the bounded boot-argument structure, zeroes the owned runtime page, and clears the volatile variable. No preboot password is intentionally persisted in NVRAM.

On AArch64, direct boot of the original Windows loader is disabled for the encrypted-system path because bypassing the DCS chain would omit the required handoff.

Rescue decryption safety

The rescue-decryption path now treats transform failures as sticky and only marks decryption complete after it has:

  1. written and flushed the final header state;
  2. reread and authenticated that header;
  3. verified an encrypted length of zero; and
  4. written a salt-bound completion marker.

This prevents a partial or stale finalization from being reported as successful.

Validation

  • AArch64 Release: PASS with VS2022/EDK2 /W4 /WX
  • x64 Release: PASS with VS2022/EDK2 /W4 /WX
  • End-to-end DCS handoff and encrypted Windows boot exercised in a Windows 11 ARM64 Parallels VM
  • Runtime payload magic/version/CRC, ownership, password length, PIM/KDF data, header salt and selected boot identity verified during development

The diagnostic instrumentation used for runtime verification is not included in this PR.

Release integration

Runtime validation used locally built components. Official EFI signing remains part of the VeraCrypt release process; no test certificate, private signing material or signing bypass is included in this PR.

Build the DCS applications for AArch64, publish authenticated boot parameters through owned runtime memory, and clear them without retaining the pre-boot password. Add fail-closed rescue-decryption completion, ARM-safe platform fallbacks, and modern EDK2 compatibility required by the AA64 build.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant