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: <5ae7e3c1-3875-ea1e-54b3-ac3c493a11f0@virtuozzo.com>
Date:   Mon, 3 Jun 2019 17:56:32 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     akpm@...ux-foundation.org, dan.j.williams@...el.com,
        mhocko@...e.com, keith.busch@...el.com,
        kirill.shutemov@...ux.intel.com, alexander.h.duyck@...ux.intel.com,
        ira.weiny@...el.com, andreyknvl@...gle.com, arunks@...eaurora.org,
        vbabka@...e.cz, cl@...ux.com, riel@...riel.com,
        keescook@...omium.org, hannes@...xchg.org, npiggin@...il.com,
        mathieu.desnoyers@...icios.com, shakeelb@...gle.com, guro@...com,
        aarcange@...hat.com, hughd@...gle.com, jglisse@...hat.com,
        mgorman@...hsingularity.net, daniel.m.jordan@...cle.com,
        jannh@...gle.com, kilobyte@...band.pl, linux-api@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v2 0/7] mm: process_vm_mmap() -- syscall for duplication a
 process mapping

On 03.06.2019 17:38, Kirill Tkhai wrote:
> On 22.05.2019 18:22, Kirill A. Shutemov wrote:
>> On Mon, May 20, 2019 at 05:00:01PM +0300, Kirill Tkhai wrote:
>>> This patchset adds a new syscall, which makes possible
>>> to clone a VMA from a process to current process.
>>> The syscall supplements the functionality provided
>>> by process_vm_writev() and process_vm_readv() syscalls,
>>> and it may be useful in many situation.
>>
>> Kirill, could you explain how the change affects rmap and how it is safe.
>>
>> My concern is that the patchset allows to map the same page multiple times
>> within one process or even map page allocated by child to the parrent.
> 
> Speaking honestly, we already support this model, since ZERO_PAGE() may
> be mapped multiply times in any number of mappings.

Picking of huge_zero_page and mremapping its VMA to unaligned address also gives
the case, when the same huge page is mapped as huge page and as set of ordinary
pages in the same process.

Summing up two above cases, is there really a fundamental problem with
the functionality the patch set introduces? It looks like we already have
these cases in stable kernel supported.

Thanks,
Kirill

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ