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:	Sat, 16 Nov 2013 14:06:30 -0800
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Simon Baatz <gmbnomis@...il.com>
Cc:	Helge Deller <deller@....de>, Benjamin LaHaise <bcrl@...ck.org>,
	linux-aio@...ck.org, linux-kernel@...r.kernel.org,
	linux-parisc@...r.kernel.org
Subject: Re: [PATCH] aio: fix D-cache aliasing issues

On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote:
> On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote:
> > On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote:
> > > When a user page mapping is released via kunmap*() functions, the D-cache needs
> > > to be flushed via flush_dcache_page() to avoid D-cache aliasing issues.
> > > 
> > > This patch fixes aio on the parisc platform (and probably others).
> > 
> > This should be flush_kernel_dcache_page().  flush_dcache_page() is for
> > full coherency but for unmap, we know the page was coherent going in and
> > may have been modified by the kernel, so only the kernel view needs to
> > be sync'd.  Technically, by the kernel API, the flush should be done
> > *before* unmapping.  This would have mattered on parisc until we did
> > flush via tmpalias which means we no-longer care if the mapping for the
> > flush exists or not because we always recreate it via the tmpalias
> > pages.
> 
> On ARM, flush_kernel_dcache_page() actually assumes that the page is
> mapped.  It avoids double flushing of highmem pages by not flushing
> in those cases where kunmap_atomic() already takes care of flushing.

On Parisc, kmap/kunmap is currently a nop.  However, if we ever
implemented highmem, we would also need to flush before we unmap, which
is why the flush needs to go before the kunmap.

I've got to say on all of this, we've implemented the most inane set of
primitives.  It would be much easier if kmap/kunmap just took care of
all of this.  kmap should bring userspace into coherence (because why
else would we be kmapping) and kunmap should force coherence on the
kernel address ... and then no-one would need to worry when to and when
not to flush.

James


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