Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
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? Thanks Marcel
On 4 January 2018 at 09:24, Marcel Hanke <marcel.hanke@1und1.de> 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
On Thu, Jan 4, 2018 at 12:31 PM, Barak Korren <bkorren@redhat.com> 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
On 4 January 2018 at 09:24, Marcel Hanke <marcel.hanke@1und1.de> wrote: 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
2018-01-04 17:21 GMT+01:00 Yaniv Kaul <ykaul@redhat.com>:
On Thu, Jan 4, 2018 at 12:31 PM, Barak Korren <bkorren@redhat.com> 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
On 4 January 2018 at 09:24, Marcel Hanke <marcel.hanke@1und1.de> wrote: 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&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
On 4 Jan 2018, at 22:16, Sandro Bonazzola <sbonazzo@redhat.com> wrote: =20 =20 =20 2018-01-04 17:21 GMT+01:00 Yaniv Kaul <ykaul@redhat.com = <mailto:ykaul@redhat.com>>: =20 =20 On Thu, Jan 4, 2018 at 12:31 PM, Barak Korren <bkorren@redhat.com = <mailto:bkorren@redhat.com>> wrote: On 4 January 2018 at 09:24, Marcel Hanke <marcel.hanke@1und1.de = <mailto:marcel.hanke@1und1.de>> 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 =
--Apple-Mail=_78F19FC9-4529-459D-8AFF-F81CDA40E6C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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
=20 Looking at the relevant Red Hat announcement: = https://access.redhat.com/security/vulnerabilities/speculativeexecution = <https://access.redhat.com/security/vulnerabilities/speculativeexecution> =20 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. =20 AFAIK none of those components were released on CentOS yet, so if you're running oVirt on CentOS you'll need to wait. =20 CentOS kernel, microcode_ctl and linux-firmware have been released. See [1] for example. I'm sure others will follow. Y. =20 [1] = https://lists.centos.org/pipermail/centos-announce/2018-January/022696.htm= l = <https://lists.centos.org/pipermail/centos-announce/2018-January/022696.ht= ml> =20 =20 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. =20 =20 =20 =20 =20 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
=20 Once updates are available, a new node and engine-apppliance images will probably also be built and released. =20 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. =20 -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com <http://redhat.com/> | TRIED. TESTED. TRUSTED. | = redhat.com/trusted <http://redhat.com/trusted> _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> =20 =20 _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> =20 =20 =20 =20 --=20 SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat=C2=A0EMEA <https://www.redhat.com/> <https://red.ht/sig>=09 TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
</div></div></div></blockquote><div><br class=3D""></div>yes there = are</div><div>right after the base OS is completely = covered</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div= class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span = class=3D"m_438005550949541432gmail-"> > If there are Patches nessessary will there also be updates for = ovirt 4.1 or<br class=3D""> > only 4.2?<br = class=3D""></span></blockquote></span></div></div></div></blockquote></div= </div></div></div></blockquote><div><br class=3D""></div>4.1 will be = covered</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div= class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span = class=3D"m_438005550949541432gmail-"> <br class=3D""> </span>Looking at the relevant Red Hat announcement:<br class=3D""> <a =
--Apple-Mail=_78F19FC9-4529-459D-8AFF-F81CDA40E6C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 4 Jan 2018, at 22:16, Sandro Bonazzola <<a = href=3D"mailto:sbonazzo@redhat.com" class=3D"">sbonazzo@redhat.com</a>>= wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" class=3D""><br class=3D""><div class=3D"gmail_extra"><br = class=3D""><div class=3D"gmail_quote">2018-01-04 17:21 GMT+01:00 Yaniv = Kaul <span dir=3D"ltr" class=3D""><<a href=3D"mailto:ykaul@redhat.com" = target=3D"_blank" class=3D"">ykaul@redhat.com</a>></span>:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" = class=3D""><br class=3D""><div class=3D"gmail_extra"><br class=3D""><div = class=3D"gmail_quote"><span class=3D"">On Thu, Jan 4, 2018 at 12:31 PM, = Barak Korren <span dir=3D"ltr" class=3D""><<a = href=3D"mailto:bkorren@redhat.com" target=3D"_blank" = class=3D"">bkorren@redhat.com</a>></span> wrote:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span = class=3D"m_438005550949541432gmail-">On 4 January 2018 at 09:24, Marcel = Hanke <<a href=3D"mailto:marcel.hanke@1und1.de" target=3D"_blank" = class=3D"">marcel.hanke@1und1.de</a>> wrote:<br class=3D""> > Hi,<br class=3D""> > besides the kernel and microcode updates are there also updates of = ovirt-<br class=3D""> > engine and vdsm nessessary and if so, is there a timeline when the = patches can<br class=3D""> > be expected?<br = class=3D""></span></blockquote></span></div></div></div></blockquote></div= href=3D"https://access.redhat.com/security/vulnerabilities/speculativeexec= ution" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://access.redhat.com/secu<wbr = class=3D"">rity/vulnerabilities/speculati<wbr = class=3D"">veexecution</a><br class=3D""> <br class=3D""> It seems that no packages that are derived directly from oVirt were = updated.<br = class=3D""></blockquote></span></div></div></div></blockquote></div></div>= </div></div></blockquote><div><br class=3D""></div>they are, the page is = updating as it progresses</div><div><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><span = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> You can see qemu-kvm-rhev there, which is quemu-kvm-ev in CentOS -<br = class=3D""> that used to be distributed by oVirt, but these days its is shipped = as<br class=3D""> part of the CentOS VirtSIG repo.<br class=3D""> <br class=3D""> AFAIK none of those components were released on CentOS yet, so if<br = class=3D""> you're running oVirt on CentOS you'll need to wait.<br = class=3D""></blockquote><div class=3D""><br class=3D""></div></span><div = class=3D"">CentOS kernel, microcode_ctl and linux-firmware have been = released.</div><div class=3D"">See [1] for example. I'm sure others will = follow.</div><div class=3D"">Y.</div><div class=3D""><br = class=3D""></div><div class=3D"">[1] <a = href=3D"https://lists.centos.org/pipermail/centos-announce/2018-January/02= 2696.html" target=3D"_blank" class=3D"">https://lists.centos.org/<wbr = class=3D"">pipermail/centos-announce/<wbr = class=3D"">2018-January/022696.html</a></div><span class=3D""><div = class=3D""> </div></span></div></div></div></blockquote><div = class=3D""><br class=3D""></div><div class=3D"">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.</div><div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div><div class=3D""> </div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><span = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br class=3D""> I suppose oVirt packages and install scripts will be updated over the<br = class=3D""> next few days to require the newer packages, but you do not need to<br = class=3D""> wait for those updates to patch your systems, you can probably patch<br = class=3D""> as soon as the updates are made available.<br = class=3D""></blockquote></span></div></div></div></blockquote></div></div>= </div></div></blockquote><div><br class=3D""></div>I suggest to start = with the kernel</div><div>But please do read up on the various variants = and mitigations. You may not necessarily need all of = them</div><div>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.</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br class=3D""> Once updates are available, a new node and engine-apppliance images<br = class=3D""> will probably also be built and released.<br class=3D""> <br class=3D""> Please note that the above as mostly a rough estimate based on my<br = class=3D""> familiarity with the processes involved, I am not directly affiliated<br = class=3D""> with any of the teams handling the response to these CVEs.<br class=3D""> <span class=3D"m_438005550949541432gmail-HOEnZb"><font color=3D"#888888" = class=3D""><br class=3D""> --<br class=3D""> Barak Korren<br class=3D""> RHV DevOps team , RHCE, RHCi<br class=3D""> Red Hat EMEA<br class=3D""> <a href=3D"http://redhat.com/" rel=3D"noreferrer" target=3D"_blank" = class=3D"">redhat.com</a> | TRIED. TESTED. TRUSTED. | <a = href=3D"http://redhat.com/trusted" rel=3D"noreferrer" target=3D"_blank" = class=3D"">redhat.com/trusted</a><br class=3D""> </font></span><div class=3D"m_438005550949541432gmail-HOEnZb"><div = class=3D"m_438005550949541432gmail-h5">______________________________<wbr = class=3D"">_________________<br class=3D""> Users mailing list<br class=3D""> <a href=3D"mailto:Users@ovirt.org" target=3D"_blank" = class=3D"">Users@ovirt.org</a><br class=3D""> <a href=3D"http://lists.ovirt.org/mailman/listinfo/users" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://lists.ovirt.org/mailman<wbr = class=3D"">/listinfo/users</a><br class=3D""> </div></div></blockquote></span></div><br class=3D""></div></div> <br class=3D"">______________________________<wbr = class=3D"">_________________<br class=3D""> Users mailing list<br class=3D""> <a href=3D"mailto:Users@ovirt.org" class=3D"">Users@ovirt.org</a><br = class=3D""> <a href=3D"http://lists.ovirt.org/mailman/listinfo/users" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://lists.ovirt.org/<wbr = class=3D"">mailman/listinfo/users</a><br class=3D""> <br class=3D""></blockquote></div><br class=3D""><br clear=3D"all" = class=3D""><div class=3D""><br class=3D""></div>-- <br class=3D""><div = class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div = dir=3D"ltr" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" = class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div = style=3D"font-family: overpass, sans-serif; font-weight: bold; margin: = 0px; padding: 0px; font-size: 14px; text-transform: uppercase;" = class=3D""><span class=3D"">SANDRO</span> <span = class=3D"">BONAZZOLA</span></div><p style=3D"font-family: overpass, = sans-serif; font-size: 10px; margin: 0px 0px 4px; text-transform: = uppercase;" class=3D""><span class=3D"">ASSOCIATE MANAGER, SOFTWARE = ENGINEERING, EMEA ENG VIRTUALIZATION R&D</span></p><div = style=3D"font-family: overpass, sans-serif; margin: 0px; font-size: = 10px; color: rgb(153, 153, 153);" class=3D""><a = href=3D"https://www.redhat.com/" style=3D"color:rgb(0,136,206);margin:0px"= target=3D"_blank" class=3D"">Red Hat <span = class=3D"">EMEA</span></a></div><table border=3D"0" style=3D"font-family: = overpass, sans-serif; font-size: inherit;" class=3D""><tbody = class=3D""><tr class=3D""><td width=3D"100px" class=3D""><a = href=3D"https://red.ht/sig" target=3D"_blank" class=3D""><img = src=3D"https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red= -hat-black.png" width=3D"90" height=3D"auto" class=3D""></a></td><td = style=3D"font-size:10px" class=3D""><div class=3D""><a = href=3D"https://redhat.com/trusted" = style=3D"color:rgb(204,0,0);font-weight:bold" target=3D"_blank" = class=3D"">TRIED. TESTED. = TRUSTED.</a></div></td></tr></tbody></table><br = class=3D""></div></div></div></div></div></div></div></div></div></div></d= iv></div></div> </div></div> _______________________________________________<br class=3D"">Users = mailing list<br class=3D""><a href=3D"mailto:Users@ovirt.org" = class=3D"">Users@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/users<br = class=3D""></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_78F19FC9-4529-459D-8AFF-F81CDA40E6C7--
Michal Skrivanek <michal.skrivanek@redhat.com> 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 warlord@MIT.EDU PGP key available
On Mon, Jan 8, 2018 at 7:32 PM, Derek Atkins <warlord@mit.edu> wrote:
Michal Skrivanek <michal.skrivanek@redhat.com> 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 warlord@MIT.EDU PGP key available _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Yaniv Kaul <ykaul@redhat.com> writes:
On Mon, Jan 8, 2018 at 7:32 PM, Derek Atkins <warlord@mit.edu> wrote:
Michal Skrivanek <michal.skrivanek@redhat.com> 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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Thu, Jan 11, 2018 at 4:33 PM, Derek Atkins <derek@ihtfp.com> wrote:
Yaniv Kaul <ykaul@redhat.com> writes:
On Mon, Jan 8, 2018 at 7:32 PM, Derek Atkins <warlord@mit.edu> wrote:
Michal Skrivanek <michal.skrivanek@redhat.com> 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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
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-Da... good luck. Arman. On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins <derek@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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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-Da... good luck. Arman.
On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins <derek@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@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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
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.h... On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <derek@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@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-Da... good luck. Arman.
On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins <derek@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@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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
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.h...
On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <derek@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@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-Da... good luck. Arman.
On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins <derek@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@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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins <derek@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
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-
On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: performance-hit-on-lfs.html
On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <derek@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@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@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@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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
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 <derek@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
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
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-
On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: that. performance-hit-on-lfs.html
On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <derek@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
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@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@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
that 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@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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
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@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
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
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-
On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: that. performance-hit-on-lfs.html
On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins <derek@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
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@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@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
that 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@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 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Thu, Jan 11, 2018 at 5:32 PM, Derek Atkins <derek@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? ;)
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_S...
As you can see, planning I can do. Execution is more challenging ;)
Thanks!
Y.
-derek
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
participants (8)
-
Arman Khalatyan -
Barak Korren -
Derek Atkins -
Derek Atkins -
Marcel Hanke -
Michal Skrivanek -
Sandro Bonazzola -
Yaniv Kaul