I dual boot with win 11, I do so for programming purposes, not gaming. I read online that the game straight up blocks Linux on all fronts (typical EA). So, I booted into win 11 and launched the beta. It still refused to start and complained that secure boot was “disabled”. Booted into BIOS and it was enabled, but not active. I had to reset the keys to the windows default keys to be able to play this game. This is a no go for me. Not giving them my money until they stop this bullshit. Just wanted to let everyone know the situation so far.

  • fuckwit_mcbumcrumble@lemmy.dbzer0.com
    21·
    22 hours ago

    I’m literally dual booting windows 11 and Linux right now. It actually just worked. After install it just asks you to approve the key, you confirm it, and boom it’s done.

        • teawrecks@sopuli.xyz
          6·
          22 hours ago

          Yeah, so that’s possible because Canonical has enough sway to get their key to play nice with manufacturers’ firmware. If you are on almost any other distro (arch included) or if you build your own kernel, it’s a headache just to get it to work at all even without dual boot. It also just might not even be possible due to a bad implementation on your motherboard (results ranging from dual boot windows refusing to boot, to a bricked motherboard).

          Here’s the process for enabling secure boot for arch users. Make sure to peruse the section on dual booting.

          If you’re wondering why it’s so complicated, it’s because of what secure boot is: you want to be sure you’re booting into binary that’s signed by a set of special keys. But Linux is not one binary that can be signed by Linus Torvalds, it’s a bundle of source code that is built by end-users. So if you decide to make any changes to the kernel you have on ububtu, you won’t be able to convince Canonical to sign your build, and you will need to jump through all the hoops on that arch wiki.

          There are many reasons for the headache, but primarily I’d say it’s because UEFI is closed source, and msft designed Secure Boot for it, and then manufacturers didn’t care about supporting it any more than the bare minimum. And all of that together results in an ecosystem of devices that favor MSFT. That’s why Linux users don’t like secure boot.

          • dafta@lemmy.blahaj.zoneEnglish
            3·
            20 hours ago

            I’m saying this as someone who has a self-signed key + kernel + bootloader + dual boot with windows. I have Arch and I dual boot windows, and the setup was literally three commands.

            Enable secure boot setup mode and then do the following:

            sbctl create-keys to create the keys

            sbctl enroll-keys -m to enroll the keys to BIOS, including microsoft keys

            sbctl verify | sed -E 's|^.* (/.+) is not signed$|sbctl sign -s "\1"|e' to sign everything that needs to be signed.

            And everything is signed automatically on an update with a pacman hook that comes by default when installing sbctl.

            That wiki entry lists all the possible ways to do it, for all combinations of bootloaders and secure boot tools. You only need one of them, for example 3.1.4. which is what I just described.

            • teawrecks@sopuli.xyz
              1·
              20 hours ago

              Cool, good to hear!

              A few questions:

              • is this with grub?
              • if so, and I make edits to grub, do I need to trigger a re-sign manually?
              • have you ever had any issues with the pacman hook?

              I think the part that has me most spooked is the “Replacing the platform keys with your own can end up bricking hardware on some machines” warning.

              • dafta@lemmy.blahaj.zoneEnglish
                2·
                19 hours ago
                1. This is with systemd-boot, which I switched to because it’s easier to use a unified kernel image with, but it should work just fine with grub as well. The last step will sign everything that needs to be signed, including grub and the kernel images.
                2. You only need to trigger a re-sign if you update grub using grub-install. If you just change the grub config, you don’t need to re-sign it because the config is loaded once the signed grub is already booted. This is another reason why I went with systemd-boot and unified kernel images, because I work with sensitive data and maybe I’m a bit too paranoid, and don’t want anyone to be able to tamper with my boot in any way. This is also possible with grub and using an encrypted boot partition, but systemd + UKI + full system encryption was just easier. If you’re not worried about evil maid attacks and just want secure boot, grub will work with no additional setup.
                3. No issues with the pacman hook, it triggers every time there’s a kernel update or nvidia update, and since I’m using mkinitcpio and UKI, the signing is usually already done by mkinitcpio before the pacman hook is ran, so the pacman hook doesn’t really ever do anything. It’s all done in the mkinitcpio hook.

                As for bricking your motherboard, this only happens if your motherboard or any other component uses the microsoft vendor keys as part of the boot sequence, and it’s only really a hard brick if it’s your motherboard that uses it. If it’s any other component, you can remove it and readd the microsoft keys and it’ll work again when you add the component back.

                And the key part here is replacing the platform keys. If you just always use the -m flag on sbctl enroll-keys, you’ll enroll both your own keys and microsoft’s, meaning no replacing necessary. If you always use -m, there’s no real risk really, because you’ll always add the microsoft keys that your hardware might need. Plus, if you’re dual booting with windows, you need the -m to have windows secure boot work, anyway.

                If you’re extra paranoid, you can also add the -f option which should also include all the keys that your motherboard comes with by default, if it contains more than just microsoft’s keys, but this shouldn’t really be necessary.

                • teawrecks@sopuli.xyz
                  1·
                  10 hours ago

                  Thank you, that’s super helpful info.

                  If you’re not worried about evil maid attacks and just want secure boot…

                  It is sad to me that that is my situation actually lol. Or rather, a random windows app just wants secure boot to work and is otherwise not worried about evil maid attacks.