linux-kernel - Re: [PATCH 2/3] userfaultfd: UFFDIO

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: <C04B3D0F-A757-49A5-9CF4-3387EED41562@gmail.com>
Date:   Thu, 14 Sep 2023 21:03:45 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Suren Baghdasaryan <surenb@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, viro@...iv.linux.org.uk,
        brauner@...nel.org, shuah@...nel.org,
        Andrea Arcangeli <aarcange@...hat.com>, lokeshgidra@...gle.com,
        Peter Xu <peterx@...hat.com>,
        David Hildenbrand <david@...hat.com>,
        Hugh Dickins <hughd@...gle.com>, mhocko@...e.com,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Mike Rapoport <rppt@...nel.org>,
        Matthew Wilcox <willy@...radead.org>, Liam.Howlett@...cle.com,
        Jann Horn <jannh@...gle.com>, zhangpeng362@...wei.com,
        bgeffon@...gle.com, kaleshsingh@...gle.com, ngeoffray@...gle.com,
        jdduke@...gle.com, linux-mm <linux-mm@...ck.org>,
        linux-fsdevel@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-kselftest@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH 2/3] userfaultfd: UFFDIO_REMAP uABI



> On Sep 14, 2023, at 8:28 PM, Suren Baghdasaryan <surenb@...gle.com> wrote:
> 
> On Thu, Sep 14, 2023 at 2:57 PM Nadav Amit <nadav.amit@...il.com> wrote:
>> 
>> 
>>> On Sep 14, 2023, at 8:26 AM, Suren Baghdasaryan <surenb@...gle.com> wrote:
>>> 
>>> +     if (!pte_same(ptep_clear_flush(src_vma, src_addr, src_pte),
>>> +             orig_src_pte))
>>> +             BUG_ON(1);
>> 
>> Just a minor detail regarding these few lines:
>> 
>> Besides the less-than-ideal use of BUG_ON() here, I think that this code
>> assumes that the PTE cannot change at this point. However, as the PTE was
>> still mapped at this point, I think the access and dirty bits can be set.
> 
> At this point we are holding PTLs for both PTEs (see
> double_pt_lock()).  Can a PTE be modified from under us in this
> situation?

PTEs has several parts: access-control bits (e.g., writable), physical
frame number, software-only bits and log-bits. The log-bits, which are
“access” and “dirty” on x86, track whether the PTE has ever been used
for translation or write correspondingly.

Without getting into all the subtleties (e.g., “access" can be set
speculatively even if no actual access take place), as long as the PTE
is present, it might be used for access (and write if it is writable)
by other cores. The page-table locks are irrelevant here, because the
PTE is not updated by software, but it is updated by the CPU itself
during the page-walk/write.