From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C10AC3601E for ; Thu, 10 Apr 2025 18:09:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CFC7F6B0369; Thu, 10 Apr 2025 14:09:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA9E86B036A; Thu, 10 Apr 2025 14:09:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFC956B036B; Thu, 10 Apr 2025 14:09:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8D49B6B0369 for ; Thu, 10 Apr 2025 14:09:20 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8407158DC6 for ; Thu, 10 Apr 2025 18:09:21 +0000 (UTC) X-FDA: 83318921322.24.6AC0620 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf01.hostedemail.com (Postfix) with ESMTP id 9CDA840008 for ; Thu, 10 Apr 2025 18:09:19 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uiS298az; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744308559; a=rsa-sha256; cv=none; b=TeUBFyXzVhbA34FO19xVVvTJEiY2iz/X3o2rjJ9djLQ+F9P9XiHAAVhKW4M7ULtNk8+UGQ DpWMfHCiDn3fQCEYotJGjcUxye+GV2RbEalLdEdZhQWLKihKRPId1ahlfvxKEZOt7qNaqW dS9hysCrTTctqQ+icM/hTcwj1TtybG4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uiS298az; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744308559; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kBiqOCa6ORKwj1OnHeplbDO55Ve1gweoAeDCTwRqF24=; b=T/sbWOfbJq80ser+ljvHN9Py7zFj/Me0hkKd1E99G31qDP+rhYB4DBBFjhq1Q0Bi1EXGWf SXefgz+Q+xeGuTCeUZn62zH3VT9JMcta9DTqHfVCOrbRPZhZHIW1KCowWmEfzr4+Ru/IQg XwDin871sTIlsP0N+Ols/J4xfz0MYyY= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5e5cbd8b19bso1255a12.1 for ; Thu, 10 Apr 2025 11:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744308558; x=1744913358; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kBiqOCa6ORKwj1OnHeplbDO55Ve1gweoAeDCTwRqF24=; b=uiS298azGsLoMdK1DKFv/VZCr+Nm5P1XLWzWGHHd3BAM5R3qQb2J0pfjjBBOZoxSRk snqoC3GuALV2qWDkkGVwd73Se8wHSawf8g4i3tS3+SqRxlb9AlVQpnj3xtsRmmLpNk0b J7qumYm8E12j1HlxyyGfCSc0Q2FBM///ZubZ1VlRU06BUXqK2vEZqYN6piU9kfwhiHSR Py5DJWT/IvQ/Dmxo/u4WKfKV3cv6JdvZG017V78Wl8AHNxaNA5cTV3yrhDeQILhPXtEW iz3DjCje+oosAQKbonW2B5ei0vVsY/U32pGeE6W5NiOMQl8ljApNSpC4POugF7g2Yyhb nz4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744308558; x=1744913358; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kBiqOCa6ORKwj1OnHeplbDO55Ve1gweoAeDCTwRqF24=; b=m65FNaYAe5nwAviLFiROyTkh+hgbZcEqHq0tuFfTgWtpYOBvK97QkNUD1L5QbAmDcS 4Co//NPonoF6wytnFqchhZwrcWw2Jtoffg1qBXdAuM1xjsxg+5rsC43QV8c9ztoiu0l2 H6b6BHsH4xYzGRQZic5sJwfjDnohU7MuXN33LQDuzxOQA4KH5MXNwAgXX4WEKi3WZ2iS 6c6DQszKcoLTxZX2DugZRCk6IlZc/dlG20cK+IdMN5PvDn9/A1y/WJa5yvZKzPbzoDUZ ACD7+0uSPaZWEdM/YJ4wh1lbyMJGB+8n4ILj2QVs6Lo6nc7vcApHseWqnOh5GQLdwjO+ 3z9A== X-Forwarded-Encrypted: i=1; AJvYcCVNKnwmXXzTdiFXa9sch3iFfuNHa+rXA7B7Y+Nrj2uNcFmifU7y+/mTFenaVNlh+OcK8z8EzPEX/Q==@kvack.org X-Gm-Message-State: AOJu0YytskZQgkBhjXlpLZjtnQiBNN9TFvKfh0Rcyd29YONBaz2rmRsV SsW1Z6ht/+njVAsZ5Y50YAc43zU2jyJFG4gzTBiDzJHihagR6WyIKxpES3mIUnc4CBvQhgZqIUI PbnNOzt88sUKmd6fmJHBNapb/s+oDeqgtdbP3 X-Gm-Gg: ASbGncu4mpWwQsZktE6H1yHyKNVKAQ1tdd4xXfBeyLgZdRK7NmGz9jcX5Q6qYM6I30r sE1LNYmUkrqpK7WfAZynpGgpKudLdUIMULmuO0EBNESKIbFLKV7AWtVw3hVWwrvRWXixyV/ES/A DZmo8vfVCuXtV2c2Zvpt+HDY558f/ZEM6MsQuCn5egN6m5k/w+nQ== X-Google-Smtp-Source: AGHT+IHNd5gXrt93ytFjFAhFM4sr1y4z+b+KauHs3T6o81++KG4r0d89C9pGvaHfV7xqhuqJ9PXrG12gji4ZcKyV42c= X-Received: by 2002:a50:954c:0:b0:5e4:9ee2:afe1 with SMTP id 4fb4d7f45d1cf-5f35d0668ccmr5169a12.2.1744308557381; Thu, 10 Apr 2025 11:09:17 -0700 (PDT) MIME-Version: 1.0 References: <20250409200316.1555164-1-jannh@google.com> In-Reply-To: From: Jann Horn Date: Thu, 10 Apr 2025 20:08:41 +0200 X-Gm-Features: ATxdqUEquuGPwCLacfB2WZNL8q6DeiACwrXJzMpGsndOI_o7ZP3y3hmfCBM6HUQ Message-ID: Subject: Re: [PATCH man] mmap.2: Document danger of mappings larger than PTRDIFF_MAX To: Alejandro Colomar Cc: linux-man@vger.kernel.org, Andrew Morton , "Liam R . Howlett" , Lorenzo Stoakes , Vlastimil Babka , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9CDA840008 X-Stat-Signature: 437cbywd7deyrufsanrkndey8iuoahh8 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744308559-7608 X-HE-Meta: U2FsdGVkX1/5qKVmrzo31AtWBL0M+aRbkY1xK6EfOejfHnXS9Pv92vBXT4A1iQQxRDw0TLD9HZGdxMdCxeALpAlICrC74c/WOYPqpiV7ccuUkfqMIGFn4qT9dTw/s74Md/JXG3A2yJ/SgO9TvLl0xDZQ4tWVHIm/Vdwsqolapor2x4teF8NjcDfOr4B9rfV54Z4n8NPEjq3c/LtkGHsaqGiqF0cGWsUuPecNJ2nyNX7AG0nCxmqSb2oO2X50AU6pGGyfx2o8mS4zNKPUGpvo5qaAEgzott4qWSei4XuvxjG+bIHlKRW48ras4TQfS009sSyCSGEP6a9B+zH0lK4xjNPckcYpknm1mYKkAicLd/kgPT2FGDxmWT55DoT76Y1gLv6AlpZmo12rDbREoKafQdRKzwv0tSNJpOLXlua4P6NIrSrXhLPEAKq44JA8SHXO49QLzvBCDqiwGu+YWI2WtN0IRo/Jvmus4RTJ/akCZeIZFUSNuM5lQgU0ltxFPRv+FK+KOTfl/Ga2EVicueH727N9Fgryg5Czn99T0YqNnsDRFiURvY4buwiZIbYCpgYLilaNs0Ys7CkKw9FxHB4egZfYPiqkRCRopdidP5n4jetjKj/8VoR0NuFX3to4NhLIXdG8OgoWplGVUqLiKLhFJr2dbOCoR+hFQgqq1amg5P2Ga+f3DjZpePC0HrskS9aofTJeIe6eM2hL7pJsrNDsm9LJpV3nzIc9kGPqcLq6h3QOnOfIGblKqmy4g/ZfjcUpj8o3MSXvQIKTP79RROxJ/JrZp1tDfAbfqxe3nR8Xia7FRakZinMlNQDTnfAZZFye4SZbOCdx3CShIDiypj5SAFydNRf1abJ8yDnCSBp8FFaLSPWLUFO5xOnBLVon2LqhcxGgPzIkvz+couW8X8JkxBZJ9oGjkSEbBdOHQqoWBjPZk4qQUoJliiZaG8TraPn7QdhKhCIg+O2B8edyI4W fZEPuG6E incnND8NxAWWqzMOLD0w6NlXuuIvpjinKrX1p+LHV679GIwBrWBnXG9xLagWEdryhFj5akeYRkhTPDDIIiSQtxjw8W6sD6/4ye7TNeNIJqlcA/nbkVqhGN4Pr+jojnXDyPOVsvUI6qh8vDnw+DREE4+D+nu6lLM2Bgbv8JRE7Sb9LuSszIbpPt/qQOmrDYxUNRd4SnCaeJH+risRuguJUR8gNpfEVHDt2RQmObE5gzG1GQQq9vR42BeJcGvB5inLd8WprAbUNYUjONbR8TpVvW4lmGNmnp1eO9NOHTGfmN5HHUhR2AGySKNeFO9mVlIEPIW+0dBQggR8kU8xW8N+so/xvUI6qrcf6yPKAlZRv3r4jpL++zZ8KJnJFsQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.307460, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Apr 9, 2025 at 10:41=E2=80=AFPM Alejandro Colomar = wrote: > On Wed, Apr 09, 2025 at 10:03:16PM +0200, Jann Horn wrote: > > References: > > - C99 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pd= f > > section "6.5.6 Additive operators", paragraph 9 > > - object size restriction in GCC: > > https://gcc.gnu.org/legacy-ml/gcc/2011-08/msg00221.html > > - glibc malloc restricts object size to <=3DPTRDIFF_MAX in > > checked_request2size() > > --- > > I'm not sure if we can reasonably do anything about this in the kernel, > > given that the kernel does not really have any idea of what userspace > > object sizes look like, > > 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. > > 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.)