On Sat, 3 Jun 2000, Manfred Spraul wrote:
>Andrea Arcangeli wrote:
>>
>> On Sat, 3 Jun 2000, Manfred Spraul wrote:
>>
>> >Note we have another race during file unmap, Kanoj Sarcar also tried to
>> >fix that race.
>>
>> I'm not sure if we should define it a feature. The other race can't cause
>> kernel instability or security issues.
>
>Unfortunately it can cause kernel instability:
>zap_page_range frees pages before the tlb entries got flushed from all
>other cpus.
I see that race (present in 2.2.x too) but it's yet another race (not the
one I was wondering about in my previous email ;).
The race condition I was talking about is the one where a dirty page can
be dropped without first flushing the data of the page to disk.
It's obvious that this kind of stuff that is going on with
zap_page_range/flush_tlb_range in 2.[234].x is wrong:
clear_pte
free_pte
flush_tlb
One possible fix could be to use a safe ordering:
clear_pte
flush_tlb
free_pte
(note: i'm not suggesting here the above fix... in the unmap path we want
to flush_tlb_range() at once instead of doing a tlb flush per each pte as
the above fix would basically imply)
The above is the race you are talking about in the reply and using the
safe ordering as above the race you're talking about would go away.
The race I was talking about would remain also using the above safe
ordering instead. Another CPU could write to the page pointed by such pte
in point XXXXXX because the tlb is still in place in such CPU at point
XXXXX:
check if pte is dirty
clear_pte
XXXXXXXXXXXXX (other cpu write to the page now)
flush_tlb
if pte was dirty sync the page
free_pte
In the above scenario (even if there are no security/stability exploitable
issues) a dirty page would not be synced to disk. That was the only race I
was wondering about.
Thinking at that secnario I'm also wondering what will happen when the
other CPU will try to set the dirty bitflag in the pte that is just zeroed
at point XXXXXXX. I think the behaviour is architectural dependent...
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST