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)
|improve this question|||||
  • Are you running the new kernel or did you just install it? – multithr3at3d Jun 1 '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 3 '19 at 1:03
  • @HadiBrais: thanks for pointing out the relation between the bugs. – Steffen Ullrich Jun 3 '19 at 5:12
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).

|improve this answer|||||
  • 1
    Can you link to some of the "maybe-perhaps mitigations"? – forest Jun 1 '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. These are used here when the MD_CLEAR microcode update is not available or when hw.mds_disable is set to 2. – Hadi Brais Jun 3 '19 at 1: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 article. – Hadi Brais Jun 3 '19 at 1:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.