linux-kernel - Re: [RFC/PATH 1/2] MM: Make Page Tables Relocatable -- conditional flush

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] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2008 18:15:40 -0400
From:	"Ross Biro" <rossb@...gle.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC/PATH 1/2] MM: Make Page Tables Relocatable -- conditional flush

On Wed, Apr 30, 2008 at 3:56 PM, Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>>> - How does it deal with migrating the accessed/dirty bits in ptes if
>>>  cpus can be using old versions of the pte for a while after the
>>>  copy?  Losing dirty updates can lose data, so explicitly addressing
>>>  this point in code and/or comments is important.
>>>
>>
>> It doesn't currently.  Although it's easy to fix.  Just before the
>> free, we just have to copy the dirty bits again.  Slow, but not in a
>> critical path.
>>
>
> But the issue I'm concerned about is what happens if a process writes the
> page, causing its cpu to mark the (old, in-limbo) pte dirty.  Meanwhile
> someone else is scanning the pagetables looking for things to evict.  It
> check the (shiny new) pte, finds it not dirty, and decides to evict the
> apparently clean page.
>
> What, for that matter, stops a page from being evicted from under a limboed
> mapping?  Does it get accounted for (I guess the existing tlb flushing
> should be sufficient to keep it under control).

The delimbo functions can be extended to deal with the dirty bit.
They already have to be called to make sure the cpu is looking at the
proper page flags.  The easiest solution to the races is probably to
make the delimbo pte functions flush the tlb cache to make sure the
cpu will also be looking at the correct entry to update flags.
Otherwise the atomic ptep* functions would probably need to be
modified.

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