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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1383733369.26213.45.camel@kazak.uk.xensource.com>
Date:	Wed, 6 Nov 2013 10:22:49 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	Matt Wilson <msw@...ux.com>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	<linux-kernel@...r.kernel.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Matt Wilson <msw@...zon.com>, <xen-devel@...ts.xen.org>
Subject: Re: [Xen-devel] [PATCH] grant-table: don't set m2p override if
 kmap_ops is not set

On Tue, 2013-11-05 at 12:53 -0800, Anthony Liguori wrote:
> >> Yes, you are completely right, then I have to figure out why blkback
> >> works fine with this patch applied (or at least it seems to work fine).
> >
> > blkback also works for me when testing a similar patch. I'm still
> > confused. One thing with your proposed patch: I'm not sure that you're
> > putting back the correct mfn.

As long as it is unique and owned by the local domain I guess it doesn't
matter which mfn goes back? It's going to get given back to the generic
allocator so the content is irrelevant? (all speculation without looking
at blkback)

> It's perfectly fine to store a foreign pfn in the m2p table.

No, it's not. The m2p is host global and maps mfns to the pfns in the
owning domain. A domain which grant maps a foreign mfn into its address
space doesn't get to update the m2p for that mfn. Perhaps you were
thinking of the p2m?

Depending on how an OS mapping the foreign MFN does things it may well
be accurate to say that having a foreign pfn in the m2p table is
harmless, in as much as it will never try and use the m2p for foreign
pages for anything real, but it depends on the implementation of the
particular OS.

>   The m2p
> override table is used by the grant device to allow a reverse lookup of
> the real mfn to a pfn even if it's foreign.

Classic Xen used an array of struct page * overrides in the struct vma
for this sort of use case (e.g. in blktap). That obviously cannot fly
for pvops...

Ian.

--
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