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 firstname.lastname@example.org. 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.