The following is a list of valid distributions that can be installed.
Install using 'wsl.exe --install <Distro>'.
NAME FRIENDLY NAME
Ubuntu Ubuntu
Ubuntu-24.04 Ubuntu 24.04 LTS
openSUSE-Tumbleweed openSUSE Tumbleweed
openSUSE-Leap-16.0 openSUSE Leap 16.0
SUSE-Linux-Enterprise-15-SP7 SUSE Linux Enterprise 15 SP7
SUSE-Linux-Enterprise-16.0 SUSE Linux Enterprise 16.0
kali-linux Kali Linux Rolling
Debian Debian GNU/Linux
AlmaLinux-8 AlmaLinux OS 8
AlmaLinux-9 AlmaLinux OS 9
AlmaLinux-Kitten-10 AlmaLinux OS Kitten 10
AlmaLinux-10 AlmaLinux OS 10
archlinux Arch Linux # Arch found here
FedoraLinux-43 Fedora Linux 43
FedoraLinux-42 Fedora Linux 42
eLxr eLxr 12.12.0.0 GNU/Linux
Ubuntu-20.04 Ubuntu 20.04 LTS
Ubuntu-22.04 Ubuntu 22.04 LTS
OracleLinux_7_9 Oracle Linux 7.9
OracleLinux_8_10 Oracle Linux 8.10
OracleLinux_9_5 Oracle Linux 9.5
openSUSE-Leap-15.6 openSUSE Leap 15.6
SUSE-Linux-Enterprise-15-SP6 SUSE Linux Enterprise 15 SP6
Ontop of that I also use it as my main distro for WSL2 for a few months (before I used the unofficial one).
> SecureBoot looks like a system designed to make it hard to change OS
To be fair SecureBoot is in a way just that: it is intended to only boot binaries that are signed with a key that has been enrolled into the UEFI. The main issue is like almost always how those keys are managed.
> Is this really true, in 2019 when this was written or today?
This is true in the sense that they only ship with MS' keys as trusted, but all MoBos (including laptops) I had allow enrolling your own. Some might handle not having MS' keys better (or at all) than others, but it should in theory be possible to remove them, whether it will boot after is a different question (see option-ROM [1])
> Is it possible to un-enroll the Microslop certificates
Technically yes, with a massive fucking asterisk: Some option-ROM are signed with the MS certs and if your Motherboard doesn't support not loading those (whether needed or not) you will not be able to sometimes even POST.
> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot).
The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...)
> The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
Isn't this already the status quo??
> It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...]
I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.
>IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Sounds like browserchoice.eu but even more pointless. For the normies who don't care about what keys they want installed, it doesn't make a difference. For people who want to switch to linux, it also doesn't make a difference because unless they're setting up their computer for the first time, because the windows key would already be installed. The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.
You are missing the big picture.
> The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.
On the contrary. It means only the currently installed OS will ever boot. If you wanted to switch you would enter the bios, clear the keys, then boot into the new system. That's roughly analogous to re-locking the bootloader on a pixel.
Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
>Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
There will still be the situation with microsoft signing third party bootloaders, because various legitimate system utilities (eg. the kaspersky rescue disk mentioned in the OP) will still need it, and telling users to clear their keys willy-nilly is just going to train users to blindly clear their keys whenever something goes wrong.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Let's be clear here. Most computers ship with Windows pre-installed, thanks to Microsoft's exclusivity deals with OEMs and the general assumption of Windows as the default OS.
Most users, even those who want to use Linux exclusively, will never be able to utilize the first-OS-install functionality you propose, because the OEM will already have installed Windows on their behalf.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
I was talking about the same "install" that is already done (pre-installed on the drive that is first booted).
Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them.
This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens.
What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack.
If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said.
UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot?
PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you.
To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine.
> No one said anything about a nag screen.
The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today.
> For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader
So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
And how many times has Intel's trusted computing platform been breached now? Would you also claim that SGX is not a meaningful security measure? Recall that the alternative to SecureBoot is ... oh that's right, there isn't an equivalent alternative.
People have broken into bank vaults. That doesn't mean that bank vaults don't provide meaningful security.
> So do UEFI systems. Install OS, test boot, enroll PK.
"Enroll PK" is "draw the rest of the fucking owl" territory.
I believe you somewhat misunderstood OP. The description was of the empty hardware. Typical hardware would ship with an OS already installed and marked as trusted. It's the flow for changing the OS that would be different.
> automatically enroll the first key it sees from disk (supply chain issue, like I posted)
I'm unconvinced. You're supposing an attacker that can compromise an OEM's imaging solution but not the (user configurable!) key store? That seems like an overly specific attack vector to me.
The breach in TFA happened because Microsoft actually did something benevolent and it blew up on their face. Now almost all of the hardware that takes security a bit seriously (basically expensive business class computers) have to upgrade their UEFI FW (many have already done ao via Windows Update).
No single point of failure will protect you fully. UEFI SB is just one layer. And nobody ever would protect you from a dedicated nation state (except another nation state). Unless you own the entire supply chain from silicon contractors all the way up to every single software vendor and every single network operator, you cannot fully prove things aren't snitching on you.
I have always enjoyed the experience of installing my favorite hobbyist teletype operating system. I think the last time I used a preinstalled on a personal machine was windows 3.1 on a 486.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?)
If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
The enrolling of the certs happen before the bootloader calls `ExitBootServices()` (I think that is what the function was called). Up until then the bootloader still has elevated priviledges and can modify certain UEFI stuff it can't after, including enrolling certs.
systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2]
No, there's nothing special about the spec secure boot variables as far as boot services goes - you can modify those in runtime as well. We use boot service variables to protect the MOK key in Shim, but that's outside what the spec defines as secure boot.
> Also, is Harvard part of the "public school system" now?
Pancake... waffle... Where in the statement do you see them saying that?
They were implying that the same people that think "public school system is there to turn kids gay and trans" are the same people that think that Harvard is "woke".
IMO OOM killing should be reserved for single processes misbehaving. When a lot of different applications just use a decent amount of memory and exhaust the system RAM swapping to disk is the appropriate thing to do.
> To be honest I don't know why it's such an issue on Linux. Mac and Windows don't have this issue at all. Windows presumably because it doesn't over-commit memory
To be fair, my Windows system grinds to a halt (not really, but it becomes very noticably less responsive in basically anything) when JetBrains is installing an update (mind you I only have SSDs with all JetBrains stuff being on an NVMe). I don't know what JetBrains is doing, but it consistently makes itself noticable when it is updating.
I have had this happen in the past (not very often though), and another saving grave of Windows is you can press ctrl-alt-del, which somehow seems to pause the rest of the system activity, and then see a process list and choose which one to kill.
Linux doesn't have anything like that. KDE seems to have a somewhat functional Ctrl-alt-del menu - I have been able to access it when the rest of the shell gets screwed up (not due to OOM). But inexplicably the only options it has are Sleep, Restart, Shutdown or Log out!! Where is the "emergency shell", or "process manager" or even "run a program"? Ridiculous.
I think Linux GUIs often have this weird fetish with designing as if nothing will ever go wrong, which is clearly not how the real world works. Especially on Linux. I've genuinely heard people claim that most Linux users will never need to use a terminal for example.
> Systemd for some reason seems to uniquely be the epicenter of giant facepalm bugs like LEAVING THE SYSTEM FIRMWARE VULNERABLE TO AN RM -RF COMMAND
I am very sorry to inform you but efivarfs is something coming from the Linux kernel. Being able to rm -rf it is squarely something that is entirely on the kernel implementation, WHICH THE AUTHOR OF EFIVARFS EVEN ADMITS[0]
Arch already has an official WSL distro. Though you are still at the mercy of the WSL2 kernel which is always a bit behind (currently 6.12)
reply