# [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:

```

$ 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:

```

$ 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

```

```

$ 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?Last edited by egrep on Mon Jul 27, 2020 11:39 pm; edited 1 time in total

----------

## fedeliallalinea

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

----------

## egrep

 *fedeliallalinea wrote:*   

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

 

Well, spectre-meltdown-checker says:

```

> 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

 *egrep wrote:*   

> 
> 
> ```
> 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:

```
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

 *egrep wrote:*   

> 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:
> 
> ```
> ...

 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.

 *egrep wrote:*   

> 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

 *Hu wrote:*   

> 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

 *NeddySeagoon wrote:*   

> 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.

----------

