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, 26 Apr 2023 09:41:51 +0100
From:   Lorenzo Stoakes <lstoakes@...il.com>
To:     Mika Penttilä <mpenttil@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>,
        Matthew Wilcox <willy@...radead.org>,
        Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
        Leon Romanovsky <leon@...nel.org>,
        Christian Benvenuti <benve@...co.com>,
        Nelson Escobar <neescoba@...co.com>,
        Bernard Metzler <bmt@...ich.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Bjorn Topel <bjorn@...nel.org>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Christian Brauner <brauner@...nel.org>,
        Richard Cochran <richardcochran@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        linux-fsdevel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        Oleg Nesterov <oleg@...hat.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        John Hubbard <jhubbard@...dia.com>, Jan Kara <jack@...e.cz>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Pavel Begunkov <asml.silence@...il.com>,
        David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH v4] mm/gup: disallow GUP writing to file-backed mappings
 by default

On Wed, Apr 26, 2023 at 10:30:03AM +0300, Mika Penttilä wrote:

[snip]

> > The issue is how dirtying works. Typically for a dirty-tracking mapping the
> > kernel makes the mapping read-only, then when a write fault occurs,
> > writenotify is called and the folio is marked dirty. This way the file
> > system knows which files to writeback, then after writeback it 'cleans'
> > them, restoring the read-only mapping and relying on the NEXT write marking
> > write notifying and marking the folio dirty again.
> >
>
> I know how the dirty tracking works :). And gup itself actually triggers the
> _first_ fault on a read only pte.

I'm sure you don't mean to, but this comes off as sarcastic, 'I know how X
works :)' is not a helpful comment. However, equally apologies if I seemed
patronising, not intentional, I am just trying to be as clear as possible,
which always risks sounding that way :)

Regardless, this is a very good point! I think I was a little too implicit
in the whole 'at any time the kernel chooses to write to this writenotify
won't happen', and you are absolutely right in that we are not clear enough
about that.

>
> So the problem is accessing the page after that, somewehere in future. I
> think this is something you should write on the description. Because,
> technically, GUP itself works and does invoke the write notify. So the
> misleading part is you say in the description it doesn't. While you mean a
> later write, from a driver or such, doesn't.
>

Ack, agreed this would be a useful improvement. Will fix on next spin!

[snip]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ