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 --