linux-kernel - Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again

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: <E1GxTED-0000yy-00@dorka.pomaz.szeredi.hu>
Date:	Thu, 21 Dec 2006 20:05:17 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	rmk+lkml@....linux.org.uk
CC:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again

> > > > > > Yes, note the flush_dcache_page() call in fuse_copy_finish().  That
> > > > > > could be replaced by the flush_kernel_dcache_page() (added by James
> > > > > > Bottomley together with flush_anon_page()) when all relevant
> > > > > > architectures have defined it.
> > > > > 
> > > > > I should say that flush_anon_page() in its current form is going to be
> > > > > problematic for ARM.  It is passed:
> > > > > 
> > > > > 1. the struct page
> > > > > 2. the virtual address in process memory for the page
> > > > > 
> > > > > It is not passed the mm or vma.  This means that we have no idea whether
> > > > > the virtual address is in the currently mapped VM space or not.  The
> > > > > common use of get_area_pages() is to get pages from other address
> > > > > spaces.
> > > > 
> > > > I'm not sure I understand.  flush_anon_page() needs only to flush the
> > > > mapping for the given virtual address, no?
> > > 
> > > Yes, but that virtual /user/ address is meaningless without knowing
> > > which process address space it belongs to.
> > > 
> > > > It's always mapped at that address (since it was just accessed through
> > > > that).
> > > 
> > > No.  Consider ptrace() (invoked by gdb) reading data from another
> > > processes address space to obtain structure data or instructions.
> > > 
> > > > Any other mappings
> > > > of the anonymous page are irrelevant, they don't need to be flushed.
> > > 
> > > Again, incorrect.  Consider if the page you're accessing is a file-
> > > backed page, and is mapped into a process using a shared mapping.
> > > Because you've written to the file, those shared mappings need to see
> > > that write, and the interface for achieving that is flush_dcache_page().
> > > If not, data loss can occur.
> > 
> > Yes, for file backed pages.  But flush_anon_page() only needs to deal
> > with anonymous (not file backed) pages.
> 
> Ignore my final paragraph, it was clearly wrong; I was thinking about
> the flush after you've written to the page.
> 
> However, I continue to assert that I require the VMA to implement
> flush_anon_page() since a userspace address without knowing which
> userspace it corresponds with is utterly useless for cache maintainence
> purposes.

I understand now.  I'm not sure how the PARISC implementation can be
correct in this light.

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