Hi,
I upgraded to EL7.4 / oVirt 4.1.8 last night.
I must say it was easier than expected, so kudos to all the devs.
I did have a few hiccups along the way, mostly of my own making.
The one main hiccup is that the ovirt-40-dependencies package links to a
CentOS repo that no longer exists, and that caused lots of pain. I had to
manually disable two repos to get the upgrade to work.
Note: Nowhere in the docs does it say to remove the ovirt-release40
package, either before OR after the upgrade!
Having said that, my ovirt host now reports:
# bash spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.31
Checking for vulnerabilities against running kernel Linux
3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
STATUS: NOT VULNERABLE (106 opcodes found, which is >= 70,
heuristic
to be improved when official patches become available)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: YES
* The SPEC_CTRL CPUID feature bit is set: YES
* Kernel support for IBRS: YES
* IBRS enabled for Kernel space: YES
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
STATUS: NOT VULNERABLE (IBRS mitigates the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Checking if we're running under Xen PV (64 bits): NO
STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
Do I need to enabke IBRS for User space?
If so, how would that be done?
Thanks!
-derek
On Mon, January 15, 2018 1:10 pm, Yaniv Kaul wrote:
On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins <derek(a)ihtfp.com>
wrote:
> Thanks.
>
> I guess it still boils down to updating to 7.4. :(
>
> In the short term, will Ovirt 4.0 continue to run in 7.4? Or MUST I
>
We don't know, but I would assume NO. Every minor release of EL required
some small adjustments to expected and unexpected changes in the platform.
We have worked with 4.1 to support 7.3 and then 7.4, I would not presume
4.0 works with it.
Y.
> upgrade both the OS and ovirt simultaneously? My time is very short
> over
> the next few weeks (I'm moving) so I'd like to get as much bang for the
> buck with as little down time as possible. I can't spend 12 hours of my
> time working to repair a botched upgrade from 4.0 to 4.1 or 4.2.
>
> Thanks again!
>
> -derek
>
> On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote:
> > 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(a)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(a)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(a)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(a)ihtfp.com
www.ihtfp.com
> >>>> Computer and Internet Security Consultant
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users(a)ovirt.org
> >>>>
http://lists.ovirt.org/mailman/listinfo/users
> >>>
> >>>
> >>
> >> --
> >> Derek Atkins 617-623-3745
> >> derek(a)ihtfp.com
www.ihtfp.com
> >> Computer and Internet Security Consultant
> >
>
>
> --
> Derek Atkins 617-623-3745
> derek(a)ihtfp.com
www.ihtfp.com
> Computer and Internet Security Consultant
>
>
--
Derek Atkins 617-623-3745
derek(a)ihtfp.com
www.ihtfp.com
Computer and Internet Security Consultant