Il ne faut pas confondre les Sandy Bridge avec les Sandy Bridge-E (gamme HEDT sur socket 2011, dérivée des Xeon), c'est un i7-3930K.
Sur https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/master/releasenote, on voit bien SNB, mais pas SNB-E/Ex (aucun dérivé serveur de Sandy Bridge n'a donc été mis à jour pour les dernières failles, contrairement aux gammes plus récentes).

Dans CPU-Z : bouton tools en bas, Save report as .TXT
Il y a une ligne "Microcode Revision" dans le fichier généré.

Le microcode, quand c'est le système exploitation qui le met à jour, il me semble que c'est non persistant : il faut faire l'opération a chaque reboot

En effet
De ma compréhension, il n'est pas possible de mettre à jour les CPU réellement
C'est à dire que le support de stockage physique n'est pas modifiable

Il y a donc deux methodes : soit le kernel applique un firmware, soit c'est le bios qui s'en charge

Linux permet de charger un microcode : l'initramfs est séparé en deux parties, la première contenant un seul fichier : le firmware, dans un chemin bien spécifique : early/kernel/x86/microcode/GenuineIntel.bin (lequel est hardcodé ici : https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/microcode/intel.c#L44)
On peut valider en extrayant un initramfs:
:~] unmkinitramfs /boot/initrd.img-4.19.0-5-amd64 .
:~] find early/ -type f
early/kernel/x86/microcode/GenuineIntel.bin

Ce qui est encore plus rigolo, c'est qu'on peut a priori charger des firmware n'importes quand, et pas seulement au chargement du kernel
Cependant, un firmware chargé tardivement ne pourra plus désactiver des fonctionnalités CPU sainement

:~] sudo iucode-tool -k GenuineIntel.bin -v
iucode-tool: processed 108 valid microcode(s), 108 signature(s), 108 unique signature(s)
iucode-tool: selected 108 microcode(s), 108 signature(s)
iucode-tool: Uploading selected microcodes to: /dev/cpu/microcode
iucode-tool: /dev/cpu/microcode: 108 microcode entries uploaded, 2411520 bytes

Je me demande pourquoi ce genre de fonctionnalité n'est pas disponible sous windows

Il suffit de prendre la version normale, pas celle avec le "skin" MSI...

Je te remercie, mais je préfère conserver cette version, quoiqu'il y en ait une générique plus récente (1.89). 

Bref, je ne trouve pas de solution pour mitiger MDS sous Windows 10 avec un PC récent (Core i3 de 6ème génération)[/size]

Selon le document Intel, il y a deux méthodes :
 - avoir le microcode, et appeler l'instruction VERW
 - exécuter une séquence de code qui écrit dans un buffer (variant selon la génération du CPU)
Je ne suis pas sûr de ce que fait le kernel de Windows, peut-être qu'ils ont aussi implèmenté la seconde méthode, dans ce cas la machine est protégée mais avec un coût plus important en performance.

https://support.microsoft.com/fr-fr/help/4093836/summary-of-intel-microcode-updates
La mise à jour avec le microcode 0xCC est disponible pour Windows 10 RTM, 1607, 1703 et 1709, mais pas les versions plus récentes !

Sur la page associée au CVE : https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv190013

Important Please note that at the release of this advisory, microcode updates provided by Microsoft for Intel processors are not available for the following versions of Windows. These microcode updates will be released at a later date. Microsoft recommends that customers running these versions of Windows install applicable Windows updates and obtain microcode updates for Intel-based devices from their OEM::

    Windows 10 Version 1803 for x64-based Systems
    Windows Server, version 1803 (Server Core Installation)
    Windows 10 Version 1809 for x64-based Systems
    Windows Server 2019
    Windows Server 2019 (Server Core installation)

Donc il faut attendre...

A noter que la 1903 a eu le patch kernel (cf la page du CVE), n'est pas dans la liste des versions qui n'ont pas la mise à jour de microcode, mais n'est la listée sur la page de la mise à jour des microcodes !

AMD serait aussi impacté : The specific instruction of interest (SWAPGS) is only available on the x86-64 architecture, as such only x86-64 platform vendors (Intel and AMD) are known to be affected.

En partie, cf les sources de Linux.

https://github.com/torvalds/linux/blob/f4eb1423e43376bec578c5696635b074c8bd2035/arch/x86/kernel/cpu/common.c#L1068

    * Technically, swapgs isn't serializing on AMD (despite it previously
    * being documented as such in the APM).  But according to AMD, %gs is
    * updated non-speculatively, and the issuing of %gs-relative memory
    * operands will be blocked until the %gs update completes, which is
    * good enough for our purposes.

https://github.com/torvalds/linux/blob/f4eb1423e43376bec578c5696635b074c8bd2035/arch/x86/kernel/cpu/bugs.c#L340
Du coup les CPU AMD, comme les Atom, ont X86_FEATURE_FENCE_SWAPGS_KERNEL, mais pas X86_FEATURE_FENCE_SWAPGS_USER.
Les CPU Intel ayant KTPI activé dans le kernel (la protection pour Meltdown) sont également déjà indirectement protégés pour le passage user=>kernel.