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]
Message-ID: <3a3422e5-8cd2-1a13-5eef-425383808396@yandex.ru>
Date:   Fri, 31 Mar 2023 11:53:08 +0500
From:   stsp <stsp2@...dex.ru>
To:     Lorenzo Stoakes <lstoakes@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mm@...ck.org, Brian Geffon <bgeffon@...gle.com>,
        Li Xinhai <lixinhai.lxh@...il.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        linux-api@...r.kernel.org, linux-man@...r.kernel.org,
        Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: MREMAP_DONTUNMAP corrupts initial mapping

Hi, thanks for info.

30.03.2023 23:42, Lorenzo Stoakes пишет:
> This seems to be a case of the documentation not quite being correct in the
> case of a MAP_PRIVATE file mapping, from the mremap man page discussing
> MREMAP_DONTUNMAP:-
Yes, it seems to be the case.
However, current semantic of MREMAP_DONTUNMAP
is unsatisfactory for many uses.
Have you considered adding more flags
to get things consistent?
For my use-case, at the very least 1 more
flag is needed to specify that in case of an
anonymous mapping I need the source
aliased not to zero-page but to destination
mapping, so that the source and dest do
match unless manually modified.
Another similar flag may be needed to
say that in case of a file-backed private
mapping source needs to be converted
to anonymous mapping, and if the first
flag is also specified, then again source
and dest would match. That can be used
in case the private file-backed mapping
was modified by hands.

Overall I need a set of flags that can
guarantee that MREMAP_DONTUNMAP
doesn't change the source data.
Can something like that be considered?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ