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

[Derek Atkins]

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  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  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  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 

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

[Derek Atkins]

Thanks.

I guess that means I need to upgrade both OS and Ovirt simultaneously. 
And if I recall correctly I need to upgrade my hosted engine first and
then upgrade the host?  (This is a single-host hosted-engine setup).

I've never actually upgraded an ovirt release beyond point releases (I
started with 4.0, and currently run 4.0.6).  I did upgrade from 7.2 to
7.3, which was relatively straightforward.  My plan is to follow the
instructions at https://www.ovirt.org/release/4.1.0/ -- will the
engine-setup also wind up pulling in the OS update?  I suppose I can run a
yum update after running engine-setup?

Thanks,

-derek

On Mon, January 15, 2018 1:10 pm, Yaniv Kaul wrote:
> On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins  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  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  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 
>> 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 

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

[Yaniv Kaul]

On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins  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  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  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  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 

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

[Derek Atkins]

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
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  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  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  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

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

Re: [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  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  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  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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Derek Atkins]

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  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  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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Yaniv Kaul]

On Thu, Jan 11, 2018 at 5:32 PM, Derek Atkins  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?  ;)
>

Not for oVirt specifically right now. We'll blog about it once we release
additional improvements to detect if you are protected - right from oVirt
UI (in 4.2.1).


>
> 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.
>

You could get it from Intel, via their microcode_ctl package. When they
release for your CPU is a different manner.
See[1] for some good pointers.
Y.

[1]
https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre


>
> 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

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

[Arman Khalatyan]

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  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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Derek Atkins]

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

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

[Yaniv Kaul]

On Thu, Jan 11, 2018 at 4:33 PM, Derek Atkins  wrote:

> Yaniv Kaul  writes:
>
> > On Mon, Jan 8, 2018 at 7:32 PM, Derek Atkins  wrote:
> >
> > Michal Skrivanek  writes:
> >
> > > > If there are Patches nessessary will there also be
> updates
> > for
> > > ovirt 4.1 or
> > > > only 4.2?
> > >
> > > 4.1 will be covered
> >
> > What about 4.0?  Or will that not be covered because it depends on
> 7.3,
> > which also isn't covered??
> >
> > It will not be covered because we have 4.1 and 4.2 out, both of which we
> take
> > care of.
>
> I was afraid of that.  So I will need to upgrade to at least 7.4/4.1 to
> get this fixed.   I'll need to find some time to do that.  :(
>
> My users don't like having downtime..  and this is a single-host system.
>

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.


> > 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

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

[Derek Atkins]

Yaniv Kaul  writes:

> On Mon, Jan 8, 2018 at 7:32 PM, Derek Atkins  wrote:
>
> Michal Skrivanek  writes:
>
> >             > If there are Patches nessessary will there also be updates
> for
> >             ovirt 4.1 or
> >             > only 4.2?
> >
> > 4.1 will be covered
>
> What about 4.0?  Or will that not be covered because it depends on 7.3,
> which also isn't covered??
>
> It will not be covered because we have 4.1 and 4.2 out, both of which we take
> care of.

I was afraid of that.  So I will need to upgrade to at least 7.4/4.1 to
get this fixed.   I'll need to find some time to do that.  :(

My users don't like having downtime..  and this is a single-host system.

> 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

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

[Yaniv Kaul]

On Mon, Jan 8, 2018 at 7:32 PM, Derek Atkins  wrote:

> Michal Skrivanek  writes:
>
> > > If there are Patches nessessary will there also be updates
> for
> > ovirt 4.1 or
> > > only 4.2?
> >
> > 4.1 will be covered
>
> What about 4.0?  Or will that not be covered because it depends on 7.3,
> which also isn't covered??
>

It will not be covered because we have 4.1 and 4.2 out, both of which we
take care of.
Y.


> Thanks,
>
> -derek
> --
>Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>Member, MIT Student Information Processing Board  (SIPB)
>URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
>warl...@mit.eduPGP key available
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Derek Atkins]

Michal Skrivanek  writes:

> > If there are Patches nessessary will there also be updates for
> ovirt 4.1 or
> > only 4.2?
>
> 4.1 will be covered

What about 4.0?  Or will that not be covered because it depends on 7.3,
which also isn't covered??

Thanks,

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Michal Skrivanek]

> On 4 Jan 2018, at 22:16, Sandro Bonazzola  wrote:
> 
> 
> 
> 2018-01-04 17:21 GMT+01:00 Yaniv Kaul  >:
> 
> 
> On Thu, Jan 4, 2018 at 12:31 PM, Barak Korren  > wrote:
> On 4 January 2018 at 09:24, Marcel Hanke  > wrote:
> > Hi,
> > besides the kernel and microcode updates are there also updates of ovirt-
> > engine and vdsm nessessary and if so, is there a timeline when the patches 
> > can
> > be expected?

yes there are
right after the base OS is completely covered

> > If there are Patches nessessary will there also be updates for ovirt 4.1 or
> > only 4.2?

4.1 will be covered

> 
> Looking at the relevant Red Hat announcement:
> https://access.redhat.com/security/vulnerabilities/speculativeexecution 
> 
> 
> It seems that no packages that are derived directly from oVirt were updated.

they are, the page is updating as it progresses

> You can see qemu-kvm-rhev there, which is quemu-kvm-ev in CentOS -
> that used to be distributed by oVirt, but these days its is shipped as
> part of the CentOS VirtSIG repo.
> 
> AFAIK none of those components were released on CentOS yet, so if
> you're running oVirt on CentOS you'll need to wait.
> 
> CentOS kernel, microcode_ctl and linux-firmware have been released.
> See [1] for example. I'm sure others will follow.
> Y.
> 
> [1] 
> https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html 
> 
>  
> 
> qemu-kvm-ev has also been tagged for release, will be in next batch or 
> earlier if I can find kbsing for manually push it.
> 
> 
> 
>  
> 
> I suppose oVirt packages and install scripts will be updated over the
> next few days to require the newer packages, but you do not need to
> wait for those updates to patch your systems, you can probably patch
> as soon as the updates are made available.

I suggest to start with the kernel
But please do read up on the various variants and mitigations. You may not 
necessarily need all of them
Also, you may lack the right firmware/microcode updates from your CPU vendor at 
the moment. Red Hat's microcode package only contains those which were released 
by Intel/AMD so far.

Thanks,
michal

> 
> Once updates are available, a new node and engine-apppliance images
> will probably also be built and released.
> 
> Please note that the above as mostly a rough estimate based on my
> familiarity with the processes involved, I am not directly affiliated
> with any of the teams handling the response to these CVEs.
> 
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com  | TRIED. TESTED. TRUSTED. | 
> redhat.com/trusted 
> ___
> Users mailing list
> Users@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/users 
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/users 
> 
> 
> 
> 
> 
> -- 
> SANDRO BONAZZOLA
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
> Red Hat EMEA 
>   
> TRIED. TESTED. TRUSTED. 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

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

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

[Sandro Bonazzola]

2018-01-04 17:21 GMT+01:00 Yaniv Kaul :

>
>
> On Thu, Jan 4, 2018 at 12:31 PM, Barak Korren  wrote:
>
>> On 4 January 2018 at 09:24, Marcel Hanke  wrote:
>> > Hi,
>> > besides the kernel and microcode updates are there also updates of
>> ovirt-
>> > engine and vdsm nessessary and if so, is there a timeline when the
>> patches can
>> > be expected?
>> > If there are Patches nessessary will there also be updates for ovirt
>> 4.1 or
>> > only 4.2?
>>
>> Looking at the relevant Red Hat announcement:
>> https://access.redhat.com/security/vulnerabilities/speculativeexecution
>>
>> It seems that no packages that are derived directly from oVirt were
>> updated.
>> You can see qemu-kvm-rhev there, which is quemu-kvm-ev in CentOS -
>> that used to be distributed by oVirt, but these days its is shipped as
>> part of the CentOS VirtSIG repo.
>>
>> AFAIK none of those components were released on CentOS yet, so if
>> you're running oVirt on CentOS you'll need to wait.
>>
>
> CentOS kernel, microcode_ctl and linux-firmware have been released.
> See [1] for example. I'm sure others will follow.
> Y.
>
> [1] https://lists.centos.org/pipermail/centos-announce/
> 2018-January/022696.html
>
>

qemu-kvm-ev has also been tagged for release, will be in next batch or
earlier if I can find kbsing for manually push it.





>
>> I suppose oVirt packages and install scripts will be updated over the
>> next few days to require the newer packages, but you do not need to
>> wait for those updates to patch your systems, you can probably patch
>> as soon as the updates are made available.
>>
>> Once updates are available, a new node and engine-apppliance images
>> will probably also be built and released.
>>
>> Please note that the above as mostly a rough estimate based on my
>> familiarity with the processes involved, I am not directly affiliated
>> with any of the teams handling the response to these CVEs.
>>
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Yaniv Kaul]

On Thu, Jan 4, 2018 at 12:31 PM, Barak Korren  wrote:

> On 4 January 2018 at 09:24, Marcel Hanke  wrote:
> > Hi,
> > besides the kernel and microcode updates are there also updates of ovirt-
> > engine and vdsm nessessary and if so, is there a timeline when the
> patches can
> > be expected?
> > If there are Patches nessessary will there also be updates for ovirt 4.1
> or
> > only 4.2?
>
> Looking at the relevant Red Hat announcement:
> https://access.redhat.com/security/vulnerabilities/speculativeexecution
>
> It seems that no packages that are derived directly from oVirt were
> updated.
> You can see qemu-kvm-rhev there, which is quemu-kvm-ev in CentOS -
> that used to be distributed by oVirt, but these days its is shipped as
> part of the CentOS VirtSIG repo.
>
> AFAIK none of those components were released on CentOS yet, so if
> you're running oVirt on CentOS you'll need to wait.
>

CentOS kernel, microcode_ctl and linux-firmware have been released.
See [1] for example. I'm sure others will follow.
Y.

[1]
https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html


>
> I suppose oVirt packages and install scripts will be updated over the
> next few days to require the newer packages, but you do not need to
> wait for those updates to patch your systems, you can probably patch
> as soon as the updates are made available.
>
> Once updates are available, a new node and engine-apppliance images
> will probably also be built and released.
>
> Please note that the above as mostly a rough estimate based on my
> familiarity with the processes involved, I am not directly affiliated
> with any of the teams handling the response to these CVEs.
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

[Barak Korren]

On 4 January 2018 at 09:24, Marcel Hanke  wrote:
> Hi,
> besides the kernel and microcode updates are there also updates of ovirt-
> engine and vdsm nessessary and if so, is there a timeline when the patches can
> be expected?
> If there are Patches nessessary will there also be updates for ovirt 4.1 or
> only 4.2?

Looking at the relevant Red Hat announcement:
https://access.redhat.com/security/vulnerabilities/speculativeexecution

It seems that no packages that are derived directly from oVirt were updated.
You can see qemu-kvm-rhev there, which is quemu-kvm-ev in CentOS -
that used to be distributed by oVirt, but these days its is shipped as
part of the CentOS VirtSIG repo.

AFAIK none of those components were released on CentOS yet, so if
you're running oVirt on CentOS you'll need to wait.

I suppose oVirt packages and install scripts will be updated over the
next few days to require the newer packages, but you do not need to
wait for those updates to patch your systems, you can probably patch
as soon as the updates are made available.

Once updates are available, a new node and engine-apppliance images
will probably also be built and released.

Please note that the above as mostly a rough estimate based on my
familiarity with the processes involved, I am not directly affiliated
with any of the teams handling the response to these CVEs.

-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users