linux-kernel - Re: [patch] mm: fix a race condition under SMC + COW

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: <20060927.155442.71092068.davem@davemloft.net>
Date:	Wed, 27 Sep 2006 15:54:42 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	suresh.b.siddha@...el.com
Cc:	akpm@...l.org, hugh@...itas.com, linux-kernel@...r.kernel.org,
	asit.k.mallick@...el.com
Subject: Re: [patch] mm: fix a race condition under SMC + COW

From: "Siddha, Suresh B" <suresh.b.siddha@...el.com>
Date: Wed, 27 Sep 2006 15:15:07 -0700

> From: "Siddha, Suresh B" <suresh.b.siddha@...el.com>
> 
> Failing context is a multi threaded process context and the failing
> sequence is as follows.
> 
> One thread T0 doing self modifying code on page X on processor P0 and
> another thread T1 doing COW (breaking the COW setup as part of just happened
> fork() in another thread T2) on the same page X on processor P1. T0 doing SMC
> can endup modifying  the new page Y (allocated by the T1 doing COW on P1) but
> because of different I/D TLB's, P0 ITLB will not see the new mapping till
> the flush TLB IPI from  P1 is received. During this interval, if T0 executes
> the code created by SMC it can result in an app error (as ITLB still points to
> old page X and endup executing the content in page X rather than using
> the content in page Y).
> 
> Fix this issue by first clearing the PTE and flushing it, before updating it
> with new entry.
> 
> Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>

You can't really do a set_pte_at() in this code path because
there isn't a subsequent flush_tlb_*().

This is needed because some architectures queue up all set_pte_at()
calls until the next flush_tlb_*() in order to batch TLB flushes.
PowerPC and Sparc64 both do this.

The pte_establish() in the existing code works fine because it takes
care of the set_pte_at() and flush_tlb_*() work internally when
necessary on a given platform.

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