Qubes Air: Generalizing the Qubes Architecture • Hacker News Board

Re: Qubes Air: Generalizing the Qubes Architecture

#31

Post by kakarot » Mon, Jan 29, 2018, 12:05 PM UTC

eptcyka wrote: post #25

kakarot wrote: post #19

This was an awesome read. These guys are doing some of the most groundbreaking work in computing right now. The idea of having an "operating system" made up of components dispersed across the globe seems like a fantasy that is too good to be true. If Qubes can finally provide a method for passing through NVIDIA GPUs with this kind of architecture, Xen or not, that would be incredible. It's the only reason I had to le…

Passing through GPUs is problematic, as it's a massive attack surface.

It's unavoidable for me.

It provides no drawback for users who don't utilize it, and the alternative is me remaining with KVM which is a vastly larger attack surface, so your argument defeats itself.

Re: Qubes Air: Generalizing the Qubes Architecture

#32

Post by qplex » Mon, Jan 29, 2018, 12:05 PM UTC

Qubes runs mostly on computers with Intel CPUs.

It's good of them to admit that the layers-upon-layers approach just doesn't bring in any additional security if you have buggy/unsecure hardware.

Re: Qubes Air: Generalizing the Qubes Architecture

#33

Post by kakarot » Mon, Jan 29, 2018, 12:05 PM UTC

Cthulhu_ wrote: post #26

kakarot wrote: post #19

This was an awesome read. These guys are doing some of the most groundbreaking work in computing right now. The idea of having an "operating system" made up of components dispersed across the globe seems like a fantasy that is too good to be true. If Qubes can finally provide a method for passing through NVIDIA GPUs with this kind of architecture, Xen or not, that would be incredible. It's the only reason I had to le…

Why would you want something like that though? What are the benefits that are worth the huge amount of overhead of having to pass through the internet to connect components? I mean I get cloud computing and such, but this seems to be aimed as a consumer OS, which is very sensitive to delays and whatnot.

Qubes aims to provide both consumer and enterprise workflows, and everything in between. People use computers for all sorts of things. A full Qubes system delivered to a tablet/phone interface is also a fine tradeoff for millisecond GUI delays.

Re: Qubes Air: Generalizing the Qubes Architecture

#34

Post by pjc50 » Mon, Jan 29, 2018, 12:13 PM UTC

effie wrote: post #28

eptcyka wrote: post #25

Earlier quoted context omitted.

Passing through GPUs is problematic, as it's a massive attack surface.

Could you elaborate on the 'massive'? Let's say you let the VM see the GPU. What kind of attack would that enable? Let's suppose that a virus inside VM manipulates GPU outside of what applications are allowed to do. What worst thing could happen?

The GPU is a PCIe/AGP "bus master", so it can usually initiate DMA transfers from host memory and read anything it likes. IOMMU blocks some of this, but is not a perfect defence. https://security.stackexchange.com/questions/150386/does-iom...

Re: Qubes Air: Generalizing the Qubes Architecture

#35

Post by effie » Mon, Jan 29, 2018, 12:39 PM UTC

pjc50 wrote: post #34

effie wrote: post #28

Earlier quoted context omitted.

Could you elaborate on the 'massive'? Let's say you let the VM see the GPU. What kind of attack would that enable? Let's suppose that a virus inside VM manipulates GPU outside of what applications are allowed to do. What worst thing could happen?

The GPU is a PCIe/AGP "bus master", so it can usually initiate DMA transfers from host memory and read anything it likes. IOMMU blocks some of this, but is not a perfect defence. https://security.stackexchange.com/questions/150386/does-iom...

Thanks, according to [1], it seems DMA is quite a 'backdoor', bypassing any memory management the kernel would do. But it is not clear to me whether this allows the attacker inside VM also to write into the forbidden regions of memory and thus either modify behaviour of the hypervisor or send information out via Internet.

[1] https://en.wikipedia.org/wiki/DMA_attack

Re: Qubes Air: Generalizing the Qubes Architecture

#36

Post by dhimes » Mon, Jan 29, 2018, 12:47 PM UTC

blattimwind wrote: post #23

viraptor wrote: post #20

Earlier quoted context omitted.

Have you considered a jailed pdf reader application instead? I'm curious what the decision factors were important for you.

So everyone downstream of weinzierl has to be aware that (1) the PDFs he hands them may be full of malware (2) have to use VMs (3) must open said malware-packed PDFs in a disposable VM (4) must strictly adhere to D-VM usage protocol.

Or weinzierl could print them and possibly rescan for further distribution.

Re: Qubes Air: Generalizing the Qubes Architecture

#37

Post by kakarot » Mon, Jan 29, 2018, 12:58 PM UTC

effie wrote: post #35

pjc50 wrote: post #34

Earlier quoted context omitted.

The GPU is a PCIe/AGP "bus master", so it can usually initiate DMA transfers from host memory and read anything it likes. IOMMU blocks some of this, but is not a perfect defence. https://security.stackexchange.com/questions/150386/does-iom...

Thanks, according to [1], it seems DMA is quite a 'backdoor', bypassing any memory management the kernel would do. But it is not clear to me whether this allows the attacker inside VM also to write into the forbidden regions of memory and thus either modify behaviour of the hypervisor or send information out via Internet. [1] https://en.wikipedia.org/wiki/DMA_attack

The primary objective would be exfiltration, executive control is only secondary. If you can exfiltrate keys or hashes then you might not even need to use DMA to gain access to a system.

Re: Qubes Air: Generalizing the Qubes Architecture

#38

Post by secfirstmd » Mon, Jan 29, 2018, 1:00 PM UTC

jeditobe wrote: post #24

xvilka wrote: post #8

Wonder about their progress of integration[1] with ReactOS. [1] https://github.com/QubesOS/qubes-issues/issues/2809

Me too

That would be amazing...especially for helping transition people who feel uncomfortable with Linux type environments.

Re: Qubes Air: Generalizing the Qubes Architecture

#39

Post by cyberpunk0 » Mon, Jan 29, 2018, 1:12 PM UTC

ecesena wrote: post #3

Qubes would make for a great startup and, given the time, prob a very successful ICO. I was positively and at the same time negatively surprised reading about the 30k users. All issues/obstacles reported don’t seem so unachievable if one can imagine to focus on one specific hardware platform and with a good marketing team. I understand this is beyond a research project, but it would make for a great startup.

At the same time I don't want such a project anywhere near shady investors and founders seeking bro get rich and destroy the company like most start ups

Re: Qubes Air: Generalizing the Qubes Architecture

#40

Post by JulianMorrison » Mon, Jan 29, 2018, 1:21 PM UTC

dhimes wrote: post #36

blattimwind wrote: post #23

Earlier quoted context omitted.

So everyone downstream of weinzierl has to be aware that (1) the PDFs he hands them may be full of malware (2) have to use VMs (3) must open said malware-packed PDFs in a disposable VM (4) must strictly adhere to D-VM usage protocol.

Or weinzierl could print them and possibly rescan for further distribution.

Convert to DjVu.