Re: [qubes-users] Question on DMA attacks
On Saturday, July 16, 2016 at 12:17:31 AM UTC-4, raah...@gmail.com wrote:
> On Friday, July 15, 2016 at 7:22:44 PM UTC-4, Chris Laprise wrote:
> > On 07/15/2016 02:43 PM, Andrew David Wong wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > > On 2016-07-15 01:46, Marek Marczykowski-Górecki wrote:
> > >> On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote:
> > >>> From the user FAQ:
> > >>> https://www.qubes-os.org/doc/user-faq/#can-i-install-
> > >>> qubes-on-a-system-without-vt-d "an attacker could always use a simple
> > >>> DMA
> > >>> attack to go from the NetVM to Dom0"
> > >>> So what does this mean though..?
> > >>> Can they launch this DMA attack from a compromised App VM..?
> > >>> Could they simply do a browser exploit in an App VM, and then do a DMA
> > >>> attack from there to go to dom0..?
> > >>> Or is it a lot harder than that..?
> > >>> I'm just trying to work out whether it's really worth buying a new
> > >>> laptop
> > >>> just to get VT-D I currently have VT-X, but not VT-D.
> > >> DMA is mechanism for PCI devices to access system memory (read/write).
> > >> Without VT-d any PCI device can access all the memory, regardless to
> > >> which
> > >> VM is assigned (or left in dom0). Most PCI devices allow driver to
> > >> request
> > >> arbitrary DMA operation (like "put received network packets at this
> > >> address in memory", or "get this memory area and sent to the network").
> > >> So, without VT-d, it gives unlimited access to the whole system. Now, it
> > >> is only a matter of knowing where to read/write to take over the system,
> > >> instead of just crashing. But since you can read the whole memory, it
> > >> isn't that hard.
> > >>
> > >> Now, how it applies to Qubes OS? The above attack requires access to PCI
> > >> device. Which means that can be performed only from NetVM / UsbVM, so
> > >> someone must first break into one of those VMs. But it isn't that hard,
> > >> because there is a lot of complex code handling network traffic. Recent
> > >> bugs includes DHCP client, DNS client etc. Most of attacks on NetVM /
> > >> UsbVM
> > >> (but not all!) requires being somehow close to the target system - for
> > >> example connected to the same WiFi network, or in case of UsbVM, having
> > >> physical acccess to some USB port.
> > >>
> > >> But, just exploiting a browser in an AppVM isn't enough, as normal AppVM
> > >> do
> > >> not have any PCI device assigned (unless you do that manually).
> > >>
> > > Clear and lucid answer, as always. Thanks, Marek! Added to the FAQ:
> > >
> > > https://github.com/QubesOS/qubes-doc/commit/45cffd68543447c81d9922572d52e408b7ff
> > > 5e65
> > >
> >
> > IIRC, this point may be covered by Joanna's blog post re: 'What makes
> > Qubes different from ...?'
> >
> > The main website does sort of lack a concise rundown of Qubes' main
> > advantages, such as:
> >
> > * Simple and strong isolation mechanism, instead of complex permissions
> > in monolithic kernels
> > * Safe virtualization of software components that normally expose
> > regular hypervisors to exploits (i.e. graphics, copy+paste)
> > * Window manager that reliably reflects the security context of running apps
> > * Hardware virtualization of risky interfaces such as NICs and USB
> > * Overall philosophy of 'protect the core system and non-networked VMs';
> > remotely exploited VMs stay contained ('game over' situation unlikely)
> >
> > Plus secondary advantages:
> > * Template system
> > * Disposable VMs
> > * AEM
> > * Trusted document 'sanitizing'
> > * Flexible use of anon networks (Tor, etc.)
> >
> > Chris
>
> I think the op's real question was how would one go about compromising the
> network card in the first place to attempt a dma attack. IMO, that is too
> general question and he would have to google the many different methods.
> Noone is going to give him step by step instructions with there preferred
> method against qubes users. I gave example of reverse shell from exploiting
> fedora's dhclient, which was biggest issue of shell shock. Using ICMP
> packet to reverse shell,Marek gave example of packet to exploit DNS
> client. Only to name a few. The link in Joannas blog gave example of many
> diff methods of using dma attack after taking over the netcard with malicious
> packet. So many methods to take over the netcard and many methods on how to
> attempt dma attack afterwards to take over the whole system. Too many to
> list.
>
> To even say that he has to take Joannas word for it that dma attacks actually
> exist, and that he has never seen any poc's of these things actually being
> done I find suspicious. Because its a matter of a simple google search.
And sure most common methods are from lan, but imo we should assume all our
routers are compromised anyways, and all our iot devices and phones. And
Marek said it doesn't always have to be local attack!!! We should stress
Re: [qubes-users] Question on DMA attacks
On Friday, July 15, 2016 at 7:22:44 PM UTC-4, Chris Laprise wrote:
> On 07/15/2016 02:43 PM, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 2016-07-15 01:46, Marek Marczykowski-Górecki wrote:
> >> On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote:
> >>> From the user FAQ:
> >>> https://www.qubes-os.org/doc/user-faq/#can-i-install-
> >>> qubes-on-a-system-without-vt-d "an attacker could always use a simple DMA
> >>> attack to go from the NetVM to Dom0"
> >>> So what does this mean though..?
> >>> Can they launch this DMA attack from a compromised App VM..?
> >>> Could they simply do a browser exploit in an App VM, and then do a DMA
> >>> attack from there to go to dom0..?
> >>> Or is it a lot harder than that..?
> >>> I'm just trying to work out whether it's really worth buying a new laptop
> >>> just to get VT-D I currently have VT-X, but not VT-D.
> >> DMA is mechanism for PCI devices to access system memory (read/write).
> >> Without VT-d any PCI device can access all the memory, regardless to which
> >> VM is assigned (or left in dom0). Most PCI devices allow driver to
> >> request
> >> arbitrary DMA operation (like "put received network packets at this
> >> address in memory", or "get this memory area and sent to the network").
> >> So, without VT-d, it gives unlimited access to the whole system. Now, it
> >> is only a matter of knowing where to read/write to take over the system,
> >> instead of just crashing. But since you can read the whole memory, it
> >> isn't that hard.
> >>
> >> Now, how it applies to Qubes OS? The above attack requires access to PCI
> >> device. Which means that can be performed only from NetVM / UsbVM, so
> >> someone must first break into one of those VMs. But it isn't that hard,
> >> because there is a lot of complex code handling network traffic. Recent
> >> bugs includes DHCP client, DNS client etc. Most of attacks on NetVM / UsbVM
> >> (but not all!) requires being somehow close to the target system - for
> >> example connected to the same WiFi network, or in case of UsbVM, having
> >> physical acccess to some USB port.
> >>
> >> But, just exploiting a browser in an AppVM isn't enough, as normal AppVM do
> >> not have any PCI device assigned (unless you do that manually).
> >>
> > Clear and lucid answer, as always. Thanks, Marek! Added to the FAQ:
> >
> > https://github.com/QubesOS/qubes-doc/commit/45cffd68543447c81d9922572d52e408b7ff
> > 5e65
> >
>
> IIRC, this point may be covered by Joanna's blog post re: 'What makes
> Qubes different from ...?'
>
> The main website does sort of lack a concise rundown of Qubes' main
> advantages, such as:
>
> * Simple and strong isolation mechanism, instead of complex permissions
> in monolithic kernels
> * Safe virtualization of software components that normally expose
> regular hypervisors to exploits (i.e. graphics, copy+paste)
> * Window manager that reliably reflects the security context of running apps
> * Hardware virtualization of risky interfaces such as NICs and USB
> * Overall philosophy of 'protect the core system and non-networked VMs';
> remotely exploited VMs stay contained ('game over' situation unlikely)
>
> Plus secondary advantages:
> * Template system
> * Disposable VMs
> * AEM
> * Trusted document 'sanitizing'
> * Flexible use of anon networks (Tor, etc.)
>
> Chris
I think the op's real question was how would one go about compromising the
network card in the first place to attempt a dma attack. IMO, that is too
general question and he would have to google the many different methods. Noone
is going to give him step by step instructions with there preferred method
against qubes users. I gave example of reverse shell from exploiting fedora's
dhclient, which was biggest issue of shell shock. Using ICMP packet to
reverse shell,Marek gave example of packet to exploit DNS client. Only to
name a few. The link in Joannas blog gave example of many diff methods of
using dma attack after taking over the netcard with malicious packet. So many
methods to take over the netcard and many methods on how to attempt dma attack
afterwards to take over the whole system. Too many to list.
To even say that he has to take Joannas word for it that dma attacks actually
exist, and that he has never seen any poc's of these things actually being
done I find suspicious. Because its a matter of a simple google search.
--
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/bbfe0bde-ee72-44d4-8e80-3477dc2d4de5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question on DMA attacks
On 07/15/2016 02:43 PM, Andrew David Wong wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2016-07-15 01:46, Marek Marczykowski-Górecki wrote:
On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote:
From the user FAQ:
https://www.qubes-os.org/doc/user-faq/#can-i-install-
qubes-on-a-system-without-vt-d "an attacker could always use a simple DMA
attack to go from the NetVM to Dom0"
So what does this mean though..?
Can they launch this DMA attack from a compromised App VM..?
Could they simply do a browser exploit in an App VM, and then do a DMA
attack from there to go to dom0..?
Or is it a lot harder than that..?
I'm just trying to work out whether it's really worth buying a new laptop
just to get VT-D I currently have VT-X, but not VT-D.
DMA is mechanism for PCI devices to access system memory (read/write).
Without VT-d any PCI device can access all the memory, regardless to which
VM is assigned (or left in dom0). Most PCI devices allow driver to request
arbitrary DMA operation (like "put received network packets at this
address in memory", or "get this memory area and sent to the network").
So, without VT-d, it gives unlimited access to the whole system. Now, it
is only a matter of knowing where to read/write to take over the system,
instead of just crashing. But since you can read the whole memory, it
isn't that hard.
Now, how it applies to Qubes OS? The above attack requires access to PCI
device. Which means that can be performed only from NetVM / UsbVM, so
someone must first break into one of those VMs. But it isn't that hard,
because there is a lot of complex code handling network traffic. Recent
bugs includes DHCP client, DNS client etc. Most of attacks on NetVM / UsbVM
(but not all!) requires being somehow close to the target system - for
example connected to the same WiFi network, or in case of UsbVM, having
physical acccess to some USB port.
But, just exploiting a browser in an AppVM isn't enough, as normal AppVM do
not have any PCI device assigned (unless you do that manually).
Clear and lucid answer, as always. Thanks, Marek! Added to the FAQ:
https://github.com/QubesOS/qubes-doc/commit/45cffd68543447c81d9922572d52e408b7ff
5e65
IIRC, this point may be covered by Joanna's blog post re: 'What makes
Qubes different from ...?'
The main website does sort of lack a concise rundown of Qubes' main
advantages, such as:
* Simple and strong isolation mechanism, instead of complex permissions
in monolithic kernels
* Safe virtualization of software components that normally expose
regular hypervisors to exploits (i.e. graphics, copy+paste)
* Window manager that reliably reflects the security context of running apps
* Hardware virtualization of risky interfaces such as NICs and USB
* Overall philosophy of 'protect the core system and non-networked VMs';
remotely exploited VMs stay contained ('game over' situation unlikely)
Plus secondary advantages:
* Template system
* Disposable VMs
* AEM
* Trusted document 'sanitizing'
* Flexible use of anon networks (Tor, etc.)
Chris
--
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/af563412-101d-1ab2-f7e4-aa94d34712d7%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question on DMA attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-07-15 01:46, Marek Marczykowski-Górecki wrote: > On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote: >> From the user FAQ: > >> https://www.qubes-os.org/doc/user-faq/#can-i-install- >> qubes-on-a-system-without-vt-d "an attacker could always use a simple DMA >> attack to go from the NetVM to Dom0" > >> So what does this mean though..? > >> Can they launch this DMA attack from a compromised App VM..? > >> Could they simply do a browser exploit in an App VM, and then do a DMA >> attack from there to go to dom0..? > >> Or is it a lot harder than that..? > >> I'm just trying to work out whether it's really worth buying a new laptop >> just to get VT-D I currently have VT-X, but not VT-D. > > DMA is mechanism for PCI devices to access system memory (read/write). > Without VT-d any PCI device can access all the memory, regardless to which > VM is assigned (or left in dom0). Most PCI devices allow driver to request > arbitrary DMA operation (like "put received network packets at this > address in memory", or "get this memory area and sent to the network"). > So, without VT-d, it gives unlimited access to the whole system. Now, it > is only a matter of knowing where to read/write to take over the system, > instead of just crashing. But since you can read the whole memory, it > isn't that hard. > > Now, how it applies to Qubes OS? The above attack requires access to PCI > device. Which means that can be performed only from NetVM / UsbVM, so > someone must first break into one of those VMs. But it isn't that hard, > because there is a lot of complex code handling network traffic. Recent > bugs includes DHCP client, DNS client etc. Most of attacks on NetVM / UsbVM > (but not all!) requires being somehow close to the target system - for > example connected to the same WiFi network, or in case of UsbVM, having > physical acccess to some USB port. > > But, just exploiting a browser in an AppVM isn't enough, as normal AppVM do > not have any PCI device assigned (unless you do that manually). > Clear and lucid answer, as always. Thanks, Marek! Added to the FAQ: https://github.com/QubesOS/qubes-doc/commit/45cffd68543447c81d9922572d52e408b7ff 5e65 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXiS7OAAoJENtN07w5UDAwBTIQAK3BACGM/8ishjh08vqn6kwC IRV4/kTuLwqQAcsVDVdtTSf8TXPLjtoU6IDPfJOstDDoF3PkKZwvlV6YbFKx5e6e Ixb9ka928uVk0qHQbJvu8bIZJgBO4p/abM2cGCv9rX1ii/3rV0DiKfAs4MA+oNKK i3QumQMQs3wqU4uIIfk2DkEqpaPmPV+IkY2eD5JdxZowWKf8OoXmwhn1EowRXL62 XL78iT8OgmKM+Errc1bQqBl9OJ7b0l7pAiAZL3jIWpLMOU2qIcr5lCoqG9CwD9z+ YPd8s44ybJvoKpt+y0N/VajPFm/sFZPAIoz17pLJ6+oVJVVyiEuvu5qZNRK+OI7Z iXrHbv0paPSKvbmSkHQ2PJ+/vQKNw3/l474nj2Op6VhNfT+mO93glmP51au2yGMv 5vVJ/zKIn/+4Vl4OWaeMrkVfkpG4bzqYJyrwVusl392ZjeA9j5yairLSvqcKPVyU FO+RyG9v94U0o1ib479Buk7ga9VPst+J14BQeFCWRdnZID5SrmcH3oBPmaekTfas 856IFKAuGgosGuzwJcn1s2oJLkD2OFA1R3C6VwcQVYB6K+BpvAaYSrjhxRWeeeZH bI0nzOZL/6RKf++uYAkolHWC5r1862NBQEB3bOtYR1zHssL2DiDijmLDa0KE7brX oxk7rg2YM7ejVQEIOi4q =zG0v -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/fa1f5914-806a-df8f-0069-2154c896992d%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question on DMA attacks
On Friday, July 15, 2016 at 11:20:43 AM UTC-4, neilh...@gmail.com wrote: > Wow.. Thanks Marek... That was a very clear explanation of DMA attacks... The > best that I've ever seen. > > Perhaps this should even be posted somewhere on the QUBES website. > > I think that's convinced me that I definitely need to get VT-D. lol https://www.google.com/webhp?sourceid=chrome-instant=1=2=UTF-8#q=what+is+a+dma+attack -- 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/e9c56616-811a-4451-be4c-2cd011203f0c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question on DMA attacks
Wow.. Thanks Marek... That was a very clear explanation of DMA attacks... The best that I've ever seen. Perhaps this should even be posted somewhere on the QUBES website. I think that's convinced me that I definitely need to get VT-D. -- 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/f0d29dbd-cd47-4191-9048-c4ce0699ce23%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question on DMA attacks
On 07/15/2016 08:46 AM, Marek Marczykowski-GĂłrecki wrote: > > On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote: >> From the user FAQ: >> >> https://www.qubes-os.org/doc/user-faq/#can-i-install-qubes-on-a-system-without-vt-d >> >> "an attacker could always use a simple DMA attack to go from the NetVM to >> Dom0" >> >> So what does this mean though..? >> >> Can they launch this DMA attack from a compromised App VM..? >> >> Could they simply do a browser exploit in an App VM, and then do a DMA >> attack from there to go to dom0..? >> >> Or is it a lot harder than that..? >> >> I'm just trying to work out whether it's really worth buying a new laptop >> just to get VT-D I currently have VT-X, but not VT-D. > DMA is mechanism for PCI devices to access system memory (read/write). > Without VT-d any PCI device can access all the memory, regardless to > which VM is assigned (or left in dom0). Most PCI devices allow driver to > request arbitrary DMA operation (like "put received network packets at > this address in memory", or "get this memory area and sent to the > network"). So, without VT-d, it gives unlimited access to the whole > system. Now, it is only a matter of knowing where to read/write to take > over the system, instead of just crashing. But since you can read the > whole memory, it isn't that hard. > > Now, how it applies to Qubes OS? The above attack requires access to PCI > device. Which means that can be performed only from NetVM / UsbVM, so > someone must first break into one of those VMs. But it isn't that hard, > because there is a lot of complex code handling network traffic. Recent > bugs includes DHCP client, DNS client etc. Most of attacks on NetVM / > UsbVM (but not all!) requires being somehow close to the target system - > for example connected to the same WiFi network, or in case of UsbVM, > having physical acccess to some USB port. > > But, just exploiting a browser in an AppVM isn't enough, as normal AppVM > do not have any PCI device assigned (unless you do that manually). > Thank you for this overview! I'm still on R2.1, as VT-d on 3.x seems to fail on my Lenovo box. (BTW, Lenovo has indicated that BIOS updates are forthcoming). I'm presuming that VT-d is important enough (I occasionally use open hotspots) that I'm best off keeping it and 2.1, foregoing any Qubes/XEN updates to 3.x (I'm keeping application software up to date outside of YUM). So the question becomes, is my reasoning valid? Are there any 2.1 issues that indicate I should upgrade to 3.x without VT-d? Thanks in Advance -- 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/5788e847.0435c80a.b917c.367b%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Question on DMA attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote: > From the user FAQ: > > https://www.qubes-os.org/doc/user-faq/#can-i-install-qubes-on-a-system-without-vt-d > > "an attacker could always use a simple DMA attack to go from the NetVM to > Dom0" > > So what does this mean though..? > > Can they launch this DMA attack from a compromised App VM..? > > Could they simply do a browser exploit in an App VM, and then do a DMA attack > from there to go to dom0..? > > Or is it a lot harder than that..? > > I'm just trying to work out whether it's really worth buying a new laptop > just to get VT-D I currently have VT-X, but not VT-D. DMA is mechanism for PCI devices to access system memory (read/write). Without VT-d any PCI device can access all the memory, regardless to which VM is assigned (or left in dom0). Most PCI devices allow driver to request arbitrary DMA operation (like "put received network packets at this address in memory", or "get this memory area and sent to the network"). So, without VT-d, it gives unlimited access to the whole system. Now, it is only a matter of knowing where to read/write to take over the system, instead of just crashing. But since you can read the whole memory, it isn't that hard. Now, how it applies to Qubes OS? The above attack requires access to PCI device. Which means that can be performed only from NetVM / UsbVM, so someone must first break into one of those VMs. But it isn't that hard, because there is a lot of complex code handling network traffic. Recent bugs includes DHCP client, DNS client etc. Most of attacks on NetVM / UsbVM (but not all!) requires being somehow close to the target system - for example connected to the same WiFi network, or in case of UsbVM, having physical acccess to some USB port. But, just exploiting a browser in an AppVM isn't enough, as normal AppVM do not have any PCI device assigned (unless you do that manually). - -- 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 iQEcBAEBCAAGBQJXiKLfAAoJENuP0xzK19cs21wH/A1AOVEKZLAr/p1/rY3gOCzJ r8qVwL8bl9sEq/WmkDAbml/wxyLBCd46bqvUD645V0FtqHIkluikIGaPUH+tNwxu PnE/3xw5tAqIvl73GJ8Eon0V12Bt9e0CJa2GhbQ67ahdj12CR3Gg4IrbSoswNYpT qK4WiIBA6UhuERx02dVvA1Hd1kEcOHvTmYTn0W1gDmiFughXM8okf44bU3PHatU/ PFGqEMc/HkWgAPb+0VAUtRoem0NdJVKUa3XGgV5KrkbxeAhSj7VMy+lD/MxSdEQE Mep+XT6I16ItBVBEq1eOEMAJxJe0YnR5/TLfKHt7rBAZmziArAUb9LKw00pV1Pc= =aQzl -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/20160715084623.GL19103%40mail-itl. For more options, visit https://groups.google.com/d/optout.
