linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jann Horn <jannh@google.com>
Cc: Yang Shi <yang@os.amperecomputing.com>,
	arnd@arndb.de, gregkh@linuxfoundation.org,
	Liam.Howlett@oracle.com, vbabka@suse.cz, willy@infradead.org,
	liushixin2@huawei.com, akpm@linux-foundation.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] /dev/zero: make private mapping full anonymous mapping
Date: Tue, 14 Jan 2025 18:38:49 +0000	[thread overview]
Message-ID: <d930175a-0f3c-43cf-b62d-2a71de92be73@lucifer.local> (raw)
In-Reply-To: <CAG48ez1rvUQuwiceNQMkxyXciAhuNvrmUvMvrkrZxB6hqtLg5w@mail.gmail.com>

On Tue, Jan 14, 2025 at 07:32:51PM +0100, Jann Horn wrote:
> On Tue, Jan 14, 2025 at 7:15 PM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> > On Tue, Jan 14, 2025 at 08:53:01AM -0800, Yang Shi wrote:
> > > On 1/14/25 4:05 AM, Lorenzo Stoakes wrote:
> > > > On Mon, Jan 13, 2025 at 02:30:33PM -0800, Yang Shi wrote:
> > > > > + fput(vma->vm_file);
> > > > > + vma->vm_file = NULL;
> > > > > + vma->vm_pgoff = vma->vm_start >> PAGE_SHIFT;
> >
> > This is just not permitted. We maintain mmap state which contains the file
> > and pgoff state which gets threaded through the mapping operation, and
> > simply do not expect you to change these fields.
> >
> > In future we will assert on this or preferably, restrict users to only
> > changing VMA flags, the private field and vm_ops.
> >
> > > > Hmm, this might have been mremap()'d _potentially_ though? And then now
> > > > this will be wrong? But then we'd have no way of tracking it correctly...
> > >
> > > I'm not quite familiar with the subtle details and corner cases of
> > > meremap(). But mmap_zero() should be called by mmap(), so the VMA has not
> > > been visible to user yet at this point IIUC. How come mremap() could move
> > > it?
> >
> > Ah OK, in that case fine on that front.
> >
> > But you are not permitted to touch this field (we need to enforce this...)
>
> Sidenote: I think the GPU DRM subsystem relies on changing pgoff in
> some of their mmap handlers; maybe talk to them about this if you
> haven't already. See for example drm_gem_prime_mmap() and
> dma_buf_mmap().

Thanks Jann , I feel like I've opened up a can of worms with this :) I will
note these as things to prioritise in the audit.

It might be worth both auditing and then actually doing the change to
restrict what can be done here too.

The problem is it requires changing a trillion callers, but hey I'm
Mr. Churn after all... ;)

Sorry Yang - I realise this is a pain and not at all obvious. Something we
in mm need to sort out (by which I mean _me_ :) your contribution and ideas
here are very valued!


  reply	other threads:[~2025-01-14 18:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 22:30 Yang Shi
2025-01-14 12:05 ` Lorenzo Stoakes
2025-01-14 16:53   ` Yang Shi
2025-01-14 18:14     ` Lorenzo Stoakes
2025-01-14 18:19       ` Lorenzo Stoakes
2025-01-14 18:21         ` Lorenzo Stoakes
2025-01-14 18:22         ` Matthew Wilcox
2025-01-14 18:26           ` Lorenzo Stoakes
2025-01-14 18:32       ` Jann Horn
2025-01-14 18:38         ` Lorenzo Stoakes [this message]
2025-01-14 19:03       ` Yang Shi
2025-01-14 19:13         ` Lorenzo Stoakes
2025-01-14 21:24           ` Yang Shi
2025-01-15 12:10             ` Lorenzo Stoakes
2025-01-15 21:29               ` Yang Shi
2025-01-15 22:05                 ` Christoph Lameter (Ampere)
2025-01-14 13:01 ` David Hildenbrand
2025-01-14 14:52   ` Lorenzo Stoakes
2025-01-14 15:06     ` David Hildenbrand
2025-01-14 17:01       ` Yang Shi
2025-01-14 17:23         ` David Hildenbrand
2025-01-14 17:38           ` Yang Shi
2025-01-14 17:46             ` David Hildenbrand
2025-01-14 18:05               ` Yang Shi
2025-01-14 17:02       ` David Hildenbrand
2025-01-14 17:20         ` Yang Shi
2025-01-14 17:24           ` David Hildenbrand
2025-01-28  3:14 ` kernel test robot
2025-01-31 18:38   ` Yang Shi
2025-02-06  8:02     ` Oliver Sang
2025-02-07 18:10       ` Yang Shi
2025-02-13  2:04         ` Oliver Sang
2025-02-14 22:53           ` Yang Shi
2025-02-18  6:30             ` Oliver Sang
2025-02-19  1:12               ` Yang Shi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d930175a-0f3c-43cf-b62d-2a71de92be73@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liushixin2@huawei.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yang@os.amperecomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox