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 

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to