Yep, that’s a fair question. The answer is I’m not really sure, but it sounded like something that should be switched on. I’m not that familiar with the more involved aspects and features of the BIOS these days.
My drive is encrypted and I’m hoping to get to the point that I can use the fingerprint reader to unlock it on boot, instead of having to type in the pass phrase every time, and I’ve got the vague notion in my head that secure boot needs to be enabled for the TPM stuff (something else I’m not familiar with) to work, which I will probably need.
That’s the problem, nowadays the word “security” is way overused, so you really need to do you own research instead of blindly believing what you have been told.
My understanding is that secure boot protects a device against running malicious code during boot, before other protective measures can be taken. Whether or not this matters will depend on your threat model.
Ideally? Yes. Realistically? Probably not worth the effort.
This is accurate. The point of Secure Boot is that all of the boot items (like initramfs and grub configurations, etc) have to be signed by a key that is trusted within the UEFI configuration. If any of the boot item signatures don’t pass validation, then the boot will fail out.
Not only would you need to configure the UEFI system to enable Secure Boot, you also have to create a key-pair, mark it trusted, sign all of those files, and ensure that the BIOS/UEFI system is protected with a strong password. Not doing all of these things reduces the benefit of this protection. Its not a protection if one can just go disable it because you didn’t secure your BIOS login…
While I don’t think most people are going to be hit by something that Secure Boot would prevent, it really is up to you and what your particular threat landscape is. If you’re just a person with a laptop, it’s likely not worth the effort… If your a CEO working at a company worth millions/billions, then yes, it’s absolutely worth the extra layer of defense; having your system popped at that level is WAY more impactful than having an IT guy enable these features for you.
Everything in security is about layers, risk and threat models. It’s up to you to determine what you’re willing to do, and what level of risk you’re willing to accept.
I think full-disk encryption is more important than secure boot (in this example). It can’t be bypassed in BIOS and it’s more likely you’ll forget your laptop somewhere where FDE can help to prevent data-loss.
If you do want to enable Secure Boot, the Arch Wiki has a good primer on the topic (I know it was linked already), but you may need to more googling to get all of the way through the process. It’s not easy, and you’ll have to maintain the process as new kernel updates are released as you have to keep signing all of the boot files. I think there’s a suggestion for a pacman hook that can help in this.
When I run Firefox, it usually works fine using an integrated GPU. Both 3D render and video decoding are working fine, but if I try to run it with “DRI_PRIME=1”, I get the next error:
$ DRI_PRIME=1 firefox
[GFX1-]: glxtest: ManageChildProcess failed
[GFX1-]: No GPUs detected via PCI
And it starts to use the CPU to decode video
Does anyone know what the issue maybe?
P.S. Steam games and Minecraft uses dGPU with “DRI_PRIME=1” no problem
Interesting though. The dGPU will still go to sleep when not actively using firefox. Then when switching back to firefox, there is a 2 second delay where firefox is unresponsive while it waits for the dGPU to wake up again. Not ideal.
Minecraft does not use it for me with only DRI_PRIME=1, not sure how you are getting that to work. But the above works for Minecraft for me, not that it needs the dGPU.
There was a major bug in the recent egl-wayland package on Arch. But Arch should have rolled it back few days ago, so if you haven’t updated try to update and see if you see a “new” package for egl-wayland.
My dGPU crashes when I try to plug the power adapter in while it’s in D3cold. This is really strange… Also it doesn’t want to go into D3cold while the adapter is plugged in. I made a post about this Here, but it appears that I have forgotten that Arch isn’t an official distro, heh… There’s also my post on the Arch BBS and I do not know what to do anymore.
The “bad” commit is somewhere between 6.8.9 and 6.9. Will test further and update. However, even on 6.8.9, the GPU refuses to go into D3cold on external power.
I’m not sure how helpful this is, but I’m on Arch with Kernel 6.9.10 with a dGPU and mine doesn’t experience any issues relating to switching states. I’ve never experienced a panic either.
I’m currently on external power (included USB-C adapter) with my dGPU in the D3cold state. I did have an issue previously, but it was found to be software trying to access sensor data that was the cause; removing that fixed it.
Have you tried running it on a live-environment external to your current install?
Where are you plugging in the USB-C adapter? I’m powering my laptop via a USB-C Expansion Card (middle on the left or right in my case)
It could also be a hardware thing; I know it sounds lame, but testing Windows might not be a half bad idea, or at least a supported Ubuntu variant, just to see what happens.
This makes the GPU not crash on plug-ins, although the GPU still stays in D0 while the power adapter is in and I cannot for the life of me see anything that’s using it.
