Re: [qubes-users] Will SLAT / EPT truly make QUBES 4.0 more secure..?

2016-07-28 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jul 28, 2016 at 03:05:59PM -0700, neilhard...@gmail.com wrote:
> Based on 2 Xen exploits in just the last 1 year, QUBES 4.0 is moving over to 
> using SLAT / EPT for memory isolation, and to using HVM/PVH rather than PV.
> 
> Certainly, in the last 2 Xen exploits, it has only affected PV and not HVM.
> 
> However, is it possible that using Intel's EPT is even riskier..?
> 
> Intel ME is said to be insecure by Joanna Rutkowska due to its insecure 
> implementation, and not being able to look at the code, because it is 
> closed-source.

The main problem with Intel ME is that we can't really know what it is
doing. It is basically a second system with full access to all resources
(including RAM) and we can't look even at the binary running there. Or
disable it. So, even it is bug-free (which is unlikely), it may still be
malicious on purpose and we don't have any way to detect it.

> Well, couldn't the same be said for Intel's EPT..? Surely this is 
> closed-source too..? No..?
> 
> At least with Xen, we can actually see the code and fix the bugs, whereas 
> surely with Intel we have no chance.
> 
> Or am I missing something here..?

Yes, the missing part is that you use your CPU anyway. So if the
microcode, or whatever part of CPU is implementing EPT, is buggy, it
will affect the system in any case (in case of EPT, in Qubes 3.x, it
will affect only HVM, but still). On the other hand, not using PV
domains makes a whole lot of Xen code unavailable to the attacker. Quite
complex code, and as we can see, somehow buggy.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXmobVAAoJENuP0xzK19csO6AH/2w2L+o/EToBzEoW0FyFfgiI
v8tnU6f5KN/yw9jN/PDv9fuYO7emvgFCHmIf7HKht+i1tMeOXYfeE3QFVLeSiLV9
VtXQeCCC6XChGVsqulhuAQz+c1an5cEpGJEOG3UPcodVVvHRFQEE0KZX50O1cH/W
Icb5N6XTx/wNVLysn/CerJQMIa7CHMjylGJwIgFKX5GpdHcWSZ58QLvxDeog74Ry
LxvlRBJcWogq4yafIFIE1RKsfTx8J/13vzSbOJRQXG4KgkZ9KcYXqKreVtJkzHsZ
YoGbZVCOgdtHyjABunWkduID6UkCYVSR9MNpLEGMTAxTtu7n0ko7m6vZHdLAYBU=
=ix6h
-END PGP SIGNATURE-

-- 
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/20160728222732.GH32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Will SLAT / EPT truly make QUBES 4.0 more secure..?

2016-07-28 Thread neilhardley
Based on 2 Xen exploits in just the last 1 year, QUBES 4.0 is moving over to 
using SLAT / EPT for memory isolation, and to using HVM/PVH rather than PV.

Certainly, in the last 2 Xen exploits, it has only affected PV and not HVM.

However, is it possible that using Intel's EPT is even riskier..?

Intel ME is said to be insecure by Joanna Rutkowska due to its insecure 
implementation, and not being able to look at the code, because it is 
closed-source.

Well, couldn't the same be said for Intel's EPT..? Surely this is closed-source 
too..? No..?

At least with Xen, we can actually see the code and fix the bugs, whereas 
surely with Intel we have no chance.

Or am I missing something here..?

-- 
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/fb61e544-740e-4e7a-a837-898e507d2711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.