linux-kernel - Re: race with page_referenced_one->ptep_test_and_clear

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: <4705B8CA.5070608@goop.org>
Date:	Thu, 04 Oct 2007 21:08:42 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Hugh Dickens <hugh@...itas.com>,
	David Rientjes <rientjes@...gle.com>,
	Zachary Amsden <zach@...are.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Keir Fraser <keir@...source.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: race with page_referenced_one->ptep_test_and_clear_young and
 pagetable setup/pulldown

Andrew Morton wrote:
> y'know, I think I think it's been several years since I saw a report of an
> honest to goodness, genuine SMP race in core kernel.  We used to be
> infested by them, but the term has fallen into disuse.  Interesting, but
> OT.
>   

I was a bit surprised to find myself typing it too.  I guess it could
also be a preempt race, which has been a bit more common.  Anyway, its a
deliberately unlocked access to the pagetable structure, so not terribly
surprising.

>> It seems to me that there are a few ways to fix this:
>>
>>    1. Use asm-generic/pgtable.h when CONFIG_PARAVIRT is enabled.  This
>>       will clearly work, but is pretty blunt.
>>    2. Make test_and_clear_pte_flags a new paravirt-op, which can be
>>       implemented in Xen as a hypercall, and as a raw test_and_clear_bit
>>       for everyone else.  The downside is adding yet another pv-op.
>>    3. Restructure the pagetable setup code so that the mm is not added
>>       to the prio tree until after arch_dup_mmap has been called (and
>>       the converse for exit_mmap).  This is arguably cleaner, but I
>>       haven't looked to see how much trouble this would be.
>>
>> Thoughts anyone?  Does making the pagetables visible "early" cause
>> problems for anyone else?
>>     
>
> I expect that 2) has the maximum niceness*suitable-for-2.6.23 product.
>   

OK, I'll whip a patch together.

> That's if you actually care much about kernel.org major releases - do many
> people run kernel.org kernels on Xen? 

Well, given that there hasn't been a Xen-capable kernel.org release yet,
no...  But we'll see what happens when .23 goes out the door.

>  If "not many" then we could perhaps
> do something more elaborate for 2.6.23.1.  But adding ever more pvops as
> core kernel evolves was always expected.
>   

I think keep it simple for now; anything significant can wait for the
brave new world of unified x86.

    J

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