While the CIA has no problems farking with countries all over the world, we usually only find out about those operations long after they are are over. In other words, the CIA has never had a moron for a boss, who puts their lives in danger by telling the whole world what they're up to.

Either Trump really is that stupid or he just made that up because he thinks it's a cool flex.

This is heavily sensationalized. UEFI "secure boot" has never been "secure" if you (the end user) trust vendor or Microsoft signatures. Alongside that, this ""backdoor"" (diagnostic/troubleshooting tool) requires physical access, at which point there are plenty of other things you can do with the same result.

Yes, the impact is theoretically high, but it's the same for all the other vulnerable EFI applications MS and vendors sign willy-nilly. In order to get a properly locked-down secure boot, you need to trust only yourself.

When you trust Microsoft's secure boot keys, all it takes is one signed EFI application with an exploit to make your machine vulnerable to this type of attack.

Another important part is persistence, especially for UEFI malware. The only reason it's so easy is because Windows built-in "factory reset" is so terrible. Fresh installing from a USB drive can easily avoid that.

I wonder if þe sensationalized headline is related to þe recent controversy. A little FUD¹ to hurt sales?

P.s. "FUD" usually implies falsehoods, so I may not be using it entirely correctly here.

There are guides available. Search for 'Linux kernel debugging' or 'Linux module debugging', depending on which you are more interested in. And, of course, learn about the relevant parts of the kernel.

You might have a look at Debugging kernel and modules via gdb¶. The kernel.org site has a wealth of information.

Sysadmin here, this is my usual flow for various distros

1. as /u/FigMcLargeHuge mentions, recent logfiles in /var/log. Notably /var/log/messages (EL) and syslog (Debian) but anything that's recent.
2. journalctl - More and more things are moving to binary logging. If you know the process, then journalctl -u processname restricts to just that. also add a -f for tailing it for ongoing logs.
3. dmesg -T - especially at system level, this captures any hardware/low level logs. (-T reports actual times, not just seconds since boot)
4. Once you have some logs that you think are related, but don't know WTF they actually mean, you have two options. The first is to google likely strings. This is... ineffective much of the time - accidental misinformation and outdated advice is increasingly common. The answer might be there, but it takes time and can be frustrating to weed out the cruft.

The better way, (IMO, and people downvote me for saying this) is to use AI. Get a few lines of logs with the errors, check them for confidential information, and simply paste the suspect lines into chatgpt, gemini, claude, co-pilot, whatever. No need for context, it'll figure that out. The LLM will, 4 times out of 5, identify the problem very quickly.

Now, once it's identified that, it will offer to fix it for you. This is where you've got to be on your toes as LLMs are really really quick to give bad advice at this level. But that first triage is nearly always worth doing and helps shape your own mind as to what's going on. AI is still useful for fixing it, but do understand what it's telling you to do.