linux-kernel - Re: Interaction between Xen and XFS: stray RW mappings

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]

Date:	Mon, 22 Oct 2007 17:16:03 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	David Chinner <dgc@....com>, Jeremy Fitzhardinge <jeremy@...p.org>,
	dean gaudet <dean@...tic.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Xen-devel <xen-devel@...ts.xensource.com>, Morten@...e.de,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bøgeskov <xen-users@...ten.bogeskov.dk>,
	xfs@....sgi.com, xfs-masters@....sgi.com,
	Mark Williamson <mark.williamson@...cam.ac.uk>
Subject: Re: Interaction between Xen and XFS: stray RW mappings

On Tue, 2007-10-23 at 01:35 +0200, Andi Kleen wrote:
> On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote:
> > On Mon, Oct 22, 2007 at 09:07:40PM +0200, Andi Kleen wrote:
> > > On Mon, Oct 22, 2007 at 11:40:52AM -0700, Jeremy Fitzhardinge wrote:
> > > > Andi Kleen wrote:
> > > > > Jeremy Fitzhardinge <jeremy@...p.org> writes:
> > > > >   
> > > > >> Yes, that's precisely the problem.  xfs does delay the unmap, leaving
> > > > >> stray mappings, which upsets Xen.
> > > > >>     
> > > > >
> > > > > Again it not just upsets Xen, keeping mappings to freed pages is wrong generally 
> > > > > and violates the x86 (and likely others like PPC) architecture because it can 
> > > > > cause illegal caching attribute aliases.

It is a serious offense to leave stray mappings for memory which can get
re-mapped to I/O devices... especially with PCI and other device
hotplug.  I have to back up Andi on this one unconditionally.

On architectures where you have multibyte, non-wordsize updates to
hardware page tables, you even have races here when setting, updating
and clearing PTEs that must be done in a sequence where no aliasing of
mappings to partially written PTEs can result in I/O memory getting
mapped in a cacheable state.  The window here is only one instruction,
and yes, it is possible for a window this small to create a problem.  A
large (or permanently lazy) window is extremely frightening.

These things do cause bugs.  The bugs take a very long time to show up
and are very difficult to track down, since they can basically cause
random behavior, such as hanging the machine or losing orbit and
crashing into the moon.

Zach

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