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: <f4b6cd03-28d7-b041-6dd4-46ac0812fc9b@redhat.com>
Date:   Thu, 16 Feb 2023 10:37:36 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Muhammad Usama Anjum <usama.anjum@...labora.com>,
        peterx@...hat.com, Andrew Morton <akpm@...ux-foundation.org>
Cc:     kernel@...labora.com, Paul Gofman <pgofman@...eweavers.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/2] mm/userfaultfd: Support WP on multiple VMAs

On 16.02.23 10:16, Muhammad Usama Anjum wrote:
> mwriteprotect_range() errors out if [start, end) doesn't fall in one
> VMA. We are facing a use case where multiple VMAs are present in one
> range of interest. For example, the following pseudocode reproduces the
> error which we are trying to fix:
> - Allocate memory of size 16 pages with PROT_NONE with mmap
> - Register userfaultfd
> - Change protection of the first half (1 to 8 pages) of memory to
>    PROT_READ | PROT_WRITE. This breaks the memory area in two VMAs.
> - Now UFFDIO_WRITEPROTECT_MODE_WP on the whole memory of 16 pages errors
>    out.

I think, in QEMU, with partial madvise()/mmap(MAP_FIXED) while handling 
memory remapping during reboot to discard pages with memory errors, it 
would be possible that we get multiple VMAs and could not enable uffd-wp 
for background snapshots anymore. So this change makes sense to me.

Especially, because userfaultfd_register() seems to already properly 
handle multi-VMA ranges correctly. It traverses the VMA list twice ... 
but also holds the mmap lock in write mode.

> 
> This is a simple use case where user may or may not know if the memory
> area has been divided into multiple VMAs.
> 
> We need an implementation which doesn't disrupt the already present
> users. So keeping things simple, stop going over all the VMAs if any one
> of the VMA hasn't been registered in WP mode. While at it, remove the
> un-needed error check as well.
> 
> Reported-by: Paul Gofman <pgofman@...eweavers.com>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@...labora.com>
> ---


Acked-by: David Hildenbrand <david@...hat.com>

-- 
Thanks,

David / dhildenb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ