Huh? How does an image based model reduce the need for secure boot?
Huh? How does an image based model reduce the need for secure boot?
ASecure boot makes the kernel unwilling to load an unsigned (or signed with untrusted certificates) kernel module.
Those modules can end up on your disk in two ways:
Those modules can end up on your disk in two ways:
- Via a root-privilege installer. This won't work on immutable distros, unless they use rpm-ostree to literally layer the kmod package, which will be easily noticeable.
- Via someone tampering on the physical disk, mounting it in another computer, and placing files on it. This can be prevented by encrypting the disk (Fedora's installer has a simple checkbox). I am also pretty sure that ostree would not allow this kind of direct tampering with files anyway.
PYes, I suppose it means malware has to more specifically be designed to work with rpm-ostree etc - but that seems more like a speed bump than anything to me. I'm not sure I would say that makes secure boot less necessary.
AI have yet to come across or hear about any malware that ever installed Linux kernel modules btw. 
ALet alone targeting rpm-ostree distros specifically, an even smaller audience.
ASo far everything I ever see is user-level malware that exfiltrates user-owned files via scripting or basic stuff like that.
Rwell there are UEFI targeted malwares floating around
PI have seen Lennart Poettering's blog posts about secure boot and UKIs and everything, definitely pretty interesting stuff, will be interested to see how silverblue evolves in that direction.
ROK my solution to this was changing the order of the EFI files in my laptop BIOS, so the MMX file was listed first. This allowed the Mokutil screen to load to enroll the akmod key. I then had to change the order back to get the OS to load normally. This is an issue with my old bios
Rusing the mmx64.efi file from the /efi/fedora directory
RI just realised this laptop was manufactured in 2015.... so the EFI setup is ancient compared to modern machines
ANice job. Glad your motherboard accepted the key that way. Mine didn't when I switched to that file. I did practically the same thing, but the MokUtil enrollment GUI was basically pretending to enroll the key but didn't write anything to BIOS memory. I just assumed that there was an untrusted code path/write lock involved, and stopped trying. This definitely varies between different BIOSes though.
So your machine is secureboot enrolled now?
So your machine is secureboot enrolled now?
ABtw there's a new exploit out that may make your BIOS unable to use secure boot again, if it only trusts the old Microsoft key. I remember hearing that Microsoft will change the signing key used for both Windows and the Linux SB shim because of some huge exploit.
Edit:
https://arstechnica.com/information-technology/2023/05/microsoft-patches-secure-boot-flaw-but-wont-enable-fix-by-default-until-early-2024/
Edit:
https://arstechnica.com/information-technology/2023/05/microsoft-patches-secure-boot-flaw-but-wont-enable-fix-by-default-until-early-2024/
AOkay a comment on the article clarified it better: Microsoft will revoke their old SecureBoot master key to prevent booting from old, vulnerable bootloaders signed with the old key.
AThe bug was in their Windows bootloader itself, but to protect people they need to block the old key itself with a BIOS update to revoke the key's trust. Linux will be getting the same patch because the SB shim will be signed with the new key instead. I remember seeing that MS is already in contact with the Fedora team about this.
ALet's hope they use some kind of derived key system so that your current Microsoft root certificate in the BIOS can still authenticate their upcoming, new key
RYeah the secure boot is enabled and nvidia modules are loaded. I can see in rpm-ostree that it's on the ublue silverblue nvidia image
AThat's really nice news. Sounds like you remembered to run the command to set the kernel boot args too?
ROne question though, my silverblue-nvidia install hasn't prompted me to run any tools like Yafti and the Firefox isn't via Flatpak. Is that something not included in the ISO?
AYeah yafti is a tool for your own downstream images created from the template in the repo. It isn't even installed in the main or nvidia images.
Main and Nvidia images are very close to upstream silverblue, with some conveniences like RPM fusion, codecs etc installed.
Main and Nvidia images are very close to upstream silverblue, with some conveniences like RPM fusion, codecs etc installed.
RI haven't run any specific commands for kernel arguements, no
AOh okay you need to do that, ostree has a special security model where kernel boot args can only be set by you, the admin. It's listed here: https://ublue.it/images/nvidia/
R
RI will have a look
Rthat install ISO is three weeks old, so maybe missing some changes?
AThat iso pulls the latest image from the internet during install, so the ISO is meant to only be updated rarely. And no the iso doesn't seem to set kargs, I cannot find the word anywhere in the source code of those repos.
And no the iso doesn't seem to set kargs, I cannot find the word anywhere in the source code of those repos.RWell the kernel args have been set in /etc/default/grub and I didn't add them
Rthe rpmfusion modules do usually update those
AAI don't even think that /etc/default/grub's kernel args are used at all on silverblue
Edit: They're not used.
Edit: They're not used.
Rand of course the Acer bios updater for this old laptop requires Windows because it's a .exe file 
AHmm try opening it with 7zip and seeing if you can get the files from inside. It's usually some DOS exe and a firmware blob inside "windows BIOS updaters".
ROK well something is doing something because the /boot/grub2/grub.cfg linked to /boot/loader/grub.cfg has the same kernel options added
ARun and look for those flags to be sure
Rthere are some other exe files inside the installer, but how would I use those in Linux?
AWith a FreeDOS USB boot stick, boot into the DOS environment and run the exe.
Rthis contains the same args as the /etc/default/grub and /boot/grub2/grub.cfg file
AThat must mean that when the modules are bundled instead of layered, they become part of the actual boot args, unlike when they are manually layered with , where you need to run manually.
ANo... that theory makes no sense. Because if you install regular Silverblue and rebase to the image, you likewise have the nvidia modules bundled instead of layered, and you don't get the same luxury there and need to manually run the command...
AIt seems like the Nvidia ISO is an exception to this rule.
RAhh FreeDOS I don't think I've ever used it. Might give it a go later
AIt's pretty painless, unless the you found requires some undocumented arguments.
R@Arcitec before I ran the uBlue ISO install the laptop had vanilla Silverblue. I haven't set any manual commands, I just ran the installer. Apart from fixing my ancient bios errors, it's all automated
AYea it just surprises me greatly because the ublue repos and ublue isogenerator don't contain the words or anywhere.
Rdid you try a search for modeset?
ABingo:
AIt's part of the Fedora kickstart installer script used by the NVIDIA ISO!
ASo this is the one and only scenario where the command doesn't have to be executed manually. 
RGitHub
Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/nvidia development by creating an account on GitHub.
Rset-kargs:
rpm-ostree kargs \
--append=rd.driver.blacklist=nouveau \
--append=modprobe.blacklist=nouveau \
--append=nvidia-drm.modeset=1
AYeah that's a different file, that's for the command which runs the command I mentioned, it's a manual thing you do after install.