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 <de...@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 <de...@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 <arm2...@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 <de...@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
>> >>>>        de...@ihtfp.com             www.ihtfp.com
>> >>>>        Computer and Internet Security Consultant
>> >>>>
>> >>>> _______________________________________________
>> >>>> Users mailing list
>> >>>> Users@ovirt.org
>> >>>> http://lists.ovirt.org/mailman/listinfo/users
>> >>>
>> >>>
>> >>
>> >> --
>> >>        Derek Atkins                 617-623-3745
>> >>        de...@ihtfp.com             www.ihtfp.com
>> >>        Computer and Internet Security Consultant
>> >
>>
>>
>> --
>>        Derek Atkins                 617-623-3745
>>        de...@ihtfp.com             www.ihtfp.com
>>        Computer and Internet Security Consultant
>>
>>
>


-- 
       Derek Atkins                 617-623-3745
       de...@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to