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: <20061231.014533.71091424.davem@davemloft.net>
Date:	Sun, 31 Dec 2006 01:45:33 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	miklos@...redi.hu
Cc:	rmk+lkml@....linux.org.uk, torvalds@...l.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	akpm@...l.org
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all
 that again

From: Miklos Szeredi <miklos@...redi.hu>
Date: Sun, 31 Dec 2006 10:10:35 +0100

> > Therefore, FUSE probably could have been fixed by judicious use
> > of copy_{to,from}_user_page() calls instead of adding this new
> > ad-hoc flush_anon_page() thing.
> 
> Probably, but I don't think either interface is perfect.
> copy_*_user_page() will double flush the user mapping
> (get_user_pages() already does a flush_dcache_page()).  Actually
> nothing except ptrace uses the copy_*_user_page() interface even
> though there are many uses of get_user_pages().
> 
> What I think get_user_pages() really needs is a single operation that
> 
>   - flushes the virtual address view
>   - flushes the kernel view
> 
> regardles whether the page is anonymous or file backed.

I guess part of the problem is that flush_dcache_page() could have
better defined semantics.

Sparc64 never notices this precisely because it can flush by physical
page and thus it can just do the flush on anonymous pages
synchronously very cheaply.

ARM probably avoids it because it would be very expensive since it
needs to flush by virtual address, so in the best case it would need
to walk the RMAP mapping list and hit every user mapping, then flush
again for the kernel side virtual address of the direct mapping to
that physical page too.

It is certainly the case that all of this stuff could be done in
a much cleaner manner.  Although it's really hard for me to get
excited by this and do the work since sparc64 already works :-)
-
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/