linux-kernel - Re: [PATCH 3/4] add replace_page(): change the page pte is pointing to.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090415112511.GH9809@random.random>
Date:	Wed, 15 Apr 2009 13:25:11 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Izik Eidus <ieidus@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, linux-mm@...ck.org, avi@...hat.com,
	chrisw@...hat.com, mtosatti@...hat.com, hugh@...itas.com,
	kamezawa.hiroyu@...fujitsu.com
Subject: Re: [PATCH 3/4] add replace_page(): change the page pte is
	pointing to.

On Tue, Apr 14, 2009 at 03:09:25PM -0700, Andrew Morton wrote:
> On Thu,  9 Apr 2009 06:58:40 +0300
> Izik Eidus <ieidus@...hat.com> wrote:
> 
> > replace_page() allow changing the mapping of pte from one physical page
> > into diffrent physical page.
> 
> At a high level, this is very similar to what page migration does.  Yet
> this implementation shares nothing with the page migration code.
> 
> Can this situation be improved?

This was discussed last time too. Basically the thing is that using
migration entry with its special page fault paths, for this looks a
bit of an overkill complexity and unnecessary dependency on the
migration code. All we need is to mark the pte readonly. replace_page
is a no brainer then. The brainer part is page_wrprotect
(page_wrprotect is like fork).

The data visibility in the final memcmp you mentioned in the other
mail is supposedly taken care of by page_wrprotect too. It already
does flush_cache_page for the virtual indexed and not physically
tagged caches. page_wrprotect has to also IPI all CPUs to nuke any not
wrprotected tlb entry. I don't think we need further smp memory
barriers when we're guaranteed all tlb entries are wrprotected in the
other cpus and an IPI and invlpg run in them, to be sure we read the
data stable during memcmp even if we read through the kernel
pagetables and the last userland write happened through userland ptes
before they become effective wrprotected by the IPI.
--
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/