GNOME To Warn Users If Secure Boot Disabled, Preparing Other Firmware Security Help

[abu_shawarib]

Secure boot in Linux is a security theater anyways because only the kernel image and its modules are signed. Everything else is not, not a single binary or library on the disk.

It's called secure boot, not secure everything. LOL

[sinepgib]

From what I understand about Coreboot, you have to have SeaBIOS or their TianoCore version of UEFI to boot Windows. Those are payloads. You can't just map to the Windows kernel like you can with Linux on Coreboot (or LinuxBoot as it was previously known). You would need TianoCore for newer versions of Windows that mandate UEFI requirements though.

That's precisely what makes my claim true. You typically use any of the common interfaces as payloads for Coreboot. You have also some other options. Some people load GRUB directly, some FILO (a LILO like bootloader made for Coreboot), some even use Linux as payload. But Coreboot on its own doesn't load anything from disk, it provides hardware initialization, the ability to load some payloads and a library for those payloads to interact with hardware, nothing more.

I stand by my point though: if the biggest independent Linux vendor out there (Fedora via Red Hat) issues warnings that force NVIDIA to advance their open-source driver development, good for them. NVIDIA needs a good swift kick in the pants. I wouldn't doubt if this move had something to do with Torvalds contention with NVIDIA. Torvalds' Linux distro of choice is Fedora. I would bet a good chunk of this paycheck comes from Red Hat.

I may partially agree with that. My response wasn't about what's best for Linux strictly, but about whether you can have verified boot on Linux while using proprietary drivers. As long as the distribution (or you, if using custom keys) trust it and sign it, it will work.

[sinepgib]

It's called secure boot, not secure everything. LOL

And even then you can absolutely keep that chain of trust intact by making the verified kernel and initramfs verify signatures for (at least) the base userspace. Because your early boot was verified you know it'll check your late boot, and so on. It's if we break any part of that chain that it becomes (at least partly) futile.
In Linux, at the time, it's theater tho: if you allow GRUB to load unsigned kernels then there's no point, all your OS is basically compromised anyway. If you allow Linux to kexec into unsigned kernels, malicious userspace can trigger that kexec to load a compromised kernel, etc.

[sinepgib]

He's a stuck up ass. I don't know why he bothered to release a product as open source if he shits all over everybody's idea on how it could be modified to fit a particular purpose.

Well, having it be open source means, in part, he doesn't need to like your idea, you can fork and implement it as your own SecureBootBSD or whatever. I'm not a fan of fork proliferation, but it is enough reason to make stuff open source, you don't need to give up control on mainline.

[asriel]

I never thought I would see the day where Linux developers would sheer for Microsoft control over our hardware...

Gnome is not linux. Gnome is more windows intreface that windows itself - still pushing for windows 8 idea that computers should become big smartphones taht run one app fullscreen and controlled by finger. So I will not be surprised if Gnome developers will implement feature to shutdown your PC if you disbale the secure boot

[Waethorn]

That's precisely what makes my claim true. You typically use any of the common interfaces as payloads for Coreboot. You have also some other options. Some people load GRUB directly, some FILO (a LILO like bootloader made for Coreboot), some even use Linux as payload. But Coreboot on its own doesn't load anything from disk, it provides hardware initialization, the ability to load some payloads and a library for those payloads to interact with hardware, nothing more.



I may partially agree with that. My response wasn't about what's best for Linux strictly, but about whether you can have verified boot on Linux while using proprietary drivers. As long as the distribution (or you, if using custom keys) trust it and sign it, it will work.

TianoCore supports Secure Boot. Coreboot on it's own does not. If you use Coreboot and use the Linux kernel or a Linux bootloader as a payload instead of a conventional firmware interface, you don't get Secure Boot. Secure Boot is something that is only for UEFI. SeaBIOS also doesn't support it since it isn't a UEFI interface. You could probably build some kind of custom certificate chain system for Coreboot yourself, but it wouldn't be Secure Boot.

[ssokolow]

• Authentication using fingerprint or FIDO/U2F authentication hardware token.
• Application-based firewall where applications cannot connect out unless allowed.

I'm on KDE, but I can agree with these... though I do prefer my current setup where even SSH requires authentication via pam_u2f.so so that all privilege escalation and network access has a physical access requirement as long as I properly sandbox any non-SSH daemons.

It means that I can SSH in from another machine in the same room and I can configure SSH to skip auth for certain special cases (eg. the WinSCP→SFTP backups to a self-chrooting username, locked to IPs on the retrocomputing subnet I isolated behind a separate port on a pfSense router configured to only allow connections outward and only for SSH and NTP to the one machine) but, otherwise, that's another layer of defense in depth.

[Waethorn]

That's precisely what makes my claim true. You typically use any of the common interfaces as payloads for Coreboot. You have also some other options. Some people load GRUB directly, some FILO (a LILO like bootloader made for Coreboot), some even use Linux as payload. But Coreboot on its own doesn't load anything from disk, it provides hardware initialization, the ability to load some payloads and a library for those payloads to interact with hardware, nothing more.



I may partially agree with that. My response wasn't about what's best for Linux strictly, but about whether you can have verified boot on Linux while using proprietary drivers. As long as the distribution (or you, if using custom keys) trust it and sign it, it will work.

If you had Verified Boot on a Linux kernel with closed-source drivers, you'd have Chrome OS.

[Waethorn]

Well, having it be open source means, in part, he doesn't need to like your idea, you can fork and implement it as your own SecureBootBSD or whatever. I'm not a fan of fork proliferation, but it is enough reason to make stuff open source, you don't need to give up control on mainline.

Let me put it this way: Linux Torvalds is a nice guy in comparison. Theo has a permanent pickle up his ass about asking him any questions or getting documentation corrected. He makes himself unavailable whenever a question arises about some change, or anything to do with the direction. He has a toxic personality, which is why most hardware companies using a BSD don't use OpenBSD.

FYI: His personality is the reason why he was cast out from the NetBSD project. It was rumoured he had an affair with one of the other leads.

[sinepgib]

TianoCore supports Secure Boot. Coreboot on it's own does not. If you use Coreboot and use the Linux kernel or a Linux bootloader as a payload instead of a conventional firmware interface, you don't get Secure Boot. Secure Boot is something that is only for UEFI. SeaBIOS also doesn't support it since it isn't a UEFI interface. You could probably build some kind of custom certificate chain system for Coreboot yourself, but it wouldn't be Secure Boot.

Of course, I thought that much was clear. Coreboot doesn't concern itself with verification or anything other than hardware init and passing control to a payload. The reason I mentioned the other payloads was simply to clarify that Coreboot doesn't care what happens after. You may load whatever you want, as long as your payload is able to. In particular, using Coreboot (with or without TianoCore and with or without enabling SecureBoot on it) does not stop you from using proprietary stuff if you want to, which was the original question.