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
| ||
|
Message-ID: <4712BB05.1020701@goop.org> Date: Sun, 14 Oct 2007 17:57:41 -0700 From: Jeremy Fitzhardinge <jeremy@...p.org> To: Nick Piggin <nickpiggin@...oo.com.au> CC: David Chinner <dgc@....com>, xfs@....sgi.com, Xen-devel <xen-devel@...ts.xensource.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Mark Williamson <mark.williamson@...cam.ac.uk>, Morten Bøgeskov <xen-users@...ten.bogeskov.dk>, xfs-masters@....sgi.com Subject: Re: Interaction between Xen and XFS: stray RW mappings Nick Piggin wrote: > Yes, as Dave said, vmap (more specifically: vunmap) is very expensive > because it generally has to invalidate TLBs on all CPUs. > I see. > I'm looking at some more general solutions to this (already have some > batching / lazy unmapping that replaces the XFS specific one), however > they are still likely going to leave vmap mappings around after freeing > the page. > Hm. Could there be a call to shoot down any lazy mappings of a page, so the Xen pagetable code could use it on any pagetable page? Ideally one that could be used on any page, but only causes expensive operations where needed. > We _could_ hold on to the pages as well, but that's pretty inefficient. > The memory cost of keeping the mappings around tends to be well under > 1% the cost of the page itself. OTOH we could also avoid lazy flushes > on architectures where it is not costly. Either way, it probably would > require an arch hook or even a couple of ifdefs in mm/vmalloc.c for > Xen. Although... it would be nice if Xen could take advantage of some > of these optimisations as well. > In general the lazy unmappings won't worry Xen. It's only for the specific case of allocating memory for pagetables. Xen can do a bit of extra optimisation for cross-cpu tlb flushes (if the target vcpus are not currently running, then you don't need to do anything), but they're still an expensive operation, so the optimisation is definitely useful. > What's the actual problem for Xen? Anything that can be changed? > Not easily. Xen doesn't use shadow pagetables. Instead, it gives the guest domains direct access to the real CPU's pagetable, but makes sure they're always mapped RO so that the hypervisor can control updates to the pagetables (either by trapping writes or via explicit hypercalls). This means that when constructing a new pagetable, Xen will verify that all the mappings of pages making up the new pagetable are RO before allowing it to be used. If there are stray RW mappings of those pages, pagetable construction will fail. Aside from XFS, the only other case I've found where there could be stray RW mappings is when using high pages which are still in the kmap cache; I added an explicit call to flush the kmap cache to handle this. If vmap and kmap can be unified (at least the lazy unmap aspects of them), then that would be a nice little cleanup. J - 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