How to Dual-Boot Ubuntu 20.04 and Windows 10 with Encryption
mikekasberg.com
mikekasberg.com
Run each operating system in it's own VM and you can encrypt its folder. Not an option because you want to use games on your Windows and those are notoriously difficult to run inside a VM? OK, then how about:
Run a hypervisor on bare metal, like VMWare ESXi. You get now each operating system to be running on bare metal just like if it's alone and on Windows you can definitely play those notorious difficult games.
One still can put the less used system into an external SSD and boot from that. Much simpler.
The lengths some people go to continue working with Windows and the hassle they are putting up with for that amazes me.
Agreed, even gaming on Linux has progressed to the point that unless you're a competitive gamer you can play nearly any Windows game on Linux thanks to Valve's Proton, as well as the advancements made by the Wine team and the growing Vulkan support by game developers.
Can we please be honest and say that with some or a lot of work we can get many games running in Linux but is expected of you to know your way around Wine tech to configure and fix stuff.
Similar complaint about Arch/wayland/CoolShit2000 works great for me but the full truth is hidden that it kinda works if you use this DE, and this Video card, and not use that feature and you read the wiki before you do anything.
Any other Linux users that agrees with me and is tired of the misleading "it works perfect now"
So, I never said Proton was perfect or that it works with every game. I also mentioned Proton as only one of several technologies for playing previously Windows-only titles on Linux.
I get where you're coming from, and I have had my own frustrations with Proton in the past. With that said, even some native Linux ports have been problematic (Rust, 7 Days to Die, etc.) so it's not just Proton itself with the issues. Overall though, my experience has been overwhelmingly positive lately, and certainly far better than it was ten years ago.
I would say if you want to play games on Linux that are not official you will need to be prepared for some reading and trial and error, do you disagree ?
I didn't have to configure a single thing to get excellent and bug-free performance on games like Witcher III and GTA V, and a host of others too.
It is also true that some games are supported by Valve and they should just work.
But there are more games that don't "just work" then games that do. I would prefer to the community would be more honest about it, like if you want to convince someone to try Linux and you show him that his preferred game is "Platinum" or "Gold" but the reality is different then the Linux community will become even more of a joke.
Most all of the games worth playing (factorio, subnautica, KPS etc) either have native linux clients or work fine via proton/wine, but the latest and greatest non-indi titles generally don't. Anti-cheat/DRM/spyware is a linux killer because it wants to inspect the operating system during play. Whatever the latest batman game is called... it probably doesn't work.
This is my conclusion as well. Almost everything I want to play runs on Linux one way or the other, so this has become a non-issue for me.
I agree the latest DRM'ed AAA game probably doesn't work (yet), but I wouldn't want to play it anyway.
There are workarounds to hide the fact that you're running a VM from the guest, but it's not worth the effort and in fact the more workarounds you apply, the higher the chance of getting banned if you trip their detection code.
Other than dumb anticheat software, gaming on a Windows VM is feasible, if not expensive, when Proton doesn't work.
No kidding. I have a hacked-together solution including 2x GPUs, an HDMI 2.0 KVM, a "USB switch" which is flaky as hell (because the KVM emulates HID devices / doesn't support USB 3.0.), the guest (Windows) and host (Linux) share memory to avoid latency in the audio path, a second NVMe drive so the guest can have native access to storage, a second USB controller so I can pass USB 3.0 devices to the guest, and I bought an entire new motherboard and CPU (AMD TR 3960x + TRX40) because the Intel non-server silicon doesn't do PCIe ACS[1] and I got sick of building a custom kernel, etc.
All this so that I can essentially play two games on Windows that I can't/won't play on Linux. One is Stellaris: which runs on Linux but has massive issues w/ Wayland. The other is FFXIV (an MMO) which I'm sure you could coax into running w/ Wine, but I don't want to get banned from an online-only game because of some overzealous anti-cheat thinking Wine is a hack.
At this point I think I'm a slave to the sunk-cost fallacy. I've entertained buying a 300$ KVM[2] just to simplify this setup a tiny bit. I'm severely constrained in terms of case/motherboard/CPU options because of the insane amount (& spacing) of PCIe I/O required, before getting a proper system that supports ACS I would constantly run into weird QEMU/KVM/kernel bugs, etc.
I want off Mr. Bone's Wild Ride.
[1]: http://vfio.blogspot.com/2014/08/vfiovga-faq.html [2]: https://store.level1techs.com/products/kvm-switch-single-mon...
This is exactly how WSL2 works. Windows and Linux run as guests under Hyper-V.
For example, this architecture prevents other hypervisors from running¹.
If one wants to run, say, a fancy filesystem that is native (to Linux) and/or stable, again, one can't.
If one considers Linux the primary O/S, they could give a shot at VGA passthrough - I assume that if the system supports ESXi, it should support VGA passthrough as well. I personally prefer it to a native Windows - besides not having to perform reboots (which is minor), I like to have a snapshottable system. The caveat is that if one wants a very stable guest, they should reserve the GPU for that purpose (I do).
[0]: https://lore.kernel.org/lkml/20200914112802.80611-1-wei.liu@...
And I can have running wsl2 session with RDR2 running.
as far as I can tell, enabling wsl2 (thus hyperV) did not slow down windows in any meaningful way I could find.
Enabling wsl2 enables Windows' "virtual machine platform", which Windows itself will then run on top of as a guest.
And yes RDR2 is running stable 100fps uwqhd at max settings on my machine under these conditions.
My progression has been:
-> 2000 dual-boot Gentoo/Windows (mostly because of gaming) -> 2012 (? I think, maybe 2014) Gentoo host with Qemu guest Windows GPU Passthrough (which was still sort of a dual boot since I could actually boot into that Windows SSD normally) -> whenever proton came out, Gentoo 99% of the time and rarely boot into Windows getting rid of GPU/SSD passthrough because it was cool but ultimately too much hassle -> now almost never boot into Windows (once every few months) except when working with one specific researcher who only uses Matlab, because Win is where my working Matlab install is ...
Inertia has kept the dual boot around because I don't want to set it all up again in a VM really.
Perhaps you could try GNU Octave.
This is how Qubes OS works: https://qubes-os.org. Yes, video passthrough should be possible: https://qubes-os.discourse.group/t/list-of-programs-that-wor....
It has a web gui allowing you to vnc* and interact with the virtual machines using only your browser, or you can install apps on your PC for a better experience.
You can limit the resources that each VM has, only a portion of the RAM, only some of the CPU threads etc.
It has a free version, but IIRC the free version limits you to 8 CPU threads per VM.
You can also pass through hardware to an individual VM, .e.g. a whole graphics card and a USB keyboard/mouse. This means that if you were looking at the monitor and using the keyboard/mouse then you wouldn’t be able to tell it’s a VM. If you had two of each peripheral, you could run two local machines from a single tower.
I think Linus did something similar with unraid (same idea) and ran 8 (?) gaming VMs from a single tower using 8 GPUs, 8 monitors etc.
Note that nvidia doesn’t like you using GPUs in VMs and actively fights against it in the drivers but there are workarounds.
*not actually vnc, something propriety.
Probably gonna need a tutorial for that, too. Was trying to set that up this weekend, but there didn’t seem to be an obvious option for dual booting with full disk encryption in the Ubuntu installer.
You can get a 240gb SSD for less than $30 these days.
(I'm assuming this is starting on a machine that already has windows on it because that's how my computers generally come (although maybe not the future since Lenovo is selling Thinkpads with Linux now):
Step 1. Install Ubuntu (let it set up the dual-boot stuff for you). The main advantage of this approach is I don't have the issue where grub can't boot windows as described in the article. (NOTE: ubuntu's installer won't do encryption in this setup for some reason: Ubuntu please fix this and save me the following steps!):
Step 2: reboot into the installer. Now things are going to get crazy.
Step 3: shrink the ubuntu partition as small as it will go (resize2fs -M ...). Then create a new partition of the same size at the end of the drive and copy the data over to the new partition.
Step 4. delete the original ubuntu partition. replace it with a /boot partition and a luks partition.
Step 5. Copy the boot stuff into /boot, copy the rest of the data onto your new encrypted / partition (i usually do lvm here also). chroot into the /, do the mounting stuff TFA suggests, install lvm/dmcrypt/etc. Reconfigure your initramfs and run update-grub.
Step 6. Delete the copy of the original ubuntu partition made in step 3 and resize the encrypted partition as needed.
OK I agree that's a pretty ridiculous sequence and I wish Ubuntu would do it for me, but it's pretty cool that it can be done at all (takes about an hour).
I've been doing embedded development (with a Linux based toolchain) on a Windows 10 host with Ubuntu in a VM, and it seems to be plenty nice on modern hardware (and a lot of RAM). And I don't have to make a choice to boot back and forth: Two systems for the price of 1.5. :)
Edit: My question aside, I fully appreciate the article's primary goal, which is to document the nonobvious hoops the author had to jump through to get dual boot to work. Thanks!
That's one case where you don't want to pay the performance overhead for virtualization, but I'm sure there are plenty of other cases where dual-booting is preferred.
My primary goal with the Windows partition was gaming, so it made more sense to dual boot than run Windows in a VM. So dual-booting made the most sense for me, even though as you say a Linux VM can be a great dev experience too.
You can however use other tools to encrypt/decrypt the windows drive besides bit locker and it will work.
TPM2 to decrypt your Linux drive on boot is a bit of a pain too.
The only way to prevent that is requiring a BIOS password at boot (not very common) and secure boot (and like in the article many Linux users skip that because it can require extra knowledge and extra work.)
So you replaced entering a disk password by entering a BIOS password. What's the benefit from usability perspective?
(Yes, secure boot would add security I don't try to deny that.)
As others have said, attackers are meant to be prevented from getting in directly by the Windows password, and they can't just put the disk in another machine to read because it wouldn't have the right TPM. I don't know enough about TPMs to know what stops an attacker from installing an OS on another hard drive on the same motherboard and using that to access the TPM to decrypt the target drive, but presumably that's been thought of. It's certainly susceptible to turning the machine on and then physically lifting the RAM out into another machine to extract the key (cooled RAM keeps its contents reliably for long enough for this to be feasible), or dismantling the TPM, but both of these are high skill attacks.
The TPM cannot prevent that, you need secure boot. That will prevent the machine to boot into another operating system. But only if you delete Microsoft's public keys from your machine. Otherwise the thief can boot Windows and all Linux distros that have a Microsoft-signed shim. Deleting Microsoft's key on a machine that is supposed to run Windows as dual boot would mean that you need to sign Windows yourself. Probably doable, but yet more hassle.
So probably disk encryption with TPM, i.e. no manual disk password raises the bar enough for the average thief bringing the device to a dodgy backyard shop. But not for a somewhat dedicated attacker. No state level resources needed here at all. Given enough time I might succeed, and I have zero practical experience which such attacks, I am just a normal software developer (having worked a bit with system boot, but not a whole lot).
Wait, why? I mean, they would be able to access the TPM, sure, but not the keys that would unlock the hard drive. This was my understanding when I played around with TPM: if the boot order has changed, no keys are given to the running OS. You can only reset them, but that just leaves you with an encrypted hard drive and no password to unlock it. I've only used it with LUKS though, not with Windows, but it'd be weird if the approach was different
Secure Boot actually does not help much here... since the idea is that thief wouldn't be able to change the disk contents.
I'm not completely familiar with Windows service management and how it handles logins - but doesn't the TPM auto decrypt function of Bitlocker mean that if you have a compromised system which has a dodgy service that starts at boot time it can potentially exfiltrate data from the machine without a user logging in?
Of course, if this is the scenario you're experiencing you have much bigger problems already haha.
It's moving the slider towards the "ease of use" end of the "security - ease of use" spectrum. It essentially outsources security to the Windows OS logon, at which point a whole bunch has started up in the background and the attack surface has substantially increased.
But it saves having to type in a second password.
Every once in a while Windows overwrite the boot sector and you have to stick in a rescue stick. Not a huge problem.
Seriously it shouldn't be hard - you should be able to install the OS's in any order and have the installer simply set up a boot menu asking which to boot. There should be some cross platform filesystem or LVM-like system so storage space can be dynamically shared with all the OS's.
Uninstallation of the OS should be as simple as installation too. Today as far as I'm aware no major OS has an uninstaller.
Each of your named OSes has different preferences as to which filesystem they will run on, each filesystem with different capabilities and expectations. Windows - NTFS, OS X - APFS and HFS+, Linux - depending on which flavour you choose. Thus an uninstallation program isn't really much use, because the installation of anything new should blow that away.
Or is it you wish that your computer had a bootstrap program when you powered it on which would source an installation image (for Windows, OS X, whatever Linux flavour you prefer)?
To that last one Apple machines do offer this in a limited fashion in the form of "Internet Recovery", plug in a blank disk into a Mac or delete the GPT on your SSD and it will offer to connect to wifi/ethernet to download the installation image for either the version of OS X it shipped with, or alternatively the version last installed (I cannot recall which). Though of course it won't help source any installation media of the other OS families.
This installation image is a cut down version of OS X which will provide just enough drivers to get the system functional, the disk drive formatting tools, a command line interface with a number of basic system tools to troubleshoot with, and a functioning web browser.
Except it isn't... Start with a dual boot windows and linux system, and delete the linux partition... And suddenly windows won't boot! Or with some UEFI setups, leaves linux as a default boot option that half boots linux and then won't complete because it can't mount the root filesystem.
It's just poor design.
I'm imagining something more like the UEFI menu having a "Right click, Delete" option next to each bootable OS. Clicking delete would run that OS's uninstaller code and refresh the menu.
You could likewise have a "Add new OS" button in the UEFI firmware where you can select from a list of available OS's to download from the net, or provide your own URL to an iso or some installation metadata file.
Forgive me if I’m incorrect but on most UEFI based systems shouldn’t the boot loader and all it’s dependencies live in the FAT32 EFI filesystem?
I know GRUB2 (which tends to be the most frequently shipped Linux bootloader for the major distros) is self contained in that regard; boot stanzas pertaining to Windows just point at Windows’ `boot.efi`, with the GRUB chain-loading that EFI program.
Deleting the Linux partitions your using should not affect that Windows entry.
Of course, it will knacker your Linux entries; though depending on how your distro does things, if the kernel and initial ramdisk are in the EFI you may get dumped into an emergency prompt on the root of the initial ramdisk (your “half-boot” example) and have the kernel itself tell you it can’t find the filesystems it’s supposed to use as the system root. But if GRUB can’t find the kernel (as in the case where the kernel is on another filesystem) it should tell you it can’t find it and dump you back to the menu, to choose how to proceed with this new information.
Ubuntu’s implementation of GRUB as one example includes a menu option to bring you to your UEFI configuration menu, where you may be able to an alternative bootloader program or boot from another storage medium.
Of course none of these things are new-user or non-technical-user friendly.
I do agree with you that these are poor user experiences, and that the low level user experience should be improved. But in certain cases - the half-boot example, this is actually very useful as a last resort troubleshooting stage.
Now I can’t speak for all UEFI implementations because many are garbage and barely functional, but most decent implementations do allow you to delete bootloader entries from them either from the “bios” menu or via “efibootmgr” on a Linux live disk - that said, this doesn’t delete the partitions underneath
An additional item of note is that most operating systems at install time treat themselves as first class citizens at best (Linux), or the only operating system to be installed on the machine (Windows). There isn’t likely to be much incentive for the developers to improve that.
Mainly because of how disrupting it is to have your dev environment torn down when you reboot and then having to set it all back up when you come back. Even with tmux and using resurrect it's not a seamless experience. This is an issue even with a few second turn around time on the dual boot itself.
Around 8 or 9 years ago I used to dual boot, then I transitioned to a Linux VM with Unity mode (vmware workstation's seamless mode to run apps in their own floating window) then to WSL 1 and now WSL 2. The only way I think things will get better is going native Linux with a GPU pass through KVM based VM running Windows to play games from Linux at native speeds without dual booting but it's a huge pain to set this up properly.
> Ext4 read/write for Windows, Btrfs for Windows
Useless if using LUKS.
> NTFS for Linux/Mac (FUSE or Paragon)
Useless if using BitLocker.
Other than that its a reason you don't want an OS specific FDE but a platform agnostic one. You can, of course, swap to such.
[1] http://augustbonds.com/luks-encrypted-ext4-drive-in-windows-...
It's best to fix this on linux with timedatectl. Changing it on windows often ends up being a cure worse than the disease.
Simple means different things to different people. I'm fine with messing with the registry, but I know several (technically inclined) people who are not.
I find it easier to change in Linux because it's either a setting or in a config file, depending on the distro.
Alternately, you can use timedatectl on distros with systemd.
If you use a non-systemd distro, try hwclock.
Based on my ddg-foo, I was mistaken about being able to configure it via a config file, short of putting it in .profile or some such other thing. That seems hacky though, so I wouldn't recommend it.
I just do a regedit in windows to fix it. But you can do the change in either OS
UTC is the default in many Linux distributions, but I wouldn't say "Linux sets the bios to UTC"; I've only ever seen it be an explicit choice.
If you want to use your customer-grade GPU on both the host and guest, there's only a single option: Intel. However, the current product on the dGPU market, Xe MAX isn't exactly the top-end GPU that people are searching for.
https://battlepenguin.com/tech/alpine-linux-with-full-disk-e...
I did this LUKS1 encrypted boot partition thing on a relatively recent laptop, and GRUB takes about 25 seconds to validate the passphrase. Once it loads the initrd, the early kernel environment validates the the root volume passphrase in about 2 seconds, presumably because it's using an optimized implementation that's available in the kernel but not in GRUB...
Right now I wouldn't recommend doing this unless you have a really good reason for encrypting the boot partition. Most people will be better off having an unencrypted boot and enabling secure boot with your own platform key instead.
When you set up the encrypted drive, it deliberately picks settings for this that will be as slow as possible to resist brute force attacks while also aiming not to take over 30s on your current CPU. You'd have to manually specify a lower iteration count to cryptsetup to get a faster unlock.
My /boot is a LUKS1 volume, and I thought that my GRUB boot passphrase for this volume was in the first slot, and that I was using the same iteration count as the root volume.
My / is a LUKS2 volume with a different passphrase that I need to enter after the initrd has been loaded. Decrypting the root volume is fast, so I suspect I set this one up correctly. Once the root volume is decrypted, I have a separate key on the filesystem to re-decrypt /boot so that it can be mounted without re-entering the /boot passphrase. This part is also fast.
Something must have gone wonky with the boot passphrase. Either a crazy iteration count or a key slot that forces GRUB to not test it first.
Whoops...
I already have enough trouble with an unencrypted file system
Not sure where to keep my user files. On NTFS, they are hard to reach from linux. On ext, they are hard to reach from Windows. On exFAT, there is no journaling
Now I put them all on NTFS.
I recently upgraded my laptop and stuck a new nmve ssd with hardware encryption features. It does have some security trade-offs but does protect decently against common theft and is hella convenient that it's all mostly managed in hardware beyond a pre-boot unlocker and a suspend-state kernel hack. Still had to dig deeeep into github issues to get it going in Linux. Works out of the box with Bitlocker allegedly.
IME it worked better the other way around, setting Linux to local time. But the Wiki recommends the opposite.
But the time is still an hour off
Will these all allow encryption?
I hope I’m just the exception here, but I’ve had to start re-evaluating what I’m going to do longer term, the short term is easier (push all).
I don't know, but I think it's an interesting idea. ReactOS on zfs...
This is apparently being worked on... in the future I will be able to run the IDE inside WSL and it will bridge X11/Wayland to Windows.
That means that VSC installs language server inside the wsl2 environment, I use it at home for my rust/python development and can't tell the difference.
This is why UEFI was invented, and if You actually read the post, you would know it details how you set this up with UEFI instead of legacy boot and have none of those troubles.
File performance is similar to native as long as you store the files in WSL2.
Only issue, I have faced is that port forwarding does not work sometimes and have to restart WSL2 for fix which I solved using a simple script.
Other than that everything has been a smooth sail. Native docker is a huge win in my list.
I never used the private ip. So, I can't say anything.