Re: Xen Project Spectre/Meltdown FAQ

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2589 bytes --]

On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
> On 05/01/18 18:16, Rich Persaud wrote:
> >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@gmail.com
> >> <mailto:lars.kurth.xen@gmail.com>> wrote:
> >> Linux’s KPTI series is designed to address SP3 only.  For Xen guests,
> >> only 64-bit PV guests are affected by SP3. A KPTI-like approach was
> >> explored initially, but required significant ABI changes.  

Is some partial KPTI-like approach feasible? Like unmapping memory owned
by other guests, but keeping Xen areas mapped? This will still allow
leaking Xen memory, but there are very few secrets there (vCPUs state,
anything else?), so overall impact will be much lower.

> >> Instead
> >> we’ve decided to go with an alternate approach, which is less
> >> disruptive and less complex to implement. The chosen approach runs PV
> >> guests in a PVH container, which ensures that PV guests continue to
> >> behave as before, while providing the isolation that protects the
> >> hypervisor from SP3. This works well for Xen 4.8 to Xen 4.10, which
> >> is currently our priority.

There is one drawback of such approach: running PV will now require a
CPU with VT-x (or equivalent). I think this is a huge problem, ruining
the most important (or maybe the only, nowadays) advantage of PV versus
PVH or HVM.

> > Since PVH does not yet support PCI passthrough, are there other
> > recommended SP3 mitigations for 64-bit PV driver domains?
> 
> Lock them down?  Device driver domains, even if not fully trusted, are
> going to be part of the system and therefore at least semi-TCB.
> 
> If an attacker can't run code in your driver domain (and be aware of
> things like server side processing, JIT of SQL, etc as "running code"
> methods), they aren't in a position to mount an SP3 attack.

Well, the main reason why driver domains are used in Qubes OS is
assumption that it is not possible to really "lock them down", given
full OS (Linux) running inside and being exposed to the outside world
(having network adapters, USB controllers etc). There are so many
components running them, that for sure some of them are buggy. Just some
examples exploitable in the near past: DHCP client, Bluetooth stack.

If we'd believe that handling those devices exposed to the outside world
is "safe", we wouldn't use driver domains at all...

-- 
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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel