3

There is a CPU vulnerability Microarchitectural Fill Buffer Data Sampling. I use a Linux OS and I think to fix Microarchitectural Fill Buffer Data Sampling you need to update intel microcode or update kernel to a fixed one https://security-tracker.debian.org/tracker/CVE-2018-12130

I updated kernel to a kernel where Microarchitectural Fill Buffer Data Sampling is fixed. After that I run spectre-meltdown-checker and I get STATUS: VULNERABLE to all 4 types of MFBDS. Why ?

 CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface:  NO  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation:  YES  (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active:  NO 
* SMT is either mitigated or disabled:  YES 
> STATUS:  VULNERABLE  (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
Hadi Brais
  • 315
  • 1
  • 6
user209346
  • 31
  • 1
  • Are you running the new kernel or did you just install it? – multithr3at3d Jun 01 '19 at 15:00
  • 1
    @SteffenUllrich MDSUM is not a different problem, it is a special case of all the other MDS vulnerabilities. A processor that is vulnerable to MDSUM is also vulnerable to at least one of the other MDS vulnerabilities, and vice versa. In addition, `spectre-meltdown-checker` does not distinguish between different MDS vulnerabilities and emits the same output for all of them. This makes it conservative, i.e., it may tell you that a processor is vulnerable even though it isn't. – Hadi Brais Jun 03 '19 at 01:03
  • @HadiBrais: thanks for pointing out the relation between the bugs. – Steffen Ullrich Jun 03 '19 at 05:12

1 Answers1

4

Yes, you need both. The Linux-side changes make use of the microcode-side changes to mitigate these vunlerabilities, both are needed for it to work.

Note that you also need to disable hyperthreading if you are really serious about mitigating this.

I should add, Intel published details on how to "maybe-perhaps" mitigate it partially using some code sequences, and those work even without the Microcode changes. At least one of the BSDs deployed these, but Linux did not (and there are no plans to, either. Apparently, they don't mitigate things nearly enough to be worth the hassle).

anonymous
  • 41
  • 2
  • 1
    Can you link to some of the "maybe-perhaps mitigations"? – forest Jun 01 '19 at 23:19
  • @forest I think the answer is referring to the software sequences, which are an alternative to the new behavior of `VERW`. Each microarchitecture has its own sequence to clear its vulnerable buffers. You can see them in the FreeBSD source code [here](https://github.com/freebsd/freebsd/blob/0f461ea9259ee2768bdd705db8e3d546b113fd57/sys/amd64/amd64/support.S#L1635). These are used [here](https://github.com/freebsd/freebsd/blob/0444f8686dbe2bb10b0e53c7493beab30e4fb3f6/sys/x86/x86/cpu_machdep.c#L986) when the `MD_CLEAR` microcode update is not available or when `hw.mds_disable` is set to 2. – Hadi Brais Jun 03 '19 at 01:09
  • For example, the sequence for Ivy Bridge is called `mds_handler_ivb` in the FreeBSD source code. All of the sequences are defined by Intel in [this](https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling) article. – Hadi Brais Jun 03 '19 at 01:10