Is microcode_ctl needed on a virtual guest?

Latest response

Does anybody know exactly if the microcode_ctl package (and so all the microcode files) are needed on a virtual guest (vmware or ovirt/rhev)? Is it safe to remove it as long an host is running on a hypervisor?
I've found different unofficial answers to my question but I didn't find an official one in the RedHat documentation. What I've found are a bug report and other sources around the web but still isn't so clear to me.

"microcode update should be skipped in virtualized environment"
https://bugzilla.redhat.com/show_bug.cgi?id=1000317

and the relative errata from the 6.5 release notes:

"[...] Previously, the microcode_ctl utility did not detect if it was running in a virtual machine and attempted to install the CPU microcode updates. This behavior caused several errors to be returned in the kernel ring buffer. The underlying source code has been modified and microcode_ctl no longer tries to update the CPU microcode in the described scenario. [...]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_technical_notes/microcode_ctl

This is the most clear one but still it's from 2013. Is still vaild as today?

Various other sources:

"[...]During the boot phase of your virtual machine you may see an error message [...] As the virtual machine is running on virtual CPUs there is no point updating the microcode. Disabling the microcode update for your virtual machines will stop this error [...]"
https://www.centos.org/docs/5/html/5.2/Virtualization/sect-Virtualization-Troubleshooting-Microcode_error_during_guest_boot.html

"[...] the guest OS tried to update the microcode from patch level XX (YYh) to patch level ZZ (TTh), but VMware ESX does not allow microcode patches to be applied from within a virtual machine. Microcode patches are used to correct CPU errata."
https://kb.vmware.com/s/article/1028290

Responses

Just to add more confusion, it seems that the patch included in the errata RHBA-2013-1668 (https://bugzilla.redhat.com/attachment.cgi?id=789554) that was checking if the binary was running on a real or physical cpu has been totally removed from the upstream source: https://pagure.io/microcode_ctl/blob/master/f/microcode_ctl.c So the microcode_ctl binary doesn't check anymore if the the host where is running it's a guest (virtual cpu) or an hypervisor (physical cpu).

Did you get this answered?

No, no answer at all :(

Do you have the possibility to open a support request to get an answer for this question? I think an answer from support should be as official as it could get.

Is there some more information available regarding this question?

I don't think this helps me ... MESSAGE (ASSOCIATE) XXX, YYY on Jun 03 2019 at 02:51 PM -04:00 Hello,

Welcome to Red Hat Technical Support.

My name is XXX & I will be assisting you with this case.

I would start here, by answering what would the microcode_ctl actually do.

service name: microcode_ctl

The microcode_ctl packages provide utility code and microcode data to assist the kernel in updating the CPU microcode at system boot time. This microcode supports all current x86-based, Intel 64-based, and AMD64-based CPU models. It takes advantage of the mechanism built-in to Linux that allows microcode to be updated after system boot. When loaded, the updated microcode corrects the behavior of various processors, as described in processor specification updates issued by Intel and AMD for those processors.

From the Red Hat documentation: It states that the microcode_ctl package is necessary for the virtual guest.

MICROCODE_CTL https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_technical_notes/microcode_ctl

snipped from above link ((The microcode_ctl packages provide utility code and microcode data to assist the kernel in updating the CPU microcode at system boot time. This microcode supports all current x86-based, Intel 64-based, and AMD64-based CPU models. It takes advantage of the mechanism built-in to Linux that allows microcode to be updated after system boot. When loaded, the updated microcode corrects the behavior of various processors, as described in processor specification updates issued by Intel and AMD for those processors.))

microcode_ctl-2.1-47.2.el7_6.x86_64.rpm https://access.redhat.com/downloads/content/microcode_ctl/2.1-47.2.el7_6/x86_64/fd431d51/package

snipped from above link ((The microcode update is volatile and needs to be uploaded on each system boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts back to the old microcode.))

I have also checked this with our virtualization domain experts, and they also have the same opinion that this package is needed in virtual guest.

Let me know if you have any more queries on the same.

Regards, XXX YYY Technical Support Engineer Red Hat

Knowledgebase: https://access.redhat.com/knowledgebase Contact us: https://access.redhat.com/support/contact/

The below kcs article will provide you more information pertaining to RHV guests.

Applying MDS CVE's patches on RHV hosts and manager node

https://access.redhat.com/solutions/4147681

Below my final interaction with support on this specific scenario, ((MDS - Microarchitectural Data Sampling - CVE-2018-12130, CVE-2018-12126, CVE-2018-12127, and CVE-2019-11091)) but I figure it applies in the general case as well. Hope it helps somebody.

Me:: I think I understand, but please can I clarify. When you say

"simply on the hosts:" - you mean the host doing the virtualization.

So you are saying one has to "patch/update" the Virtualization ( in my case vCenter ) and if you got that done you don't have to do anything on the guest.

as in .. "The update isn't needed within the guests,"

Thanks!

Redhat:: Yes, that's all correct - the only patches that need to be installed and changes that need to be made are on the host to make sure that the guest's RAM remains inaccessible to other guests and from the host level, in your case vCenter.

Thanks Gonda for sharing this. It would be great if RedHat could publish an official KB with these informations.