Re: [qubes-users] Impact of the Intel hyper-threading bug [Skylake & Kaby Lake]?
Thanks Unman. 26.07.2017, 17:21, "Unman" <un...@thirdeyesecurity.org>: > On Tue, Jul 25, 2017 at 05:14:45PM +0300, private user82 wrote: >> I am concerned about the recent bug affecting Skylake and Kaby Lake gen >> Intel processors - >> https://lists.debian.org/debian-devel/2017/06/msg00308.html >> >> As BIOS updates aren't yet available from many mobo manufacturers, how can >> we Qubes users best defend ourselves against an exploit? In this post I am >> hoping to reach out to someone who may be able to comment on how we can best >> configure our platforms until a fix is available. >> >> Following the advice in the linked Debian advisory, I have disabled >> hyper-threading in the BIOS settings. My questions are as follows: >> >> 1) When I check /proc/cpuinfo in dom0, 'ht' remains listed as a flag >> (capability). Running $ lscpu in dom0 indicates that 'Threads per core: 1' >> so I assume the BIOS has in fact disabled hyper-threading. Is this correct, >> or should the flag also disappear when functionality is disabled in BIOS >> settings? >> >> 2) Is it safe to run multiple VCPUs (up to the number of physical cores) >> for each Guest VM. Or, in light of this bug, should we only be using a >> single VCPU for each guest? >> >> Many thanks in advance. > > I seem to recall that Xen used to advise disabling hyperthreading, and > VMWare counsel against its use when provisioning vcpus. > In general there's no advantage in assigning more than physical cores to any > VM. > > On the specifics, I *think* that cpuinfo reports capabilities even if > they have been diabled, so that isnt an issue. > > I dont see any issue in assigning multiple vcpus up to the number of > physical cores. I dont think that bug is relevant to the decision. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/315281501502066%40web9o.yandex.ru. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Impact of the Intel hyper-threading bug [Skylake & Kaby Lake]?
I am concerned about the recent bug affecting Skylake and Kaby Lake gen Intel processors - https://lists.debian.org/debian-devel/2017/06/msg00308.html As BIOS updates aren't yet available from many mobo manufacturers, how can we Qubes users best defend ourselves against an exploit? In this post I am hoping to reach out to someone who may be able to comment on how we can best configure our platforms until a fix is available. Following the advice in the linked Debian advisory, I have disabled hyper-threading in the BIOS settings. My questions are as follows: 1) When I check /proc/cpuinfo in dom0, 'ht' remains listed as a flag (capability). Running $ lscpu in dom0 indicates that 'Threads per core: 1' so I assume the BIOS has in fact disabled hyper-threading. Is this correct, or should the flag also disappear when functionality is disabled in BIOS settings? 2) Is it safe to run multiple VCPUs (up to the number of physical cores) for each Guest VM. Or, in light of this bug, should we only be using a single VCPU for each guest? Many thanks in advance. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/129571500992085%40web5j.yandex.ru. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Expired certificate warnings for ftp.qubes-os.org
Hi, I'm receiving warnings in my browser that the certificates for "ftp.qubes-os.org" and "keys.qubes-os.org" have expired today. SHA256 Fingerprint=42:DE:02:82:3F:8C:27:3E:6B:E0:D0:8B:4F:36:7A:64:23:9F:CD:74:78:2B:82:43:1E:0C:31:AE:0C:B6:54:F3 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 Validity Not Before: Jul 18 08:15:00 2017 GMT Not After : Oct 16 08:15:00 2017 GMT Subject: CN=ftp.qubes-os.org -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/13141508156182%40web17j.yandex.ru. For more options, visit https://groups.google.com/d/optout.
[qubes-users] USB exposed to M.2 SSD drives?
Browsing the Wikipedia page for the M.2 SSD Form Factor (https://en.wikipedia.org/wiki/M.2), I noticed that multiple buses are exposed through the M.2 connector, including USB. My question is, does this represent an isolation problem for Qubes? I.e. could a malicious USB device bypass the isolation provided by VT-d, in order to gain direct communication with an SSD controller for a firmware compromise of the SSD?.. Perhaps this issue is mitigated in some way, would be great to hear people's thoughts on the matter, as many new devices (including the Purism offerings) are shipping with these ports. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/12621510616670%40web58j.yandex.ru. For more options, visit https://groups.google.com/d/optout.
