CVE-2018-3639 - Important - oVirt - Speculative Store Bypass
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639. oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue. If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639. If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html> An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ on your systems or manually installing the package from the repository. If you're running oVirt on a different Linux distribution, please check with your vendor for available updates. Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers. The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
On 5/23/2018 7:57 AM, Sandro Bonazzola wrote:
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
Intel has been promising microcode updates since January when Spectre first appeared and yet except for the very newest CPUs we haven't seen anything and in the cases of older CPUs, I wonder if we are ever going to see anything even if Intel has is on their "roadmap" Can someone shed some light on the vulnerability at this time given we have no microcode update, but all Kernel/Os updates applied, which supposedly handle the original Meltdown and some Spectre Variants. 1) Does the unpatched microcode exploit require "root" permissions? 2) Do the existing libvirt/qemu patches prevent a user "root" or "otherwise" in a VM from snooping on other VMs and/or the host? Sincerely, -wk
2018-05-23 18:45 GMT+02:00 WK <wkmail@bneit.com>:
On 5/23/2018 7:57 AM, Sandro Bonazzola wrote:
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
Intel has been promising microcode updates since January when Spectre first appeared and yet except for the very newest CPUs we haven't seen anything and in the cases of older CPUs, I wonder if we are ever going to see anything even if Intel has is on their "roadmap"
Can someone shed some light on the vulnerability at this time given we have no microcode update, but all Kernel/Os updates applied, which supposedly handle the original Meltdown and some Spectre Variants.
1) Does the unpatched microcode exploit require "root" permissions?
2) Do the existing libvirt/qemu patches prevent a user "root" or "otherwise" in a VM from snooping on other VMs and/or the host?
Adding Jonathan Masters, author of https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-ho... Maybe he can answer your questions.
Sincerely,
-wk
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
On 23 May 2018, at 18:45, WK <wkmail@bneit.com> wrote:
On 5/23/2018 7:57 AM, Sandro Bonazzola wrote:
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
Intel has been promising microcode updates since January when Spectre first appeared and yet except for the very newest CPUs we haven't seen anything and in the cases of older CPUs, I wonder if we are ever going to see anything even if Intel has is on their “roadmap"
I believe they did release it[1], albeit late. SandyBridge for sure, and *some* Westmere and Nehalem.
Can someone shed some light on the vulnerability at this time given we have no microcode update, but all Kernel/Os updates applied, which supposedly handle the original Meltdown and some Spectre Variants.
it requires microcode update as well for optimal performance, though reading [2] the “big hammer” approach could work without it, but I do not believe anyone had run any benchmarks yet.
1) Does the unpatched microcode exploit require "root" permissions?
2) Do the existing libvirt/qemu patches prevent a user "root" or "otherwise" in a VM from snooping on other VMs and/or the host?
libvirt/qemu patches are just propagating the new mechanism to guests, they do not implement anything in addition on their own About exploitability - not sure at this point, I guess a proof of concept implementations will show up soon Thanks, michal
Sincerely,
-wk
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org
[1] https://downloadcenter.intel.com/download/27776?v=t [2] https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-ho...
On Thu, May 24, 2018 at 10:08 AM, Michal Skrivanek < michal.skrivanek@redhat.com> wrote: [snip]
Intel has been promising microcode updates since January when Spectre
first appeared and yet except for the very newest CPUs we haven't seen anything and in the cases of older CPUs, I wonder if we are ever going to see anything even if Intel has is on their “roadmap"
I believe they did release it[1], albeit late. SandyBridge for sure, and *some* Westmere and Nehalem.
[snip]
I confirm. I was also able for example to update the microcode of my Asus U36SD laptop, bought in late 2012, with the microcode released by Intel. My cpu model that I searched for inside the list at the link, from cpuinfo: model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz From dmidecode on this system that is now on Fedora 28 it confirms the latest Bios version released by Asus: Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: U36SD.206 Release Date: 09/26/2011 and by dmesg you can see the microcode update released on February by Intel: [ 0.000000] microcode: microcode updated early to revision 0x2d, date = 2018-02-07 [ 0.000000] Linux version 4.16.10-300.fc28.x86_64 ( mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC)) #1 SMP Mon May 21 14:41:48 UTC 2018 And there is another update released on late April I didn't apply yet... Gianluca
2018-05-23 16:57 GMT+02:00 Sandro Bonazzola <sbonazzo@redhat.com>:
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639.
oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue.
If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639.
If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html>
An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ on your systems or manually installing the package from the repository.
If you're running oVirt on a different Linux distribution, please check with your vendor for available updates.
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
Update: oVirt Node 4.2.3 image RPM has been refreshed, rebased on CentOS 7.5 with above mentioned CVE fixes. An updated ISO has also been composed for new host installation. Reference tracking bug: *Bug 1578909* <https://bugzilla.redhat.com/show_bug.cgi?id=1578909> - oVirt Node 4.2.3 respin needed including CVE fixes Thanks.
The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical.
Thanks, --
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
Hello, Will a 4.1.9.x security update be released for those who can't migrate to 4.2.3.7 for any reasons? Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639.
oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue.
If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639.
If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html>
An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ on your systems or manually installing the package from the repository.
If you're running oVirt on a different Linux distribution, please check with your vendor for available updates.
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical.
Thanks, --
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
<https://red.ht/sig> <https://redhat.com/summit>
_______________________________________________ Announce mailing list -- announce@ovirt.org To unsubscribe send an email to announce-leave@ovirt.org
-- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr
2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet <blanchet@abes.fr>:
Hello,
Will a 4.1.9.x security update be released for those who can't migrate to 4.2.3.7 for any reasons?
No. oVirt 4.1 reached end of life with 4.1.9 https://lists.ovirt.org/pipermail/announce/2018-January/000383.html Please consider updating to 4.2 as soon as practical / possible.
Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639.
oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue.
If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639.
If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html>
An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ on your systems or manually installing the package from the repository.
If you're running oVirt on a different Linux distribution, please check with your vendor for available updates.
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical.
Thanks, --
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
_______________________________________________ Announce mailing list -- announce@ovirt.org To unsubscribe send an email to announce-leave@ovirt.org
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques227 avenue Professeur-Jean-Louis-Viala <https://maps.google.com/?q=227+avenue+Professeur-Jean-Louis-Viala&entry=gmail&source=g> 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14blanchet@abes.fr
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
XP has reached is end of life in may 14 and Microsoft decided to release an exceptionnal update because of a critical leak last year... so all is possible when it is about criticity! https://www.microsoft.com/en-us/download/details.aspx?id=18770 Le 28/05/2018 à 14:23, Sandro Bonazzola a écrit :
2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>>:
Hello,
Will a 4.1.9.x security update be released for those who can't migrate to 4.2.3.7 for any reasons?
No. oVirt 4.1 reached end of life with 4.1.9 https://lists.ovirt.org/pipermail/announce/2018-January/000383.html Please consider updating to 4.2 as soon as practical / possible.
Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639 <https://access.redhat.com/security/cve/cve-2018-3639>.
oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue.
If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639 <https://access.redhat.com/security/cve/cve-2018-3639>.
If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html>
An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ <https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/> on your systems or manually installing the package from the repository.
If you're running oVirt on a different Linux distribution, please check with your vendor for available updates.
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical.
Thanks, --
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
<https://red.ht/sig> <https://redhat.com/summit>
_______________________________________________ Announce mailing list --announce@ovirt.org <mailto:announce@ovirt.org> To unsubscribe send an email toannounce-leave@ovirt.org <mailto:announce-leave@ovirt.org>
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala <https://maps.google.com/?q=227+avenue+Professeur-Jean-Louis-Viala&entry=gmail&source=g> 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr <mailto:blanchet@abes.fr>
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr
On Mon, May 28, 2018 at 3:40 PM, Nathanaël Blanchet <blanchet@abes.fr> wrote:
XP has reached is end of life in may 14 and Microsoft decided to release an exceptionnal update because of a critical leak last year... so all is possible when it is about criticity!
All is indeed possible. We always welcome contribution to the oVirt project, and you can send patches that backport the 4.2 patches to 4.1 and build it. Y.
https://www.microsoft.com/en-us/download/details.aspx?id=18770
Le 28/05/2018 à 14:23, Sandro Bonazzola a écrit :
2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet <blanchet@abes.fr>:
Hello,
Will a 4.1.9.x security update be released for those who can't migrate to 4.2.3.7 for any reasons?
No. oVirt 4.1 reached end of life with 4.1.9 https://lists.ovirt.org/ pipermail/announce/2018-January/000383.html Please consider updating to 4.2 as soon as practical / possible.
Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639.
oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue.
If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639 .
If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html>
CESA-2018:1632 Important CentOS 7 libvirt Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html>
CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html>
An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64 /kvm-common/ on your systems or manually installing the package from the repository.
If you're running oVirt on a different Linux distribution, please check with your vendor for available updates.
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical.
Thanks, --
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
_______________________________________________ Announce mailing list -- announce@ovirt.org To unsubscribe send an email to announce-leave@ovirt.org
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques227 avenue Professeur-Jean-Louis-Viala <https://maps.google.com/?q=227+avenue+Professeur-Jean-Louis-Viala&entry=gmail&source=g> 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14blanchet@abes.fr
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14blanchet@abes.fr
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community- guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/ message/JU2IA6ZZAVZVVWSYCF3RL62S2KMQVEXJ/
I'm not able to do such a thing but it is quite good to know it is feasible! Was nice to meet you at San Francisco summit :) Le 28/05/2018 à 19:56, Yaniv Kaul a écrit :
On Mon, May 28, 2018 at 3:40 PM, Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>> wrote:
XP has reached is end of life in may 14 and Microsoft decided to release an exceptionnal update because of a critical leak last year... so all is possible when it is about criticity!
All is indeed possible. We always welcome contribution to the oVirt project, and you can send patches that backport the 4.2 patches to 4.1 and build it. Y.
https://www.microsoft.com/en-us/download/details.aspx?id=18770 <https://www.microsoft.com/en-us/download/details.aspx?id=18770>
Le 28/05/2018 à 14:23, Sandro Bonazzola a écrit :
2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>>:
Hello,
Will a 4.1.9.x security update be released for those who can't migrate to 4.2.3.7 for any reasons?
No. oVirt 4.1 reached end of life with 4.1.9 https://lists.ovirt.org/pipermail/announce/2018-January/000383.html <https://lists.ovirt.org/pipermail/announce/2018-January/000383.html> Please consider updating to 4.2 as soon as practical / possible.
Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639 <https://access.redhat.com/security/cve/cve-2018-3639>.
oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue.
If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639 <https://access.redhat.com/security/cve/cve-2018-3639>.
If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update<https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html>
An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ <https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/> on your systems or manually installing the package from the repository.
If you're running oVirt on a different Linux distribution, please check with your vendor for available updates.
Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers.
The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical.
Thanks, --
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
<https://red.ht/sig> <https://redhat.com/summit>
_______________________________________________ Announce mailing list --announce@ovirt.org <mailto:announce@ovirt.org> To unsubscribe send an email toannounce-leave@ovirt.org <mailto:announce-leave@ovirt.org>
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala <https://maps.google.com/?q=227+avenue+Professeur-Jean-Louis-Viala&entry=gmail&source=g> 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr <mailto:blanchet@abes.fr>
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr <mailto:blanchet@abes.fr>
_______________________________________________ Users mailing list -- users@ovirt.org <mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org <mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ <https://www.ovirt.org/site/privacy-policy/> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JU2IA6ZZAVZVVW... <https://lists.ovirt.org/archives/list/users@ovirt.org/message/JU2IA6ZZAVZVVWSYCF3RL62S2KMQVEXJ/>
-- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr
participants (6)
-
Gianluca Cecchi -
Michal Skrivanek -
Nathanaël Blanchet -
Sandro Bonazzola -
WK -
Yaniv Kaul