Okay thanks. That makes sense. I've been trying to read up on this topic too. It's a strange way to describe a kernel status, it's so dramatic LOL. "TAINTED" wooooo (scary music). LOL
But anyhow, I think I was able to reduce some (but not all of the messages) by reducing the number of kernel parameters I was using, and by removing some of the proprietary drivers (I already had free drivers installed).
As it turns out, some of the messages are just about devices that I blacklisted (and I don't mind that) in the kernel parameters.
But the very first "blue" messages I can't read except for the "GPE type mismatch" or something like that. The internet says not to worry about that though, I guess.
There's some other stuff printed there about PNP but I can't read it, and it doesn't show up in the /var/log/boot.log, most everything looks OK. There are a few odd errors here and there, but since my system seems okay, I'm guessing I should ignore them.
My only question is, why am I all of sudden getting blue items during boot when I never had that before?
Is it from system upgrade? Is it from the newer Linux kernel? Does it mean I got hacked?
The blue text on boot up is largely informational messages or lower-priority kernel messages. Some kernels have it and some don't since it depends on how the kernel and bootloader were configured. The white text is largely about initializing hardware, loading drivers, and setting up system facilities that are needed. A blue screen on the other hand, can be a kernel panic, but that's quite obvious since the machine stops functioning.
If a system boots up normally and functions as expected, then there's usually no problem.
The likelihood of a home user's linux computer being hacked after it has been installed with a default installation of a linux distro that hasn't been altered, ranges from small to negligible to extremely remote. Hackers generally like larger targets from which there can be a return to them of some sort. One can always check uncertainties by engaging with more experienced users, forums, distro documentation, kernel docs etc. Questioning helps.
Some hacking of linux is possible of course. There are rootkit attacks, hardware and software vulnerabilities that can be taken advantage of. Mostly these vulnerabilites are identified early in the FOSS biosphere and are either resolved, or plugged or neutralised in some way. Some have existed for many years but remained so obscure that there is no evidence they were taken advantage of, e.g.:
https://www.securin.io/articles/a-1...xposes-linux-to-privilege-escalation-attacks/, and here:
https://www.bleepingcomputer.com/ne...-decade-old-needrestart-flaw-that-gives-root/
It's quite common for such vulnerabilities to be discovered by security specialists and investigators or firms in the linux world who then construct proof of concept code to show how the exploit can succeed in attacking a system without there existing any evidence of use of that exploit in the wider community. Then the developers usually code away the holes and life goes on.
It's the case that some users are uncertain in their usage of a linux installation's functioning and see things that are unfamiliar, odd looking or seemingly coming out of nowhere and so are unable to attribute the occurrences to any process which consequently raises their suspicions. Experience gathering knowledge over time helps with discriminating between the troubling and benign.
In relation to some major vulnerabilities in linux, one can check whether or not the kernel they are using has had mitigations applied to it against some of the relatively recent identified threats. One can check the "Vulnerablities:" section of the output of the lscpu command thus:
Code:
$ lscpu
<snip>
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Mitigation; Clear Register File
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled vi
a prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user
pointer sanitization
Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB cond
itional; RSB filling; PBRSB-eIBRS SW sequence; B
HI BHI_DIS_S
Srbds: Not affected
Tsx async abort: Not affected
This kernel is well covered for the identified vulnerabilities. The actual exploits can be found in docs online for the interested reader.
