lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100623163223.GA4255@phenom.dumpdata.com>
Date:	Wed, 23 Jun 2010 12:32:23 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Alex Williamson <alex.williamson@...hat.com>, ebiederm@...ssion.com
Cc:	linux-kernel@...r.kernel.org, fujita.tomonori@....ntt.co.jp,
	iommu@...ts.linux-foundation.org, albert_herranz@...oo.es,
	x86@...nel.org, Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH] Xen-SWIOTBL v0.8.3 used for Xen PCI pass through for PV
 guests.

> > The end user of this is the Xen PCI frontend and Xen PCI [1] which
> > require a DMA API "backend" that understands Xen's MMU. This allows the
> > PV domains to use PCI devices.
> 
> Hi Konrad,

Hey Alex,

Congratulations on your new job at Red Hat!
> 
> Sorry if I missed it, but I didn't see any mention or apparent
> requirement of a hardware iommu in xen for this code.  Is that true?  If

Ah, I completely missed to put that in the writeup (and as well some
other things that I thought off overnight). The answer is: both.

You can run this without an IOMMU in which case the security threat you
mentioned is feasible. Or you can run with an hardware IOMMU, if you
pass in the iommu=pv argument to the Xen hypervisor.

> so, is there anything to stop a PV guest with ownership of a DMA capable
> PCI device from reading all sorts of memory that the domain wouldn't
> otherwise have access to?  I was under the impression that the old PCI
> front/back for PV guests was mainly an interesting hack with limited
> applications due to security.  Thanks,

I thought as well but it looks as many folks are using it. The other
thing that I forgot to mention in the writeup are these two other use cases:

 1) One of them is the privileged PV (PPV?) domain drivers. This
    idea came about a year ago and was suggested on LKML by Eric
    Biederman. I can't find the link to it thought. Eric,
    would you by any chance remember it?

    The idea is to have multiple PPV domains which serve specific
    device drivers. An implementation using the hardware IOMMU is the
    Qubes OS (http://quebes-os.org), while this would be the same but
    using PV guests.

 2) Xen Dom0 support. Without the SWIOTLB-Xen patchset Dom0 is incapable
    of working with PCI devices.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ