linux-kernel - Re: [PATCH RFC] mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA

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]

Date:   Wed, 7 Dec 2022 16:32:17 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Peter Xu <peterx@...hat.com>, Hugh Dickins <hughd@...gle.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Ives van Hoorne <ives@...esandbox.io>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...le.com>,
        Alistair Popple <apopple@...dia.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Nadav Amit <nadav.amit@...il.com>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [PATCH RFC] mm/userfaultfd: enable writenotify while
 userfaultfd-wp is enabled for a VMA

> 
> David, would you please repost a new patch for this one and copy Ives to
> make sure it'll work for him in his systems?

Yes, will do. I think has was already cc'ed.

> 
> I'd suggest to drop the mprotect example, I'll reply later on that to the
> other email but I still don't know whether it's a good example for a reader
> to understand the problem.

Yes, can do.

> 
> No reproducer needed for numa I think - I guess Ives's test case would be
> far enough to verify it if possible.  I also hope what Ives saw was the
> numa balancing issue you reported, so maybe it'll resolve all problem he
> has.  Then with that verified and queued we can drop the mm/migrate patch.

I tried writing a numa hinting reproducer, but so far I assume that it's 
with current code not (easily) possible for shmem.

We'd have to call change_prot_numa() in order to protnone these PTEs. 
That can either happen via

a) mbind() with MPOL_MF_LAZY. However, user space is currently not able
    to set that flag (dead code ...).
b) task_numa_work(). However, vma_policy_mof() seems to always fail on
    shmem and prevent us from reaching that code. Reason is that shmem
    implements vm_ops->get_policy, and it seems to be impossible to get
    MPOL_F_MOF set. At least I haven't found an easy way or I am missing
    something.

So numa hinting might not immediately explain the lost write faults.

... but are there other ways to reach do_numa_page(), even without 
active NUMA hinting? I found at least one:

   map = mmap(NULL, size, PROT_WRITE, MAP_SHARED|MAP_ANON, -1, 0);
   memset(map, 0, size);
   uffd_wp_range(map, size);

On upstream during the next write fault, we'll end up in do_numa_page() 
and simply remap the page writable due to vm_page_prot, not triggering a 
write fault. I can see the "numa_hint_faults" counter in /proc/vmstat 
increasing accordingly, so we're really in do_numa_page().

PROT_WRITE on shmem with uffd-wp is completely non-functional as it 
seems. It seems to work with anon memory. And with my patch, it also 
works with shmem.

Attaching a simple reproducer (uffd-wp-prot-write.c).

Independent of uffd-wp on shmem, we seem to be missing propagating the 
uffd-wp bit when splitting the huge zeropage. So uffd-wp'ing the huge 
zeropage and then splitting it loses the uffd-wp markers. :/

Fix seems easy and I just tested my possible fix. Attaching a simple 
reproducer (uffd-wp-huge-zero.c).

-- 
Thanks,

David / dhildenb

View attachment "uffd-wp-prot-write.c" of type "text/x-csrc" (3718 bytes)

View attachment "uffd-wp-huge-zero.c" of type "text/x-csrc" (4150 bytes)