linux-kernel - Re: [RFC] PAGE_RW Should be added to PAGE

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:	Mon, 25 Sep 2006 12:53:29 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Hugh Dickins <hugh@...itas.com>
CC:	Yingchao Zhou <yc_zhou@...c.ac.cn>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	akpm <akpm@...l.org>, alan <alan@...hat.com>,
	zxc <zxc@...c.ac.cn>,
	Linux Memory Management <linux-mm@...ck.org>
Subject: Re: [RFC] PAGE_RW Should be added to PAGE_COPY ?

Hugh Dickins wrote:

>On Sat, 16 Sep 2006, Nick Piggin wrote:
>
>>... but the problem is still fundamentally COW.
>>
>
>Well, yes, we wouldn't have all these problems if we didn't have
>to respect COW.  But generally a process can, one way or another,
>make sure it won't get into those problems: Yingchao is concerned
>with the way the TestSetPageLocked unpredictably upsets correctness.
>I'd say it's a more serious error than the general problems with COW.
>

But correctness is no more upset here than with any other reason that
the page gets COWed.

>>In other words, one should always be able to return 0 from that
>>can_share_swap_page and have the system continue to work... right?
>>Because even if you hadn't done that mprotect trick, you may still
>>have a problem because the page may *have* to be copied on write
>>if it is shared over fork.
>>
>
>Most processes won't fork, and exec has freed them from sharing
>their parents pages, and their private file mappings aren't being
>used as buffers.  Maybe Yingchao will later have to worry about
>those cases, but for now it seems not.
>

So we should still solve it for once and for all just by turning off
COW completely.

>>So if we filled in the missing mm/ implementation of VM_DONTCOPY
>>(and call it MAP_DONTCOPY rather than the confusing MAP_DONTFORK)
>>such that it withstands such an mprotect sequence, we can then ask
>>that all userspace drivers do their get_user_pages memory on these
>>types of vmas.
>>
>
>(madvise MADV_DONTFORK)
>
>For the longest time I couldn't understand you there at all, perhaps
>distracted by your parenthetical line: at last I think you're proposing
>we tweak mprotect to behave differently on a VM_DONTCOPY area.
>
>But differently in what way?  Allow it to ignore Copy-On-Write?
>

Well I think that we should have a flag that just prevents copy
on write from ever happening. Maybe that would mean it be easiest
to implement in mmap rather than as madvise, but that should be
OK.

--

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/