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: <20061230224604.GA3350@flint.arm.linux.org.uk>
Date:	Sat, 30 Dec 2006 22:46:04 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Miklos Szeredi <miklos@...redi.hu>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again

On Sat, Dec 30, 2006 at 10:26:20AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 30 Dec 2006, Russell King wrote:
> > 
> > And here's the flush_anon_page() part.
> > 
> > Add flush_anon_page() for ARM, to avoid data corruption issues when using
> > fuse or other subsystems using get_user_pages().
> 
> Btw, since this doesn't actually change any code for anybody but ARM, just 
> adds a parameter that is obviously unused by everybody else, and if it 
> actually fixes a real bug for ARM, I'll obviously happily take it even 
> before 2.6.20. So go ahead put it in your ARM tree, and we'll get some 
> testing through that. And just ask me to pull at some point.
> 
> I wonder why nobody else seems to have a "flush_anon_page()"? This would 
> seem to be a potential issue for architectures like sparc too.. Although 
> maybe sparc can do a flush by physical index with "flush_dcache_page()".

Well...

iirc, flush_anon_page() was introduced to fix non-working fuse on parisc,
which occurs because fuse wants to use get_user_pages() to read data from
the current processes memory space.

get_user_pages() contains a call to flush_dcache_page(), whose behaviour
is defined for shared mappings.  Anonymous pages are unspecified.  It
appears that flush_anon_page() was introduced to correct this oversight.

Looking at some of the other users of get_user_pages() which want to
access the current processes memory space, one finds the following:

some use flush_cache_page():
- binfmt_elf coredump
- ptrace (in arch code)

others don't:
- aio
- bio
- block (block_dev::blk_get_page seems to be for direct-io, there's problems
   reported with this on ARM)
- direct-io
- fuse
- vmsplice

So, anything except coredumps and ptrace are currently unsafe on ARM
without something being added to get_user_pages() to ensure coherency
of anonymous pages.

Given that we have reported corruption with direct-io, and debian bug
#402876 for nonworking fuse, it seems the correct thing to do is to
implement this function.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/