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.

Generally, it depends on the issue. The first thing I'd check is journalctl, and if there are any errors, I usually look up "[pasted error] [distro name]" and go from there. if I'm unable to find errors, then my next bet is to look up "[description of issue] [distro name]". Unless I am directly familiar with the component that is having an issue, I try to see if I can find a solution online first. Of course, I never recommend running commands you read online that you don't understand, so take it as a learning experience and pull up some man pages to see what everything is doing. By doing that, you can even begin to learn how to debug and fix these issues by yourself. Even just finding issues other people have and proving it isn't your issue helps narrow it down.

What I will never under any circumstances recommend is using an LLM. Please, just use a normal search engine (I prefer DDG), and find forum posts from real people. Those people are generally capable of understanding what they're saying, so they won't give completely made up information based on generation of the most likely next word from the data an LLM model was trained on. Besides, chances are that the LLMs are trained on the data you would find by searching anyway, so why not go straight to the source?

I do find myself having to troubleshoot issues entirely on my own sometimes, but usually those are of my own doing, and I can likely figure out what I did wrong (I host my own server and tinker with it quite often). Of course, since switching to atomic distros on my desktop, I haven't had any system issues to troubleshoot with it in years. Running Manjaro is practically a guarantee that you'll have system issues, though. I've never had a worse experience with my system than when I ran it, and I'm not alone in that.

Otherwise, if you find yourself unable to find an easy solution, backups are a wonderful thing. My server recently had part of its boot corrupted, and it was just a case of recovering from a backup to restore it. Remember, with backups: 2 is 1 and 1 is none. Data can (and will) get corrupted eventually.

journalctl and log files are very valuable. If it's specific to an application running said application in a terminal with verbose also gives can potentially provide you with a clear indication of what's going wrong.

I'm dyslexic so I get syntax errors all the damn time and thankfully using NixOS it likes to remind me on rebuild how much of an idiot I am.

Worse comes to worse you can always plug the error into an LLM like Claude or Chatgpt. But take that with a grain of salt. It'll give you a good base to start from for debugging but never trust something like Claude that will constantly tell you "it's a known issue" when it isn't.

All this being said I've had the best experience for help via whatever application/distro/whatever IRC channels on Libera chat.

Three Wi-Fi routers are placed in a room.

I'd be interested to know how well this works if there aren't 3 (!) hotspots in 1 (!) room. If that is a hard requirement for it to work accurately, I don't see many applications for this technology. At least not in its current version.