[ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Arman Khalatyan]

If you see that after the update of your OS dmesg shows RED alert in
the spectra check script in the second position then you should follow
the intel's read.me.
As in readme described on Centos 7.4:
rsync  -Pa intel-ucode /lib/firmware/
On the recent kernels(>2.6.xx) the dd method does not work, dont do that.
To confirm that microcode loaded:
dmesg | grep micro
look for the release dates.
But I beleve that v4 should be already in the microcode_ctl package of
the CentOS7.4 ( in my case 2650v2 was not inside, but the  v3 and v4
were there)
I have a script to enable or disable the protection so you can see the
performance impact on your case:
https://arm2armcos.blogspot.de/2018/01/lustrefs-big-performance-hit-on-lfs.html



On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <derek at ihtfp.com> wrote:
> Arman,
>
> Thanks for the info...  And sorry for taking so long to reply.  It's
> been a busy weekend.
>
> First, thank you for the links.  Useful information.
>
> However, could you define "recent"?  My system is from Q3 2016.  Is that
> considered recent enough to not need a bios updte?
>
> My /proc/cpuinfo reports:
> model name      : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
>
> I downloaded the microcode.tgz file, which is dated Jan 8.  I noticed
> that the microcode_ctl package in my repo is dated Jan 4, which implies
> it probably does NOT contain the Jan 8 tgz from Intel.  It LOOKS like I
> can just replace the intel-ucode files with those from the tgz, but I'm
> not sure what, if anything, I need to do with the microcode.dat file in
> the tgz?
>
> Thanks,
>
> -derek
>
> Arman Khalatyan <arm2arm at gmail.com> writes:
>
>> if you have recent supermicro you dont need to update the bios,
>>
>> Some tests:
>> Crack test:
>> https://github.com/IAIK/meltdown
>>
>> Check test:
>> https://github.com/speed47/spectre-meltdown-checker
>>
>> the intel microcodes  you can find here:
>> https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=41447
>> good luck.
>> Arman.
>>
>>
>>
>> On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins <derek at ihtfp.com> wrote:
>>> Hi,
>>>
>>> On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote:
>>>
>>>> No one likes downtime but I suspect this is one of those serious
>>>> vulnerabilities that you really really must be protected against.
>>>> That being said, before planning downtime, check your HW vendor for
>>>> firmware or Intel for microcode for the host first.
>>>> Without it, there's not a lot of protection anyway.
>>>> Note that there are 4 steps you need to take to be fully protected: CPU,
>>>> hypervisor, guests and guest CPU type - plan ahead!
>>>> Y.
>>>
>>> Is there a HOW-To written up somewhere on this?  ;)
>>>
>>> I built the hardware from scratch myself, so I can't go off to Dell or
>>> someone for this.  So which do I need, motherboard firmware or Intel
>>> microcode?  I suppose I need to go to the motherboard manufacturer
>>> (Supermicro) to look for updated firmware?  Do I also need to look at
>>> Intel?  Is this either-or or a "both" situation?  Of course I have no idea
>>> how to reflash new firmware onto this motherboard -- I don't have DOS.
>>>
>>> As you can see, planning I can do.  Execution is more challenging ;)
>>>
>>> Thanks!
>>>
>>>>> > Y.
>>>
>>> -derek
>>>
>>> --
>>>        Derek Atkins                 617-623-3745
>>>        derek at ihtfp.com             www.ihtfp.com
>>>        Computer and Internet Security Consultant
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
> --
>        Derek Atkins                 617-623-3745
>        derek at ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant