if you use this source (https://docs.kernel.org/admin-guide/hw-vuln/) to interpret your output you will eventually come to the conclusion—well I can only speak for myself----I came to the conclusion I was well-protected on this end. I interpret my own output as everything is being done that can be done, and I have an older Intel quad core.
It was about 20 minutes of learning for me, thought it was cool. this post is just FYI. edit/added word
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Vulnerable, no microcode
Spec store bypass: Vulnerable
Spectre v1: Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers
Spectre v2: Vulnerable, IBPB: disabled, STIBP: disabled, PBRSB-eIBRS: Not affected
Srbds: Not affected
Tsx async abort: Not affected
Yeah maybe you shouldn’t, but I didn’t hear any widespread exploitation of these vulnerabilities and I’ve been turning off these mitigations for years now, even on windows.
The salmon banner with 2 linked articles (I read them both) saying how dangerous mitigation=off is enough to dissuade me. Even Arch says my old Intel would gain only “up to” a 5% boost.
I don’t always trust the people/orgs who tell me what ‘untrustworthy’ and ‘sketchy’ is more than I do my own instincts at this point. Weird times!
I wonder if the older CPU doesn’t have the vulnerability (yet) - as most of the mitigations are for backdoors in ‘speculative execution’ workflows. Did a Core 2 even indulge in speculation? (if so - why were they so slow? )