linux-kernel - Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking

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:   Sat, 5 Aug 2023 03:16:59 +0200
From:   Mateusz Guzik <mjguzik@...il.com>
To:     Suren Baghdasaryan <surenb@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        akpm@...ux-foundation.org, regressions@...mhuis.info,
        bagasdotme@...il.com, jacobly.alt@...il.com, willy@...radead.org,
        liam.howlett@...cle.com, david@...hat.com, peterx@...hat.com,
        ldufour@...ux.ibm.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org,
        linux-arm-kernel@...ts.infradead.org, gregkh@...uxfoundation.org,
        regressions@...ts.linux.dev, Jiri Slaby <jirislaby@...nel.org>,
        Holger Hoffstätte <holger@...lied-asynchrony.com>,
        stable@...r.kernel.org
Subject: Re: [PATCH v2 3/3] fork: lock VMAs of the parent process when forking

On 8/5/23, Suren Baghdasaryan <surenb@...gle.com> wrote:
> On Fri, Aug 4, 2023 at 5:49 PM Mateusz Guzik <mjguzik@...il.com> wrote:
>> However, the other users (that I know of ) go through the mmap
>> semaphore to mess with anything which means they will wait for
>> dup_mmap to finish (or do their work first). I would be surprised if
>> there were any cases which don't take the semaphore, given that it was
>> a requirement prior to the vma patchset (unless you patched some to no
>> longer need it?). I would guess worst case the semaphore can be added
>> if missing.
>
> No, the only mmap_lock read-lock that is affected is during the page
> fault, which is expected.
>

I have difficulty parsing your statement.

I am saying that any 3rd parties which can trigger page faults already
read lock mmap_lock or can be made to do it (and I don't know any case
which does not already, but I'm not willing to spend time poking
around to make sure). One can consider 3rd parties as not a problem,
modulo the audit.

Past that there does is no known source of trouble? In my original
e-mail I was worried about processes up the chain in ancestry, perhaps
some of the state is shared(?) and the locking at hand neuters any
problems. I'm guessing this is not necessary.

Bottom line though it looks like this will work fine?

That said, I'm not going to submit a patch I can't confidently defend.
As I did not dig into any of the VMA code and can't be arsed to audit
all places which mess with "foreign" mm, I'm definitely not submitting
this myself. You are most welcome to write your own variant at your
leisure. :)

-- 
Mateusz Guzik <mjguzik gmail.com>