linux-kernel - Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

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: <20061021004627.GA32044@linux-mips.org>
Date:	Sat, 21 Oct 2006 01:46:27 +0100
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Linus Torvalds <torvalds@...l.org>,
	David Miller <davem@...emloft.net>, akpm@...l.org,
	linux-kernel@...r.kernel.org, anemo@....ocn.ne.jp
Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

On Sat, Oct 21, 2006 at 02:47:56AM +1000, Nick Piggin wrote:

> >So maybe the COW D$ aliasing patch-series is just the right thing to do. 
> >Not worry about D$ at _all_ when doing the actual fork, and only worry 
> >about it on an actual COW event. Hmm?
> 
> Well if we have the calls in there, we should at least make them work
> right for the architectures there now. At the moment the flush_cache_mm
> before the copy_page_range wouldn't seem to do anything if you can still
> have threads dirty the cache again through existing TLB entries.

If you're talking about getting 2.6.19 out of the door without risking
too much wreckage, I'm all for it.

> I don't think that flushing on COW is exactly right though, because dirty
> data can remain invisible if you're only doing reads (no write, no flush).
> And if that cache gets written back at some point, you're going to see
> supposedly RO data change underneath you. I think?

You will not be able to avoid aliases at COW breaking time by any kind of
cache flush.  In a VIPT cache the userspace page is living at it's
userspace address but the current implemention of copy_user_page will
try to copy it at it's kernel space address and those two may not live
at the same cache index.

So, when breaking a COW mapping you have two options:

 1) copying involves touch a userspace mapped page at it's kernel address.
    This may result in an alias so apropriate cache flushing will be
    needed.  On a MIPS system this flush itself is like 1,000 cycles but
    could easily several times as much.  Add the cost of bringing all the
    data that was blown away from the cache back later on.
 2) try to be smart and avoid the creation of aliases by creating proper
    temporary aliases.  Creating and tearing down a TLB mapping is dirt
    cheap.

The current strategy is #1 which happens to work for MIPS because there
is at most an alias between clean lines which is harmless on MIPS but will
blow up on PA8800 - without overkill flushing.

It is possible to implement the common sequence of fork + exec such that
the child never ever breaks a COW page, not even a stack page.  So why
should a PIPT or VIPT cache be flushed in such a case?  We can do better
than that.

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