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]

Date:	Sat, 21 Oct 2006 00:39:40 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	David Miller <davem@...emloft.net>
CC:	ralf@...ux-mips.org, torvalds@...l.org, akpm@...l.org,
	linux-kernel@...r.kernel.org, anemo@....ocn.ne.jp
Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

David Miller wrote:
> From: Ralf Baechle <ralf@...ux-mips.org>
> Date: Thu, 19 Oct 2006 19:13:46 +0100
> 
> 
>>That would require changing the order of cache flush and tlb flush.
>>To keep certain architectures that require a valid translation in
>>the TLB the cacheflush has to be done first.  Not sure if those
>>architectures need a writeable mapping for dirty cachelines - I
>>think hypersparc was one of them.
> 
> 
> There just has to be "a mapping" in the TLB so that the L2 cache can
> translate the virtual address to a physical one for the writeback to
> main memory.

So moving the flush_cache_mm below the copy_page_range, to just
before the flush_tlb_mm, would work then? This would make the
race much smaller than with this patchset.

But doesn't that still leave a race?

What if another thread writes to cache after we have flushed it
but before flushing the TLBs? Although we've marked the the ptes
readonly, the CPU won't trap if the TLB is valid? There must be
some special way for the arch to handle this, but I can't see it.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/