Windows WSL2 and LUKS

wsl-luks.md

If you have a LUKS-encrypted partition on another disk, it's easy to mount it inside WSL.

List your disks:

> wmic diskdrive list brief

Mount the whole disk inside WSL (using --bare so WSL doesn't attempt to mount it automatically):

> wsl --mount \\.\PHYSICALDRIVE1 --bare

Now inside WSL, check the device name of the mounted disk (something like /dev/sd*):

$ dmesg | tail

Open the LUKS device (it'll prompt for your passphrase):

$ sudo cryptsetup luksOpen /dev/sdd3 my-encrypted-disk

And mount it somewhere:

$ sudo mount /dev/mapper/my-encrypted-disk /somewhere

Avoid mounting on /mnt because that's usually used by WSL itself to mount your C: drive.

Hello,

I wanted to express my gratitude to you for sharing the information on how to mount a cryptsetup in WSL in the most simple way that I found online. Thanks to your guidance, I was able to effortlessly execute the "luksopen" command and mount my LVM partition, which uses the ext4 file system – just as I'm accustomed to doing. I've streamlined the process by directly running 'commands' in wsl.exe within a PowerShell script, and it even worked seamlessly with a GPG-encrypted keyfile.

I truly appreciate your help. Thank you very much! WSL going strong

Cipher used over here: twofish-xts-plain64 - works fine to decrypt drive even if the twofish module seems missed in in /proc/crypto in my wsl2 setup.

⚠️ NOTE

This has nothing to do with the original post. This is just a warning message for everyone testing LUKS with WSL. If you're seeing this, consider yourself warned. Backup your LUKS header NOW!

Important Update: Cautionary Advisory on Using WSL with Multiple LUKS-Encrypted Drives

For those diving into integrating WSL with cryptsetup and LUKS-encrypted drives, I cannot stress enough the paramount importance of backing up the LUKS header. I recently encountered an issue where Windows inadvertently introduced a 16MB GPT header to my drive. This action put my entire 16TB drive at risk.

This anomaly presented itself upon connecting a Funtoo SSD, housing three partitions:

1. BIOS_GRUB
2. Boot partition
3. Rootfs on LUKS2 encrypted with a GPG key.

Upon further examination, I identified that this GPT overwrite potentially stemmed from interactions between the SSD and a connected USB drive. My proactive decision to back up the LUKS header was the sole reason I managed to restore and access my data. Without this precaution, the outcome might have been irrevocably dire.

Should you be considering a similar WSL setup, I earnestly urge you to make a LUKS header backup prior to any integration or modification steps. The inherent risks are significant, and a pre-emptive backup could be the pivotal factor between a successful recovery and irreplaceable data loss.

Technical Insight without modifcations:

t&fh
TCPAu2
r,fh
fSfSfUfh
Invalid partition table
Error loading operating system
Missing operating system
EFI PART
{"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha512"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":18,"memory":1048576,"cpus":4,"salt":"mvXLzWn1IYEOb/a8g0ezfnNTVu9rvwsxC5eMo9e2CiQ="}},"1":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"290816","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":7,"memory":1048576,"cpus":4,"salt":"YTnf/ypEI6y0ssZlRHq3cfRq16175r6aFX2XTUSFN1c="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0","1"],"segments":["0"],"hash":"sha512","iterations":173835,"salt":"su+921tALdeckXOJ4W4L2mfZkOKJWUrGwvMjWYFgGlw=","digest":"t4qCg7dnLsHNGhtSCjwxizOxsXFyyJ0fHMxPu9SZAs3XMQU1e7z93Poi1R3UMCUtjD0TjtAARqpHqMw2QEh4+A=="}},"config":{"json_size":"12288","keyslots_size":"16744448"}}
X".e
...random data to the end...

Key Observations:

1. EFI PART: Indicates the EFI GPT (GUID Partition Table) header's presence. This segment was added when Windows mistakenly appended a GPT to the drive.
2. LUKS2 Data: The JSON-style data beginning with {"keyslots": ... corresponds to the LUKS2 header configuration. This data delineates encrypted content unlocking protocols, algorithms employed, key derivation specifics, and more. The LUKS data's lingering presence implies the GPT header didn't completely overwrite the original LUKS2 header. This partial preservation, combined with my backup, facilitated the successful data recovery.

This incident highlights the significance of prudence when working with raw disk tools. Even minimal, unintended alterations can culminate in data access barriers or outright loss. Vigilant backup practices, especially concerning vital headers or metadata, are indispensable.

Where does /somewhere inside the WSL end up in windows explorer?

@nextgenthemes In the latest Windows 11, there is a Linux icon where This PC and Network are. You can access the WSL filesystem there.

So /somewhere inside WSL would be \\wsl.localhost\Ubuntu\somewhere (if you're using the default Ubuntu distro).

I getting the following error when attempting to mount my USB drive:

wsl --mount \\.\PHYSICALDRIVE4 --bare

The system cannot find the drive specified.
Error code: Wsl/Service/AttachDisk/0x8007000f

You haven't run into this? There's some discussion here → microsoft/WSL#9290, but doesn't seem helpful.

I'm able to mount and access the encrypted disk within Linux but the mounted folder shows as empty within Windows Explorer. wslview also errors when trying to open a file within the encrypted disk.

@ghost thanks for the warning. I made sure to back up