linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Jann Horn <jannh@google.com>
Cc: linux-man@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	 "Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	 Vlastimil Babka <vbabka@suse.cz>,
	linux-mm@kvack.org
Subject: Re: [PATCH man] mmap.2: Document danger of mappings larger than PTRDIFF_MAX
Date: Thu, 10 Apr 2025 22:30:02 +0200	[thread overview]
Message-ID: <7eipszjbpwa6hpmhidggt5pclbwrck6zmch6cahbs6mdbt5csg@ho4hux3avpdf> (raw)
In-Reply-To: <CAG48ez2Ox6YudW9iOS=0PvM3_NZr0fvJTda1z8eC+uybYYPANA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

Hi Jann,

On Thu, Apr 10, 2025 at 08:08:41PM +0200, Jann Horn wrote:
> > Hmmm.  Maybe it could reject PTRDIFF_MAX within the kernel, which would
> > at least work for cases where user-space ptrdiff_t matches the kernel's
> > ptrdiff_t?  Then only users where they don't match would be unprotected,
> > but those are hopefully extra careful.
> 
> Perhaps. But then some tricky things are:
> 
> 1. How many existing users would we be breaking with such a change?
> Probably _someone_ out there is deliberately mapping files over 2G
> into 32-bit processes and it sorta worked until now...
> 2. We don't really have a concept of object size in the kernel, and it
> might be hard to reason about whether mmap() is used logically to
> create a new object or extend an existing object. I guess we could
> limit VMA sizes for 32-bit userspace to 0x7ffff000 and enforce a
> 1-page gap around mappings that are at least half that size, or
> something like that, but that would probably get a bit ugly on the
> kernel side...
> 
> The first point is really the main concern for me - we might end up
> breaking existing users.

Hmmm, okay.  If it ends up being too complex, it also would be bad.
It's easier for careful programmers to just check the size before the
call.  So it's fine to not do the check in the kernel.

> > > or whether userspace even wants C semantics.
> >
> > I guess any language will have to link to C at some point, or have
> > inherent limitations similar to those of C.
> 
> This limitation is really a result of deciding to make pointer
> subtraction return a signed value, so that you can subtract a bigger
> pointer from a smaller pointer. I don't know whether other languages
> do that.
>
> > > But we can at least document it...
> >
> > Yep.  Most people are unaware of this, and believe they can get
> > SIZE_MAX.
> >
> > >
> > > @man-pages maintainer: Please wait a few days before applying this;
> > > I imagine there might be some discussion about this.
> >
> > Okay; see some minor comments below.
> 
> Thanks. (I'll probably be out for the next two weeks or so, I'll
> probably get back to this afterwards.)

Okay, no problem

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2025-04-10 20:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 20:03 Jann Horn
2025-04-09 20:25 ` Jakub Wilk
2025-04-09 20:41 ` Alejandro Colomar
2025-04-10 18:08   ` Jann Horn
2025-04-10 20:30     ` Alejandro Colomar [this message]

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=7eipszjbpwa6hpmhidggt5pclbwrck6zmch6cahbs6mdbt5csg@ho4hux3avpdf \
    --to=alx@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=vbabka@suse.cz \
    /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