virt

virt@lists.centos.org

1612 discussions

Speculative attack mitigations
by Jonathan Archdale - Blacknight 12 Jun '19

12 Jun '19

Hi folks, Firstly; apologies in advance for what is a head wrecker of keeping on top of the speculative mitigations and also if this is a duplicate email; my first copy didn't seem to make it into the archive. Also a disclaimer that I may have misunderstood elements of the below but please bear with me. I write this hoping to find out a bit more about the state of the relevant kernel patches for the various speculative attack mitigations in the current 4.9.177-35 kernel used in the centos-virt tree. For reference; I am running a Dell R620, using an E5-2620 v2 CPU, using 4.9.177-35 from the xen-410 tree in the EL6 branch ; though I am still using xen 4.6 at this time. I have been told in the irc channel that the kernel is not built against a specific version of xen so this should make no odds. As per https://www.dell.com/support/home/ie/en/iebsdt1/drivers/driversdetails?driv… - bios version 2.70 (installed) contains mitigations for CVE-2018-3639 (variant 3a route system register read) and CVE-2018-3640 (variant 4, speculative store bypass). I am also running the latest available intel microcode for the CPU; as imported via 'module /GenuineIntel.bin' and 'ucode=2' in my grub.conf to import (as taken from https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files) # uname -r 4.9.177-35.el6.x86_64 # cat /proc/cmdline ro root=UUID=0e51d8dc-6409-4715-83f4-f86fa24083e2 rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_NO_MD nodmraid SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet intel_idle.max_cstate=0 processor.max_cstate=0 l1ft=full mds=full,nosmt ssbd=force-on # grep -e flags -e "model name" -e microcode -e bugs /proc/cpuinfo | sort -u model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz microcode : 0x42e flags : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc arch_perfmon rep_good nopl nonstop_tsc pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm fsgsbase erms xsaveopt dtherm ida arat pln pts bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds You will note that there is a lack of flags for ssbd, spec_ctrl, intel_stibp, flush_l1d, ibrs, etc. # for i in /sys/devices/system/cpu/vulnerabilities/* ; do echo -n "$i : "; cat $i ; done /sys/devices/system/cpu/vulnerabilities/l1tf : Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/mds : Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown /sys/devices/system/cpu/vulnerabilities/meltdown : Vulnerable /sys/devices/system/cpu/vulnerabilities/spec_store_bypass : Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v1 : Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2 : Mitigation: Full generic retpoline, STIBP: disabled, RSB filling Despite having relevant microcode, I am still seeing the box as showing vulnerable to meltdown, speculative store bypass (ssbd), as well as MDS via MD_CLEAR mitigation. When I mount the debugfs, the flag for ibrs is missing - preventing me enabling it as a mitigation for ssbd (due to lack of relevant cpu flag): # mount -t debugfs none /sys/kernel/debug/ # ls -lahtr /sys/kernel/debug/x86/ibrs_enabled ls: cannot access /sys/kernel/debug/x86/ibrs_enabled: No such file or directory I have other R620's with the same CPUs running stock el6 kernels that are showing as fully patched to these issues. Could I please get some feedback from whoever builds out the kernels; if the mitigations/patches are in place in the 4.9.177-35 kernel for the various speculative mitigations? Specifically; CVE-2018-3639, CVE-2018-3640, CVE-2018-3646, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127 and CVE-2019-11091. Many thanks for your response. Regards, Jonathan

2 1

CentOS 7 Xen 4.12 libvirt/virt-manager wrong path for qemu-system-i386
by Pasi Kärkkäinen 27 May '19

27 May '19

Hello, While testing Virt-SIG Xen 4.12 rpms on CentOS7 I noticed the following problem with libvirt/virt-manager when manually installing a new HVM guest from virt-manager GUI.. basicly the VM installation won't start, because libvirt/virt-manager is not able to start the VM, due to "missing" qemu-system-i386 binary: Unable to complete install: 'unsupported configuration: emulator '/usr/lib/xen/bin/qemu-system-i386' not found' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 2553, in _do_async_install guest.start_install(meter=meter) File "/usr/share/virt-manager/virtinst/guest.py", line 498, in start_install doboot, transient) File "/usr/share/virt-manager/virtinst/guest.py", line 434, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3725, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: unsupported configuration: emulator '/usr/lib/xen/bin/qemu-system-i386' not found Quick'n'dirty fix is to create a symlink: ln -s /usr/lib64/xen/bin/qemu-system-i386 /usr/lib/xen/bin/qemu-system-i386 .. after creating that symlink the VM can be started just fine and works OK. We need to fix that default directory path for qemu-system-i386 to be correct out-of-the-box.. Thanks, -- Pasi

2 3

centos-virt CPU microcode updates?
by Karel Hendrych 16 May '19

16 May '19

Hi, is there any guide for CPU microcode updates on CentOS6, Xen 4.10, kernel 4.9 ? Thanks Karel

3 3

Centos7 Xen hypervisor console= options broken in default grub2 config
by Pasi Kärkkäinen 05 May '19

05 May '19

Hello, While testing Virt-SIG Xen 4.12 rpms on CentOS 7, I noticed the default Xen hypervisor console= option parameters are broken, and result in an error from Xen, and no output on the physical vga console: >From xen dmesg: (XEN) Bad console= option 'tty' Xen 4.12.0-1.el7 (XEN) Xen version 4.12.0-1.el7 (mockbuild(a)centos.org) (gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)) debug=n Tue Apr 2 13:09:41 UTC 2019 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.02~beta2 (XEN) Command line: placeholder dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all .. and indeed, 'tty' is not a valid option for Xen hypervisor console= parameter. That can be easily fixed in "/etc/sysconfig/grub", and executing "grub2-mkconfig -o /boot/grub2/grub.cfg" afterwards, but we should fix the default.. Here is the working setting (console=com1,vga, instead of console=com1,tty): # grep GRUB_CMDLINE_XEN_DEFAULT /etc/sysconfig/grub GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all" Thanks, -- Pasi

1 0

CentOS virt-sig Linux kernel 4.9.155 build
by Pasi Kärkkäinen 26 Mar '19

26 Mar '19

Hello everyone, Some of you might remember discussions earlier in 2017 (huh, long time ago) on centos-virt list about Linux kernel tty/ldisc related bug, which caused Xen dom0 kernel crashes for some people (and also more easy to trigger crashes on other arches, like on hp pa-risc), but the bug was difficult to reproduce for others/most people. Fix for this issue was merged to centos virt-sig Linux 4.9.48-29 kernel earlier in 2017, but reverted/deleted in 4.9.75-30 due to problems with the patch. The patch in question was also merged to upstream Linux kernel, and later reverted there aswell. But now finally the issue has been resolved in upstream Linux, and the patches have been already backported to Linux 4.9.152 longterm stable kernel. Changelog: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.152 You can find the tty/ldisc patches there. So I propose we build the latest 4.9.155 kernel for CentOS virt-sig for centos6 and centos7. Thanks, -- Pasi

3 15

Xen-kernel: Update to 4.14 or 4.19?
by George Dunlap 08 Mar '19

08 Mar '19

Hey all, We've been on 4.9 for some time now, and while it's still supported, I think it's time to start thinking about upgrading, and I'd like input from the community about which version to move up to. 4.19 has been out for almost 5 months now. It will include PVH domU support, and PVH dom0 support in what _is believed_ to be the final form; so when the Virt SIG moves to a version of Xen that supports PVH dom0, the kernel will already be in place with no need to upgrade. The other option would be to move to 4.14: Probably more stable (as it's been out for over a year now), but doesn't have either PVH domU or PVH dom0 support. I'd suggest 4.19. Any other opinions? -George

6 5

libvirt stuck when executing 2 or more parallel calls
by Oleksandr Panchuk 08 Mar '19

08 Mar '19

Hello, Recently built RPM package libvirt-4.3.0-1.xen48.el6 ( https://cbs.centos.org/koji/buildinfo?buildID=25235 ) has following issue: When trying to run two or more virus commands (2 or more simultaneous calls to libvirtd) we got virsh stuck. See attached strace log. What could be possible cause? Thanks,

2 1

CentOS 7.6 and Xen 4.6
by George Dunlap 05 Mar '19

05 Mar '19

Hey all, In order to make sure SIG content is "fresh", whenever a new version of CentOS comes out, content is discarded automatically unless SIG chairs specifically request it to be moved over. At the moment, Xen has three repos that are under consideration to be moved up: virt/x86_64/xen-46 virt/x86_64/xen-48 virt/x86_64/xen-410 I'll request xen-48 and xen-410 to be updated for sure, but I wanted to gauge how much interest there was in xen-46. If you have strong feelings about xen-46, let me know (and perhaps consider volunteering to maintain the packages). Thanks, -George ---------- Forwarded message --------- From: Anssi Johansson <avij(a)centosproject.org> Date: Thu, Nov 1, 2018 at 9:02 AM Subject: [CentOS-devel] SIGs: Possibility to drop EOL content at 7.6.1810 release time To: The CentOS developers mailing list. <centos-devel(a)centos.org> So here we go again. As one of the virtues of a programmer is laziness, I'll just cut&paste the previous email with some modifications. You know the drill. RHEL 7.6 was released a few days ago and building CentOS 7.6.1810 has just started. This would be an excellent time to remove any EOL software you may have floating around on mirror.centos.org. mirror.centos.org should have only supported packages available. SIGs should explicitly state which content they want copied over from 7.5.1804 to 7.6.1810. I'd imagine that for example ceph-jewel could be dropped because it went EOL in July 2018. Is there some other content that could be dropped? If you are planning to keep content available that has gone EOL upstream, you must commit to backport any required security fixes to it. If SIGs want to transfer some of their packages from 7.5.18004 to 7.6.1810, please let hughesjr know. You can probably simply reply to this message to let people know of your decision. It is possible that some other SIG depends on your packages that are going to be removed. In that case the other SIG should probably update their packages to depend on supported versions. Content to be transferred over to 7.6.1810 can be specified either by directory name, or by individual package names. There are also various centos-release-* packages in extras, http://mirror.centos.org/centos/7.5.1804/extras/x86_64/Packages/ , perhaps some of those could be trimmed as well. You should also communicate to your users in advance that the EOL packages will disappear, and if necessary, instruct them to migrate to a newer supported version. Having instructions for that procedure published somewhere would be nice. The old content under 7.5.1804, including any EOL content, will be archived to vault.centos.org, and that content will be available in the vault indefinitely. The 7.5.1804 directory on mirror.centos.org will be emptied some time after 7.6.1810 is released. For reference and inspiration, here are some directories from mirror.centos.org, including both up-to-date content and potentially EOL content. SIGs should review the list to make sure these directories can be copied over to 7.6.1810 when that time comes. Making the decisions now would save a bit of time at 7.6.1810 release time. cloud/x86_64/openstack-ocata cloud/x86_64/openstack-pike cloud/x86_64/openstack-queens cloud/x86_64/openstack-rocky configmanagement/x86_64/ansible26 configmanagement/x86_64/yum4 dotnet nfv/x86_64/fdio/vpp/vpp-1710 nfv/x86_64/fdio/vpp/vpp-1801 nfv/x86_64/fdio/vpp/vpp-1804 nfv/x86_64/fdio/vpp/vpp-1807 opstools/x86_64/common opstools/x86_64/fluentd opstools/x86_64/logging opstools/x86_64/perfmon opstools/x86_64/sensu paas/x86_64/openshift-origin paas/x86_64/openshift-origin13 paas/x86_64/openshift-origin14 paas/x86_64/openshift-origin15 paas/x86_64/openshift-origin36 paas/x86_64/openshift-origin37 paas/x86_64/openshift-origin38 paas/x86_64/openshift-origin39 paas/x86_64/openshift-origin310 sclo/x86_64/rh/devassist09 sclo/x86_64/rh/devtoolset-3 sclo/x86_64/rh/devtoolset-4 sclo/x86_64/rh/devtoolset-6 sclo/x86_64/rh/devtoolset-7 sclo/x86_64/rh/git19 sclo/x86_64/rh/go-toolset-7 sclo/x86_64/rh/httpd24 sclo/x86_64/rh/llvm-toolset-7 sclo/x86_64/rh/mariadb55 sclo/x86_64/rh/maven30 sclo/x86_64/rh/mongodb24 sclo/x86_64/rh/mysql55 sclo/x86_64/rh/nginx16 sclo/x86_64/rh/nodejs010 sclo/x86_64/rh/passenger40 sclo/x86_64/rh/perl516 sclo/x86_64/rh/php54 sclo/x86_64/rh/php55 sclo/x86_64/rh/postgresql92 sclo/x86_64/rh/python27 sclo/x86_64/rh/python33 sclo/x86_64/rh/python34 sclo/x86_64/rh/rh-eclipse46 sclo/x86_64/rh/rh-git29 sclo/x86_64/rh/rh-haproxy18 sclo/x86_64/rh/rh-java-common sclo/x86_64/rh/rh-mariadb100 sclo/x86_64/rh/rh-mariadb101 sclo/x86_64/rh/rh-mariadb102 sclo/x86_64/rh/rh-maven33 sclo/x86_64/rh/rh-maven35 sclo/x86_64/rh/rh-mongodb26 sclo/x86_64/rh/rh-mongodb30upg sclo/x86_64/rh/rh-mongodb32 sclo/x86_64/rh/rh-mongodb34 sclo/x86_64/rh/rh-mongodb36 sclo/x86_64/rh/rh-mysql56 sclo/x86_64/rh/rh-mysql57 sclo/x86_64/rh/rh-nginx18 sclo/x86_64/rh/rh-nginx110 sclo/x86_64/rh/rh-nginx112 sclo/x86_64/rh/rh-nodejs4 sclo/x86_64/rh/rh-nodejs6 sclo/x86_64/rh/rh-nodejs8 sclo/x86_64/rh/rh-perl520 sclo/x86_64/rh/rh-perl524 sclo/x86_64/rh/rh-perl526 sclo/x86_64/rh/rh-php56 sclo/x86_64/rh/rh-php70 sclo/x86_64/rh/rh-php71 sclo/x86_64/rh/rh-postgresql10 sclo/x86_64/rh/rh-postgresql94 sclo/x86_64/rh/rh-postgresql95 sclo/x86_64/rh/rh-postgresql96 sclo/x86_64/rh/rh-python35 sclo/x86_64/rh/rh-python36 sclo/x86_64/rh/rh-redis32 sclo/x86_64/rh/rh-ror42 sclo/x86_64/rh/rh-ror50 sclo/x86_64/rh/rh-ruby23 sclo/x86_64/rh/rh-ruby24 sclo/x86_64/rh/rh-ruby25 sclo/x86_64/rh/rh-scala210 sclo/x86_64/rh/rh-thermostat16 sclo/x86_64/rh/rh-varnish4 sclo/x86_64/rh/rh-varnish5 sclo/x86_64/rh/ror40 sclo/x86_64/rh/ror41 sclo/x86_64/rh/ruby193 sclo/x86_64/rh/ruby200 sclo/x86_64/rh/ruby22 sclo/x86_64/rh/rust-toolset-7 sclo/x86_64/rh/thermostat1 sclo/x86_64/rh/v8314 sclo/x86_64/sclo/sclo-cassandra3 sclo/x86_64/sclo/sclo-git25 sclo/x86_64/sclo/sclo-git212 sclo/x86_64/sclo/sclo-httpd24more sclo/x86_64/sclo/sclo-php54 sclo/x86_64/sclo/sclo-php55 sclo/x86_64/sclo/sclo-php56 sclo/x86_64/sclo/sclo-php70 sclo/x86_64/sclo/sclo-php71 sclo/x86_64/sclo/sclo-python27 sclo/x86_64/sclo/sclo-python34 sclo/x86_64/sclo/sclo-python35 sclo/x86_64/sclo/sclo-ror42 sclo/x86_64/sclo/sclo-subversion19 sclo/x86_64/sclo/vagrant1 storage/x86_64/ceph-jewel storage/x86_64/ceph-luminous storage/x86_64/gluster-3.10 storage/x86_64/gluster-3.12 storage/x86_64/gluster-4.0 storage/x86_64/gluster-4.1 storage/x86_64/gluster-5 virt/x86_64/azure virt/x86_64/kubernetes19 virt/x86_64/kubernetes110 virt/x86_64/kvm-common virt/x86_64/libvirt-latest virt/x86_64/ovirt-4.2 virt/x86_64/xen-46 virt/x86_64/xen-48 virt/x86_64/xen-410 In addition to those, ovirt-4.1 should have already been removed, but it is still available in the altarch branch for aarch64 and ppc64le. This is an error, which will hopefully get fixed this round. _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel

2 4

CVE-2019-5736
by Frantisek Kluknavsky 12 Feb '19

12 Feb '19

Hi, builds fixing CVE-2019-5736 in runc and docker are in cbs: https://cbs.centos.org/koji/buildinfo?buildID=25142 https://cbs.centos.org/koji/buildinfo?buildID=25136 The security flaw is quite severe. Please, what should be done? I am not very well versed in the processes and do not want to neglect anything. Thank you very much and have a nice day, Fero

1 0

Cri-o 1.13 package
by Matheus Eduardo Bonifacio Morais 07 Feb '19

07 Feb '19

Hi there, I was looking for cri-o 1.13 package to install on CentOS 7.6 but it seems that we only have 1.11 packaged. There is any alternative to 1.13 package to CenOS 7.6 or if I want to use it I should build from source? Thanks. -- Matheus Eduardo Bonifácio Morais Analista de Infraestrutura de TI, Plataforma e Aplicações Confederação Sicredi Centro Administrativo Sicredi – Porto Alegre +55 51 3358 7143 sicredi.com.br Esta mensagem é somente para uso do destinatário informado e pode conter informações privilegiadas, proprietárias ou privadas. Se você recebeu esta mensagem por engano, por favor, notifique o remetente imediatamente e apague a original. Qualquer outro uso deste e-mail é proibido. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

2 2

← Newer
1
...
4
5
6
7
8
9
10
...
162
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt