[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Re: Qubes Security Bulletin #23
From: VÃt_Å esták <groups-no-private-mail--contact-me-at--co
Date: 2015-12-21 17:28:24
Message-ID: fb3acefd-d1ff-4462-b79b-5faf9b65f238 () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Monday, December 21, 2015 at 6:09:53 PM UTC+1, Eric Shelton wrote:
>
> I do not think that is correct. Looking at lines 78-108 of the QSB, the
> characteristic that defines what you call a "traditional Xen deployment"
> does not have anything to do with using an IOMMU, but instead whether a
> backend is located in dom0 or in a "driver domain."
>
Sure, even without IOMMU, Qubes is not the "traditional Xen deployment"
(TXD). But it is much more similar to the TXD, because all domains with a
PCI device have access to whole RAM through DMA, so they are effectively a
part of TCB. In such cases, the attack gives attacker nothing previously
not owned on any non-IOMMU system.
> In contrast, Qubes has at least the net backend in NetVM, as well as
> ProxyVM as you noted. Plus, if you set up a USBVM, sharing a USB flash
> drive or such causes the USBVM to act as a block backend as well.
>
That's true. However, if NetVM or USBVM is compromised on a non-IOMMU, then
they can perform the DMA attack. It depends if ProxyVMs and FirewallVMs are
to be considered as a significant additional risk.
Also, the QSB notes an example where an AppVM hosts an ISO for another
> domain.
>
Maybe this could have some impact, not sure. However, I am not sure if the
block device sharing allows such attack and what direction it would work
in. If host can attack the guest, but not vice versa, I usually don't care,
because I usually run installer from such device, implying some trust…
However, even on a system without an IOMMU, I would not say that we
> "already trust NetVMs," as there is still significant isolation provided by
> having it in a separate domain
>
This is what I am not sure about. Maybe such attack would have to be
slightly adapted for some type of the PCI device. But if you have a
well-known device…
Regards,
VÃt Å esták 'v6ak'
--
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/fb3acefd-d1ff-4462-b79b-5faf9b65f238%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #5 (text/html)]
<div dir="ltr"><br><br>On Monday, December 21, 2015 at 6:09:53 PM UTC+1, Eric Shelton \
wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">I do not think \
that is correct. Looking at lines 78-108 of the QSB, the characteristic that \
defines what you call a "traditional Xen deployment" does not have anything \
to do with using an IOMMU, but instead whether a backend is located in dom0 or in a \
"driver domain."</div></blockquote><div>Sure, even without IOMMU, Qubes is \
not the "traditional Xen deployment" (TXD). But it is much more similar to the TXD, \
because all domains with a PCI device have access to whole RAM through DMA, so they \
are effectively a part of TCB. In such cases, the attack gives attacker nothing \
previously not owned on any non-IOMMU system.<br> </div><blockquote \
class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc \
solid;padding-left: 1ex;"><div dir="ltr">In contrast, Qubes has at least the net \
backend in NetVM, as well as ProxyVM as you noted. Plus, if you set up a USBVM, \
sharing a USB flash drive or such causes the USBVM to act as a block backend as \
well.</div></blockquote><div>That's true. However, if NetVM or USBVM is \
compromised on a non-IOMMU, then they can perform the DMA attack. It depends if \
ProxyVMs and FirewallVMs are to be considered as a significant additional \
risk.<br><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"> Also, the QSB \
notes an example where an AppVM hosts an ISO for another \
domain.</div></blockquote><div><br>Maybe this could have some impact, not sure. \
However, I am not sure if the block device sharing allows such attack and what \
direction it would work in. If host can attack the guest, but not vice versa, I \
usually don't care, because I usually run installer from such device, implying \
some trust…<br><br></div><blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div \
dir="ltr"><div>However, even on a system without an IOMMU, I would not say that we \
"already trust NetVMs," as there is still significant isolation provided by \
having it in a separate domain</div></div></blockquote><div><br>This is what I am not \
sure about. Maybe such attack would have to be slightly adapted for some type of the \
PCI device. But if you have a well-known device…<br><br>Regards,<br>VÃt Å esták \
'v6ak'<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/fb3acefd-d1ff-4462-b79b-5faf9b65f2 \
38%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/fb3acefd-d1ff-4462-b79b-5faf9b65f238%40googlegroups.com</a>.<br /> \
For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>
------=_Part_507_1652718489.1450718904228--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic