[SOLVED] Is my laptop vulnerable or not?

[egrep]

Hello,

I have a Lenovo laptop with a Intel Xeon E3-1200 v6/7th Gen Core Processor. It looks like I'm collecting vulnerabilities, lol. I used a guide to update my processors microcode as described here: https://wiki.gentoo.org/wiki/Intel_microcode. And after a reboot dmesg output says I have installed Intel microcode proper way:

Code: Select all

$ dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2020-04-23
[    0.575621] microcode: sig=0x906e9, pf=0x20, revision=0xd6
[    0.576199] microcode: Microcode Update Driver: v2.2.

But my system is still vulnerable (?) to the mds, meltdown, spectre flaws, and so on, although I used the guide to update my processors microcode:

Code: Select all

$ lscpu | grep -i vulnerab
Vulnerability Itlb multihit:     Processor vulnerable
Vulnerability L1tf:              Mitigation; PTE Inversion
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds:             Mitigation; Microcode
Vulnerability Tsx async abort:   Not affected

Code: Select all

$ dmesg | grep -iE '(spectre|mds|srbds)'
[    0.100599] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.100601] Spectre V2 : Mitigation: Full generic retpoline
[    0.100603] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[    0.100604] Spectre V2 : Enabling Restricted Speculation for firmware calls
[    0.100606] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[    0.100608] Spectre V2 : User space: Mitigation: STIBP via seccomp and prctl
[    0.100617] SRBDS: Mitigation: Microcode
[    0.100618] MDS: Mitigation: Clear CPU buffers
[    0.109359] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.

I am running 5.7.10-gentoo and have no idea what else can I do. I am missing something else?

To summarize, I am interested in the question of how vulnerable my processor is. And Is there any complete guide to protection from such vulnerabilities?

[fedeliallalinea]

You can install app-admin/spectre-meltdown-checker package that has better output.

[egrep]

You can install app-admin/spectre-meltdown-checker package that has better output.

Well, spectre-meltdown-checker says:

Code: Select all

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK

e.g. there is no CVE with non-OK. Is this means everything is OK?

[fedeliallalinea]

Yes but I'm not expert and I don't know if this utility checks all know issues.

[halcon]

Code: Select all

Vulnerability Itlb multihit:     Processor vulnerable

AFAIK, that vulnerability is actual only if you use a virtualization with KVM: iTLB multihit.

spectre-meltdown-checker's last info block is dedicated to it. For example:

Code: Select all

CVE-2018-12207 aka 'No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* This system is a host running a hypervisor:  NO 
* iTLB Multihit mitigation is supported by kernel:  YES  (found itlb_multihit in kernel image)
* iTLB Multihit mitigation enabled and active:  NO 
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

[egrep]

Thank you guys

[Hu]

It looks like I'm collecting vulnerabilities, lol.
But my system is still vulnerable (?) to the mds, meltdown, spectre flaws, and so on, although I used the guide to update my processors microcode:

Code: Select all

$ lscpu | grep -i vulnerab
Vulnerability Itlb multihit:     Processor vulnerable
Vulnerability L1tf:              Mitigation; PTE Inversion
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds:             Mitigation; Microcode
Vulnerability Tsx async abort:   Not affected

Not quite. As I read this:

• You are still fully impacted by itlb.
• For MDS, you are still affected if SMT is used.
• For all the others, software mitigations (which impair system performance) are present and attempt to mitigate the problem.

I am running 5.7.10-gentoo and have no idea what else can I do. I am missing something else?

What else do you want to do? Which of these vulnerabilities apply to how you use your system?

[Ant P.]

There are changes coming in Linux 5.8 (.9?) to make SMT less dangerous without having to disable it outright. That's probably a long way off though.

[NeddySeagoon]

egrep,

We are all vulnerable. :)

[egrep]

What else do you want to do? Which of these vulnerabilities apply to how you use your system?

Well, my daily usage of this workstation is to read news (rss), check mail (thunderbird), write simple code (emacs), do some local research and read books (evince). Probably I could count all the unique web-sites that I visit for a month and this number would not exceed 20. That's probably all. I'm just interested in doing the best that I can. However, I would not want to sacrifice performance because of the mythical hack possibility.

[egrep]

egrep,

We are all vulnerable.

Haha, This is certainly true! However, I am not prone to fanatical defense.

[Hu]

Based on that usage pattern, I think using a browser is probably your single greatest risk. Modern browsers are bloated monstrosities with uncounted lurking vulnerabilities due to the desire to have them do all sorts of things (WebGL, asynchronous page content, inline videos with sound, inline video-conferencing, etc.), usually without user preapproval, and sometimes without any way for the user to withhold consent other than refusing to visit the offending site. Keeping your number of sites down is helpful, but not sufficient, because those sites could suffer a breach and begin serving dangerous content. Realistically, unless you visit sites that would be a high priority target due to extreme popularity, the processor flaws probably will not matter.