[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Friday, March 16, 2018 at 3:34:05 PM UTC+1, Lorenzo Lamas wrote: > After updating to Xen 4.6.6-37, with updated BIOS/microcode, I executed > Spectre & Meltdown > Checker(https://github.com/speed47/spectre-meltdown-checker) in a PV Fedora > 26 AppVM.(Kernel 4.14.18-1) > > Hardware support is now supported: > * Hardware support (CPU microcode) for mitigation techniques > * Indirect Branch Restricted Speculation (IBRS) > * SPEC_CTRL MSR is available: YES > * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) > * Indirect Branch Prediction Barrier (IBPB) > * PRED_CMD MSR is available: YES > * CPU indicates IBPB capability: YES (IBPB_SUPPORT feature bit) > * Single Thread Indirect Branch Predictors (STIBP) > * SPEC_CTRL MSR is available: YES > * CPU indicates STIBP capability: YES > > However, the VM kernel does not seem to support the migitations: > > CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' > * Mitigated according to the /sys interface: NO (kernel confirms your > system is vulnerable) > * Mitigation 1 > * Kernel is compiled with IBRS/IBPB support: NO > * Currently enabled features > * IBRS enabled for Kernel space: NO > * IBRS enabled for User space: NO > * IBPB enabled: NO > * Mitigation 2 > * Kernel compiled with retpoline option: YES > * Kernel compiled with a retpoline-aware compiler: NO (kernel reports > minimal retpoline compilation) > > STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline, IBPB) > > > Does this mean the kernel compiled by Qubes does not support the migitations > yet, or that this test cannot get proper info from the kernel, since the > kernel is provided by Dom0 instead of the VM? Or are both true? Important typo, I forgot to add 'in the future'. "I believe, while not knowing, that the Qubes team might focus more on securing the VM's dirt (in above's analogy), but right now, it's all on the fence and cemented ground inside it." should be: "I believe, while not knowing, that the Qubes team might in the future focus more on securing the VM's dirt (in above's analogy), but right now, it's all on the fence and cemented ground inside it." -- 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/b3e1adc9-5b04-4bf5-b87c-86ac0c28318e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Friday, March 16, 2018 at 3:34:05 PM UTC+1, Lorenzo Lamas wrote: > After updating to Xen 4.6.6-37, with updated BIOS/microcode, I executed > Spectre & Meltdown > Checker(https://github.com/speed47/spectre-meltdown-checker) in a PV Fedora > 26 AppVM.(Kernel 4.14.18-1) > > Hardware support is now supported: > * Hardware support (CPU microcode) for mitigation techniques > * Indirect Branch Restricted Speculation (IBRS) > * SPEC_CTRL MSR is available: YES > * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) > * Indirect Branch Prediction Barrier (IBPB) > * PRED_CMD MSR is available: YES > * CPU indicates IBPB capability: YES (IBPB_SUPPORT feature bit) > * Single Thread Indirect Branch Predictors (STIBP) > * SPEC_CTRL MSR is available: YES > * CPU indicates STIBP capability: YES > > However, the VM kernel does not seem to support the migitations: > > CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' > * Mitigated according to the /sys interface: NO (kernel confirms your > system is vulnerable) > * Mitigation 1 > * Kernel is compiled with IBRS/IBPB support: NO > * Currently enabled features > * IBRS enabled for Kernel space: NO > * IBRS enabled for User space: NO > * IBPB enabled: NO > * Mitigation 2 > * Kernel compiled with retpoline option: YES > * Kernel compiled with a retpoline-aware compiler: NO (kernel reports > minimal retpoline compilation) > > STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline, IBPB) > > > Does this mean the kernel compiled by Qubes does not support the migitations > yet, or that this test cannot get proper info from the kernel, since the > kernel is provided by Dom0 instead of the VM? Or are both true? I do by no means have proper insight into this, but I believe for this particular case it doesn't matter much if the VM's kernel is not updated against these attacks. I will stand corrected if I'm wrong about that. My reasoning is, despite that information about the CPU can be seen in the VM's, as long as the lower system levels can't be exploited (CPU/BIOS/Xen), then it won't matter if the AppVM's kernel is exploitable, because it can't reach deeper down, and will be blocked by the patch fixes on the lower system levels. However, like Andrew mentioned above, it might still be possible to some extent use it in combination with other attacks (hypothetically), so it's not deemed completely secure (yet, at least). An illustrative example, - The dig-able dirt is the exploitable VM's. - The fence and cemented ground below the dirt inside the fence's area, is the secured VM environment. So a successful attack on an VM would be like the soft dirt ground in the VM's can be dug and breach the cement, in order to get out of the protected area (prison break). If the ground is cemented below the area inside the fence, then you cannot dig further down to escape the fenced area. So too for the AppVM's, the soft dirt ground being dug-able, but since you can't dig further down to exploit further than the lower level security (cemented ground) then it won't matter anyway. However, the issue being, if some places are not fully cemented, then it might be possible to escape. The question then is, since no one can see the cement without first digging (not the protectors, not the attackers, essentially no one knows without first digging), then it remains unknown if the area is inescapable or not. The aim of Qubes is to secure the cement and fence, not the dirty ground, i.e. no matter what you run in the VM's, it should stay secure. While true securing the VM's can add extra security, it is however not the aim here. You yourself can install more secure VM's if you prefer. I believe, while not knowing, that the Qubes team might focus more on securing the VM's dirt (in above's analogy), but right now, it's all on the fence and cemented ground inside it. Qubes OS's work, as I perceive it, focuses on securing the environment from below up. So if security inside a VM is needed, then they are not meeting their own set goals to allow a any insecure code run wild in VM's without it compromising the Qubes OS infrastructure. I have absolutely no deep insight into any of this, however, this is my perspective, perhaps it can be of use, or perhaps it can't. -- 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/c4179bd4-d648-4577-b639-e6f56a00a5dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
After updating to Xen 4.6.6-37, with updated BIOS/microcode, I executed Spectre & Meltdown Checker(https://github.com/speed47/spectre-meltdown-checker) in a PV Fedora 26 AppVM.(Kernel 4.14.18-1) Hardware support is now supported: * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: YES * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: YES * CPU indicates IBPB capability: YES (IBPB_SUPPORT feature bit) * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: YES * CPU indicates STIBP capability: YES However, the VM kernel does not seem to support the migitations: CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: NO (kernel reports minimal retpoline compilation) > STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline, IBPB) Does this mean the kernel compiled by Qubes does not support the migitations yet, or that this test cannot get proper info from the kernel, since the kernel is provided by Dom0 instead of the VM? Or are both true? -- 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/636c6c6c-66fe-45e5-9605-1c3bba03c2eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thursday, February 1, 2018 at 10:31:14 AM UTC+1, Vít Šesták wrote: > I have also seen one strange change (not sure about the timing, but it might > be related to the update) that might affect security of those who use some > pseudo-DVM for sys-usb. When I remove USB „mouse“* and attach it back, the > mouse is automatically allowed. Maybe the connection has not been closed. The > strange part is that this does not apply for USB keyboard, although the input > proxy works virtually the same. Please ignore this part, the issues with touchpad/mice rather looks like a my fault. V6 -- 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/9630075c-0ca7-4acb-a17e-7d19755b4e30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
I have installed the patch from security-testing. On system resume, I sometimes notice effects like: * Time synced noticeably late. For example, when my laptop wakes up on morning, Thunderbird considers today's e-mails as e-mails from future day (so it displays date, not only time). * Some VMs don't get the time synced at all (or at least after a huge delay that looks like forever). I've repeatedly seen this at some VM with a background bot. * The same applies to Wi-Fi. It sometimes seems to be attached even after I type the password (which is not short). I have also seen one strange change (not sure about the timing, but it might be related to the update) that might affect security of those who use some pseudo-DVM for sys-usb. When I remove USB „mouse“* and attach it back, the mouse is automatically allowed. Maybe the connection has not been closed. The strange part is that this does not apply for USB keyboard, although the input proxy works virtually the same. So, before adding an untrusted device, it is not enough to disconnect USB keyboard/touchpad. I also have to reboot the sys-usb VM. Regards, Vít Šesták 'v6ak' *) I have two USB „mice“, none of them is actual traditional mouse. One of them is a touchpad that uses mouse USB protocol. The other one is a keyboard that has capability of clicking and looks like multiple input devices on the USB protocol. -- 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/3bec4ff9-5ca5-4951-bf88-8478138b1fec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 01/24/2018 07:51 AM, Ed wrote: > On 01/24/2018 04:29 AM, Andrew David Wong wrote: > >> ## Qubes 3.2 >> >> Previously, we had planned to release an update for Qubes 3.2 that would >> have made almost all VMs run in PVH mode by backporting support for this >> mode from Qubes 4.0. > > Out of curiosity, is this still going to happen? I would love to see > this if possible, not only helping mitigate Meltdown without the > performance penalty (I believe), but also would give a nice general > security boost to 3.2 > > Thanks, > Ed > The thing is, if Qubes intends on sticking with Xen 4.6 on Qubes R3.2, then the promise of 1 year extended support after R4.0 is officially released may be hard to meet since Xen will discontinue security support in Oct 2018 (Source: https://wiki.xenproject.org/wiki/Xen_Project_Release_Features ). That means there could be a 3-4+ month period where the Qubes devs would need to manually backport from newer versions of Xen any security fixes found in Xen during that time frame (in essence, the Qubes project would need to take over maintenance of the Xen 4.6 branch for that time period). That could increase the support/maintenance burden for the Qubes devs by a lot, depending on how complex the security issues are (worse case would be another thing like Meltdown/Spectre happening again during that time frame after official Xen support ends). Xen 4.8 will be supported with security fixes by Xen until Dec 2019, so assuming that Qubes R4.0 comes out this calendar year, then there'd still be time left over to honor that 1 year extended support promise, at least when it comes to any Xen fixes. So backporting Xen 4.8 to Qubes R3.2 might actually be the better move in the long term, if the devs really intend to honor that 1 year extended support promise. But that's just my opinion. -- 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/p4alsi%245q0%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 01/24/2018 04:29 AM, Andrew David Wong wrote: ## Qubes 3.2 Previously, we had planned to release an update for Qubes 3.2 that would have made almost all VMs run in PVH mode by backporting support for this mode from Qubes 4.0. Out of curiosity, is this still going to happen? I would love to see this if possible, not only helping mitigate Meltdown without the performance penalty (I believe), but also would give a nice general security boost to 3.2 Thanks, Ed -- 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/p4a6db%248qa%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
