Windows: add ARM64 system encryption support - #1838
Open
0x1337F00D wants to merge 1 commit into
Open
Conversation
Add native ARM64 driver and DCS handoff support for normal GPT system encryption, runtime-select AA64 EFI resources in native and Win32 setup binaries, and keep the handoff fail-closed across encryption and authenticated rescue decryption. Secure Boot remains unsupported for the unsigned AA64 resources, and hidden-system encryption remains disabled.
0x1337F00D
marked this pull request as ready for review
July 29, 2026 09:33
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This adds Windows system encryption support for the native ARM64 UEFI/GPT boot path. It includes the Windows driver, application, installer, resource-selection and fail-closed handoff changes. The companion bootloader implementation is in VeraCrypt-DCS#47.
Development and validation were performed on Windows 11 ARM64 in a Parallels VM.
Architecture
Native ARM64 boot path
Stage-Dcs.ps1to stage DCS artifacts deterministically while validating PE machine type (0xAA64) and content hashes.Explicit DCS handoff
The companion DCS code allocates an owned 4 KiB UEFI runtime page and publishes a small versioned descriptor through a volatile runtime variable. The driver validates protocol magic/version, size, CRC and ownership before copying the bounded boot-argument structure. It then zeroes only the owned page and clears the variable.
The password payload is therefore not intentionally persisted in NVRAM, and the driver does not rely on scanning stale physical addresses.
Fail-closed activation
Arm64BootArgsHandoffRequiredis persisted before the first system-encryption transform can make the handoff mandatory. Once required, missing or invalid boot arguments fail closed instead of allowing Windows to continue with an unusable encrypted boot volume.Normal and rescue decryption clear that requirement only after the final header has been written, flushed, reread and verified as erased. The registry update is flushed before the rescue completion marker is removed, so a crash cannot prematurely disable the handoff requirement.
Validation
Built successfully from the final one-commit tree:
veracrypt.sysSHA-256C06AFDF5C6D79A64D8147DF98569C5804D3ACEE4F6E78C76E82EB2EC8603A4CF)/W4 /WXThree consecutive encrypted-system reboots passed in the Parallels ARM64 VM on the preceding evidence build. The final one-commit tree additionally contains narrowly scoped decryption-finalization durability hardening; it was rebuilt and independently reviewed. A second full decrypt/re-encrypt cycle was intentionally omitted to avoid unnecessary repeated full-disk transforms.
Diagnostic builds used during development verified DCS payload CRC, disk identity, header read/salt, KDF/decryption and mounted/encrypted state. Oracle, breadcrumb, stage-limit and lab-only logging code is absent from this PR.
Release integration
Runtime validation used locally test-signed components. Official driver and EFI signing remain part of the VeraCrypt release process; no test certificate, private signing material or signing bypass is included in this PR.
Related work
The mounted-volume direct-I/O optimization is intentionally isolated in #1839.