On Monday, January 15, 2018 at 12:57:09 PM UTC+1, awokd wrote:
> It matters a bit because Spectre is harder to exploit than Meltdown. IIUR,
> Qubes' design allowed it to constrict Meltdown to a single VM

Not in PV, which are primary type of VM in 3.2.

> I'm still
> somewhat unclear on how Spectre operates under hardware virtualization but
> you're right, it needs to be fixed.

As far as I understand, Spectre can read the memory available of victim. That 
is:

* If an application does not mitigate Spectre and attacker finds useful entry 
point, attacker can read memory of the application (but nothing more).
* If VM kernel does not mitigate Spectre and attacker finds useful entry point, 
attacker can probably read memory of whole VM (but other VMs are not affected).
* If Xen does not mitigate Spectre and attacker finds useful entry point, 
attacker can probably read memory of whole system.

Please note that:

* Attacker needs a suitable entry point. It might be difficult to find it.
* All code needs to be recompiled in order to mitigate Spectre. It is not 
binary that you are/aren't protected. Some parts of system might be protected 
at the same time when others aren't.
* Lowlevel components might need additional work because of assembly code.
* Microcode update is needed only for some variants of patches. But retpoline 
might be preferred for both performance reasons and not need of microcode 
update.

Regards,
Vít Šesták 'v6ak'

-- 
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/cb5afe86-bd1a-4444-8bb8-4bc875eeab2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to