linux-kernel - Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork

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>] [day] [month] [year] [list]

Message-ID: <20201102083122.GA23988@quack2.suse.cz>
Date:   Mon, 2 Nov 2020 09:31:22 +0100
From:   Jan Kara <jack@...e.cz>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
        Peter Xu <peterx@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
        Christoph Hellwig <hch@....de>,
        Hugh Dickins <hughd@...gle.com>, Jann Horn <jannh@...gle.com>,
        John Hubbard <jhubbard@...dia.com>,
        Kirill Shutemov <kirill@...temov.name>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Leon Romanovsky <leonro@...dia.com>,
        Linux-MM <linux-mm@...ck.org>, Michal Hocko <mhocko@...e.com>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during
 fork

On Fri 30-10-20 14:02:26, Jason Gunthorpe wrote:
> On Fri, Oct 30, 2020 at 05:51:05PM +0100, Jan Kara wrote:
> > > @@ -446,6 +447,12 @@ struct mm_struct {
> > >  		 */
> > >  		atomic_t has_pinned;
> > >  
> > > +		/**
> > > +		 * @write_protect_seq: Odd when any thread is write protecting
> > > +		 * pages in this mm, for instance during fork().
> > > +		 */
> > > +		seqcount_t write_protect_seq;
> > > +
> > 
> > So this comment isn't quite true. We can be writeprotecting pages due to
> > many other reasons and not touch write_protect_seq. E.g. for shared
> > mappings or due to explicit mprotect() calls. So the write_protect_seq
> > protection has to be about something more than pure write protection. One
> > requirement certainly is that the VMA has to be is_cow_mapping(). What
> > about mprotect(2) calls? I guess the application would have only itself to
> > blame so we don't care?
> 
> Yes, that sounds right, How about
> 
> /**
>  * @write_protect_seq: Locked when any thread is write protecting
>  * pages for COW in this mm, for instance during page table copying
           ^^^ maybe I'd write a bit more explicitly "... write protecting
pages mapped by this mm to enforce later COW, ..."

>  * for fork().
>  */
> 
> mprotect and shared mappings cause faults on write access not COW?

Correct.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR