sudo needs to be used
#[SOLVED: just switch to qemu] How can I make secure boot work in virtualbox
soft herald
@exotic crater try removing the immutable attribute via sudo chattr -i <filename> and then make sure it's writeable as root via sudo chmod 600 <iflename> and chown root <filename>
soft herald
hmm, we'll try one more thing, but I think the issue here may be the VM settings. can you try mount -o remount,rw,nosuid,nodev,noexec,relatime efivarfs /sys/firmware/efi/efivars followed by an ls -lta /sys/firmware/efi/efivarsif ownership is root:root, there is no immutable attribute, and rw exists for root/owner, I think the issue may be due to the VM configuration. Can you get us a screenshot of secure boot being enabled from VMware? Also have you entered the VM's firmware/bios and reviewed the secure boot settings so that you're currently in 'enroll mode' (basically clearing all keys)
soft herald
@exotic crater I was able to reproduce this and had similar issues when using bootctl as well. Systemd-boot would load in auto-enroll mode but it too had issues enrolling the secure boot keys. Are you open to trying another hypervisor such as Vmware? The latest workstation provides a free user license
soft herald
Just as an fyi, still trying to make sure you have a working solution for you. The latest VMware workstation does indeed support secure boot and I confirmed I could boot a Xubuntu iso after enabling secure boot. However, I'm running into an issue where I cannot find a way to enter 'setup' mode and this is working because Ubuntu's shim is signed by Microsofft. Just to to see our options, which operating system is the Host machine running @exotic crater ?
soft herald
Wow. That was very...painless! The hardest part will actually just be setting up libvirt/kvm, so I'll provide more detailed steps there as I really didn't divert from the wiki for the sbctl commands
Install virt-manager and the ovfm EFI firmware:
pacman -S virt-manager edk2-ovmf qemu-base && sudo systemctl enable --now libvirtd.service libvirtd.socket
Make sure the kvm module is loaded
lsmod|grep kvm
You should have kvm and kvm_intel or kvm_amd as such
kvm_amd 237568 10
kvm
If it is not loaded, try loading it:
sudo modprobe -r kvm
If that returns an error, restart and into the BIOS and ensure Virtualization features are enabled
Then enable nested virtualization on the intel or amd module (not necessary but helpful if you plan on using KVM some more)
sudo modprobe -r kvm_amd
sudo modprobe kvm_amd nested=1
Make that change permanent:
sudo -u root bash -c 'echo "options kvm_amd nested=1" > /etc/modprobe.d/kvm.conf'
Then start virt-manager. Click on QEMU/KVM -> Virtual networks and you can use a default NAT network that provides DHCP on a subnet that doesn't already exist on your system. This is fine because virsh creates a bridge interface such as virbr0 that serves as a gateway device for your VMs and will make them accessible to your host
Once done, create a new VM and go through the wizard picking your desired options and the archiso, as well as a network interface on that NAT network. Be sure to 'customize before installing'. Otherwise, you will have to edit the VM's XML or create a new one to enable EFI. The two main items you want to select are in the 'Overview' tab in the screen after you check 'customize before installing.' You'll want to select machine type Q35 and secureboot EFI firmware '/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd'
Review the other options and choose any that are to your liking. I also did add a TPM version 2.0 device (you can leave all settings as default other than 2.0 for the version). Then begin install and proceed as usual
Once done, hit delete to get into the BIOS and locate the Secure Boot settings. It will be disabled. I reset the keys to default just to be 100% certain enroll mode was triggered
yeah, just that and the base for for qemu
the rest was honestly just following https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Assisted_process_with_sbctl to a tee, with the exception that sbctl verify indicated 3 files to sign, the other not that wasn't listed in the wiki for me was /boot/EFI/systemd/systemd-bootx64.efi
so it's basically 'sbctl status', create the keys, enroll the keys, sign the two bootloader files, sign the kernel. check the status again and you'll see it toggle from enroll mode=enabled to enroll mode=disabled. Then reboot, go into the BIOS to double check the Secure Boot Flag is now toggled as X and you should be able to boot without a rejection and once up, check 'sbctl status' again
Going forward, the main issue would be that if you use multiple hypervisors, that only one can be active. For Virtualbox, it's a bit picky about which modules are loaded, so once you ensure all your kvm machines are off, you'll modprobe -r kvm_amd (or intel) and kvm, then start virtualbox
But in all honesty, kvm is really good in terms of speed compared to vmware and virtualbox if you're doing a lot of VMs
ah, you can skip the step about creating /etc/modprobe.d/kvm.conf in that case or delete it if you ran it
oh, and do also run the sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.eficommand so that pacman always copies a signed boot file when it updates sytemd or the kernel
outer lotusBOT
lionel_hutz6990 received a thank you cookie!
exotic crater
[SOLVED: just switch to qemu] How can I make secure boot work in virtualbox
soft herald
@exotic crater Apologies I went to bed shortly after that. So to address your question about the signing your initramfs and ucode, they don't have to be signed because per the EFI secure boot boot spec, the requirements are that all UEFI executables (PE executables) are signed. These include the kernel itself, the kernel modules, and the bootloader. The initramfs image is not a PE executable file nor is the processor microccode image. In the case of the initramfs, the signed kernel is what loads it and not the motherboard's firmware. By default when the kernel is signed it doesn't verify the initramfs but can be configured to do so and in the case of modules, it's the kernel that verifies the modules are signed (not the motherboard as once you have a signed bootloader and kernel and they've been loaded, all responsibility for validation is handled by the kernel). The same applies to the microcode, though you may want to verify how you're loading it. You can either load microcode via a bootloader entry or you bake it into the initramfs (see https://wiki.archlinux.org/title/Microcode if you need assistance in how you're loading it). But both methods are done during the initramfs stage where the signed kernel is already loaded. Technically though, you should be able to sign any file involved during the entire boot process
, but the tooling is a bit limited as sbctl only supports signing PE executable files. You can workaround this by generating a unified kernel image, which will contain a kernel, the initrd, and microcode (either inside the initrd directly, or specified when generating one). See https://wiki.archlinux.org/title/Unified_kernel_image. After you have a unified kernel image, you'd sign it with sbctl as you've done previously for the other binaries and at that point, you can either have systemd-boot load the UKI/.efi binary, or you can manually go into the bios/firmware and set
soft herald
that .efi file as a boot option, or you can have efibootmgr create an entry for you in the firmware and you'll be able to boot a single file containing the needed boot files. Just keep in mind that systemd-boot technically uses all those conf files in your output (excluding microcode and initramfs). Those would have to be left unsigned and I'm not aware of any tooling that can do this for systemd-boot or if this feature is even supported. I was able to find someone doing this with grub https://askubuntu.com/questions/1247826/secure-boot-verification-of-initramfs (see the top answer --> 2 --> second bullet point). They gave a method of how to do this for each individual file, including the conf. If you're simply worried about the output not looking right on the sbctl verify command, this is due to an upstream bug https://github.com/Foxboron/sbctl/issues/433 https://github.com/Foxboron/sbctl/issues/398 where it checks against all files in your ESP and not just EFI PEs, but it looks like the author is working on a fix. Once that's fixed though, you'd stll want to verify the actual data you get, as it may indicate a PE for another installed operating system like Windows or Linux and it may get a bit tricky here
For Windows, just let the Microsoft keys handle this (so importing their keys via enroll-keys -m will suffice) and ignore any files in /boot/EFI/Microsoft if their in the output
soft herald
So the -m flag enrolls the default microsoft keys, in addition to the ones you you generate via create-keys. That will make sure you can still boot Windows because the motherboard will will enroll the Microsoft keys you already have present
I think if you REALLY want to be certain nothing is borked, you can sbctl export-keys --dir /root/OEM-keys prior to doing anything
and then you'd 'sbctl reset' 'sbctl create-keys' and 'sbctl import-keys --dir /root/OEM-keys', then simply run a 'sbctl enroll-keys' and that will verify everything was as setup by your OEM and import the additional ones you created
but on real HW, best to not reset any keys at all, so if you can set your firmware to enrollment mode WITHOUT clearing the keys this is the safest route
and then the steps would be 'sbctl create-keys' 'sbctl enroll-keys -f' (actually just found out about this one a minute ago, so you can ignore the steps about exporting the current keys and then importing them again)
that -f flag will make sure the keys you created, in addition to the ones already present/installed by your OEM are what's inside the mobo's key DB
I'd honestly suggest doing a 'sbctl list-enrolled-keys' on your actual physical machine in a live environment, and compare it to 'sbctl list-enrolled-keys' on your VM to compare them (the Microsoft ones) and verify they're the same. That way you'll know for sure if the 'sbctl enroll-keys -m' is enough, or if you should import more keys via 'sbctl enroll-keys -f' and not clearing the keys
hmm, is secure boot actually enabled on the host or did you just clear the keys? @exotic crater
you shouldn't need to touch the host, but if you did, don't worry. I would first check if secure boot is actually enabled. If it isn't, you should be able to able to boot Windows. And if you did reset them, your mobo may have some settings where it clears all non-microsoft keys
what does 'sudo sbctl list-enrolled-keys' on the host show?
Wait, you were able to boot into arch and I believe this was your first time testing secure boot with systemd-boot, by doing it in a VM. So that tells me secure boot is off. And it is possible to boot into Windows 11 after secure boot is disabled @exotic crater. The requirements for installing Windows 11 are a secure boot/UEFI capable machine and a TPM, but it doesn't need to be enabled in order to install/boot it
I think you're fine in either case @exotic crater. Worst case scenario is that you deleted the microsoft keys (if it let you/doesn't have a fallback) and can't boot either OS when you enable secure boot in the bios. Firmware/BIOS updates, or just a reflash of your current Firmware version will most likely get them back for this reason/that they need to be renewed sometimes. And if the firmware doesn't revert this, they can be re-imported via the sbctl tool in setup mode
and if your firmware doesnt look that tool, we can find them online and save them to a flash drive 🙂
soft herald
You can upgrade to windows 11 w/o a tpm using this registry workaround btw, https://www.tomshardware.com/how-to/bypass-windows-11-tpm-requirement. I just wouldn't recommend enabling bitlocker encryption if you don't at least have a TPM built into your CPU
Tbh, it's a mixture of curiosity / my own troubleshooting and seeing how I go from there. It really depends on where you want to start
Are you interested more in the systems side more (understanding how everything works in general) or more into the coding part of it?
Ah, it'll come with time and definitely as you start applying it after schooling is over. I think finding a particularly interesting area is a code way to start and to then go from there. W/ networking, you really gotta understand the big picture since it's involved at every layer of the stack basically lol
You can possibly get a bigger picture by doing some networking home lab stuff to play around with things like switches, vlans, routers, BSD based router firmware and then add on the hypervisor to where you configure things like virtual switches/bridges, VLAN aware networks, and then explore that further via your code which can automate a lot of this stsuff
I'd say setup some home lab stuff, or even create a VM running something like opnsense you can have an internal network for your VMs, then learn how to go about how to configuring the VMs to acctualy use that router and you'll find you'll learn a lot about things like linux bridges or virtual switches, networking from the OS perspective and as you troubleshoot issues with them don't be afraid to use tools like wireshark and tshark to see what's going where and why your connection isn't working
You definitely won't find lack of coding in a good devops role
Yep yep, set it up a few times, and then look into automating all the work and you can then in integrate it with other tooling like Opnstack or Vmware
Btw, I really recommend you look into LXD for a lot of this stuff. It's basically a VM container except all changes are saved to a drive
so you get all the speed of a container but the full OS experience with a really simple cli interface
yeah, its in the arch repos as a non-snap application
i kinda stopped doing a lot of vm spinups and use container VMs when possible since they're up in a second but can do what a VM can
yeah, they use some of the same underlying technology (well docker technically does this a lot differently now) to essentially isolate a process and its network namespaces into a container VM environment
you don't have to use lxd and can do similar with systemd, but LXDs basically just a front-end for settting up a linux container that's super eash to use
the networking model is a lot easier to understand than docker or containerd btw, as you'll see how everything is managed by the host via brctl show