Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qubes Air: Generalizing the Qubes Architecture

qubes-os.org

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Qubes Air: Generalizing the Qubes Architecture

#41

Post by gmueckl »

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

GPUs can definitely write to host memory. In some situations, this is the only way to the results of some operations that the GPU performed (e.g. grab framebuffer for screenshots or video recordings). Usually, it's the job of the driver to check for illegal copy target addresses.

Re: Qubes Air: Generalizing the Qubes Architecture

#42

Post by blattimwind »

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.

Which is basically what Qubes "Convert to trusted PDF" does.

Re: Qubes Air: Generalizing the Qubes Architecture

#43

Post by nickpsecurity »

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.

My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. This might even be batched on simple hardware which itself has lower attack surface. Later on secure hardware like CHERI CPU albeit that can happen today if you have FPGA board and skills to run their HDL code.

For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right? ;) It might also be run back through similarly-deprivileged OCR to turn into a safer format. Gotta eyeball it if doing it that way. That said, there are fonts that work well with OCR that it might be converted to as part of image production if OCR is the goal in the first place.

Could be a fun, little project teaching folks about a number of topics at once.

Re: Qubes Air: Generalizing the Qubes Architecture

#44

Post by tptacek »

nickpsecurity wrote: post #43
dhimes wrote: post #36

Earlier quoted context omitted.

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

My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

Your "first solution" would be to take a de novo PDF implementation written in C, "compile it with something that makes it memory-safe", and then port it to an L4 microkernel. Maybe bust out some HDL and get parts of it deployed directly on to FPGA.

Got it.

Re: Qubes Air: Generalizing the Qubes Architecture

#45

Post by ecesena »

kakarot wrote: post #18
ecesena wrote: post #14

Earlier quoted context omitted.

For the cloud, it would be an incentive to run the nodes, and you’d pay for the resource you’re using. I’m not saying they should, Im saying it could be a good startup or, in this case, a good model for a blockchain-based company.

I think the idea is you just buck up and pay the cloud fees. If you follow Qubes / ITL, you would know that they are hardly a "startup" as a decade-old company, and they have been experimenting with enterprise-level support. If they can find a home in the enterprise market, it will at least give them enough cashflow to continue developing Qubes for the foreseeable future. Besides, I imagine Joanna Rutkowska's opinion…

I don’t know how to write it better. I never said Qubes should change their biz model or do an ICO. Full stop.

All I said is that their product would be great in the hands of a startup that focuses on a single hardware platform and does more marketing, and/or does an ico because I see a great incentive to run nodes of the cloud (because qubes utself provides all the building block for trust).

> If you follow Qubes I do, since 2010, when I was doing very similar research on trusted cloud computing.

> If they can find a home in the enterprise market I wish it to them, but this doesn’t mean someone else can try a more aggressive consumer route, or an alternative for their cloud model.

I respect a ton their work, and as I said in my very first comment I think they should focus on the research part, and someone else could provide capital and grow the consumer product.

Re: Qubes Air: Generalizing the Qubes Architecture

#46

Post by blattimwind »

nickpsecurity wrote: post #43
dhimes wrote: post #36

Earlier quoted context omitted.

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

My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

> For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right?

Which is literally what Qubes "Convert to trusted PDF" does.

> My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy.

It would of course be preferable to have a secure PDF reader to begin with, but the complexities of the PDF format doesn't isn't really conducive to that.

Re: Qubes Air: Generalizing the Qubes Architecture

#47

Post by blattimwind »

rectang wrote: post #29
Cthulhu_ wrote: post #26

Earlier quoted context omitted.

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.

One reason: the prospect of an endless stream of unpatchable Spectre-like hardware vulnerabilities. The "real problem" exposed by Meltdown and Spectre is running untrusted software on the same hardware where sensitive information resides. Moving away from physical coupling defends against potential sidechannel attacks. The Qubes approach of "careful decomposition of various workflows, devices, apps across securely co…

> The "real problem" exposed by Meltdown and Spectre is running untrusted software on the same hardware where sensitive information resides.

Well obviously. Which is why people try to avoid that as much as they can when they are handling actually sensitive information.

> Moving away from physical coupling defends against potential sidechannel attacks.

... is a correct deduction, but using cloud VMs hardly qualifies as following the principle (except if they are only used for lowest-privilege stuff, but even then, the system now requires connectivity). Now you don't know who else is on your hardware, and you don't even control the hardware in the first place.

Re: Qubes Air: Generalizing the Qubes Architecture

#48

Post by blattimwind »

kakarot wrote: post #17
mtgx wrote: post #15

Earlier quoted context omitted.

To start, only because it's the best model to fund an open source project, ever? Of course they'd also have to pick their launch during a bull market, because nobody cares about ICOs in a bear market. If there's one innovation the "blockchain" has brought, is extreme liquidity and high funding potential for any type of startup, including open source projects that wouldn't even be considered by VCs ever, or they'd hav…

Ok, I'll bite. You're begging the question, Why is it the best model to fund an open source project, ever? And don't list "extreme liquidity" as a reason.

Given trade volumes, cryptocurrencies are not very liquid at all.

Re: Qubes Air: Generalizing the Qubes Architecture

#49

Post by jstewartmobile »

qplex wrote: post #32

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.

Amen. Huge silver lining to Meltdown has been raised awareness over what a mess our hardware is.

As long as we're in Intel x86 land, the Plan 9 service-per-box approach is probably about the best we can do, and I'm not saying that with any joy, or as an endorsement.

Or, perhaps we can claw our way back to the 1960s and reclaim working memory protection? As obvious as that sounds, I wouldn't take it for granted. People already accept all sorts of half-broken proprietary bullshit for GPU performance, bootloading, AMT, etc. From the mailing lists, looks like Intel is trying to normalize that for CPUs as well.

Re: Qubes Air: Generalizing the Qubes Architecture

#50

Post by transpute »

With the Qubes Air architecture, the unpopular Intel ME/AMT could be repurposed as a VNC server for web browsing on a dedicated device, e.g. old laptop. The AMT VNC client could be run in a thin Qubes VM. This would isolate the web browser (main x86 CPU), VNC server (Intel ME cpu) and VNC client (Qubes device CPU) on three physical processors. Usability would depend on performance of the AMT VNC server.
Post reply on HN